Maintainers Sync 2021-12-01 - Wrangler Integration

[robertoaloi]

Present: Alan, Simon, Roberto, Dominik (student)

Content

The discussion was about what is the best way to integrate Wrangler into erlang_ls. There is a parallel discussion going on with the RefactorErl people on the same topic for erlang_ls.

The Wrangler state of play is they have forked erlang_ls and the vscode extension, and have it working as a proof of concept.

They get around the problem of not being able to enter data in vscode by using middleware, as per the screenshot.

The outcome immediate decisions were:

• Let wrangler run in a separate node, communicate via RPC. Same as refactorErl
• Move the minimal calling code into erlang_ls itself. This can perhaps become a behaviour to match the implementations for both Wrangler and RefactorErl
• Make a PR on the vscode extension for the middleware

The idea is that if the middleware is not in place, the bare command still works, but with default values for e.g. a new function name. This can then be renamed in a separate step.

Other discussion around more complex refactorings

Simon pointed out that some refactorings, such as “fold subexpression“ look for the potential duplication throughout the code base and need to ask for each instance how to apply it. In Eclipse, and the custom Emacs plugin this can be presented as a list, or worked though in the IDE one by one. LSP does not offer this.

Alan suggested sending an edit to create a new, transient file in the IDE, of a special kind, for commands. This is fully active via LSP, and allows code actions on the contents, which can be the proposed list of actions. This can potentially also be edited by the user, to add parameters for proposed changes, etc. Or to generate wrangler query language.

We agreed to think more about it, and have another discussion in the erlang_ls sync one friday