Skip to content

Add documentation for the plugin environment #2092

Open
@goldenstein64

Description

@goldenstein64

Plugins have a surprisingly large amount of flexibility when the surrounding environment is considered. Unfortunately, most of the environment is undocumented, which means there's a good chance plugin developers don't know how much their plugin can really do.

Currently, printing out package.path and package.cpath gives these directories

package.path

# directories provided by the extension
$LSP/script/?.lua
$LSP/script/?/init.lua

# access to the plugin's directory
$PLUGIN/?.lua

package.cpath

$LSP/bin/?.dll

where:

  • $LSP is the path to this project's folder, and
  • $PLUGIN is a path to the plugin's current directory. ~/project/config/plugin.lua would make $PLUGIN point to ~/project/config

Along with giving plugins the ability to have sub-modules, the LSP has some very useful utilities in its script folder like:

  • vm for inspecting types (or so it seems)
  • parser.compile for getting an AST
  • inspect which looks like kikito/inspect.lua
  • config for reading LSP settings like Lua.runtime.version

I don't work with Visual Studio enough to understand the DLLs in $LSP/bin, or at least not enough to work with them in Lua.

... has some useful information too.

local inspect = require("inspect")

print(inspect({ ... }))
--[[--> 
{ 
  <function 1>,                   -- this plugin loaded as a chunk using `load()`
  "file:///$WORKSPACE_FOLDER",    -- a URI pointing to the workspace folder
  {}                              -- arguments provided by the setting `Lua.runtime.pluginArgs`
}
]]

I think this information is useful enough to be documented in the wiki. I can contribute to it if need be.

It would be even more useful and accessible if there was a meta-addon that adds the $LSP/script directory to Lua.workspace.library or a boolean option that adds the directory internally. I can try to contribute to that as well.

I understand that $LSP/script may be updated often for bugfixes and other things. If this is the case, I think it would at least be useful to provide a directory for plugin utilities.

I'm not sure about what to do when the VS Code extension gets updated since it changes directory. Maybe, more generally, the LSP can warn you about missing libraries.

Also, if $LSP/script updates too frequently to be mentioned in the wiki, I think the meta-addon route would be more fruitful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationHas to do with documentation either in the wiki or in the repofeat/pluginAssociated with a plugin

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions