Add support for Emacs configuration to `lune setup`

[kennethloeffler]

Right now, lune setup can only configure VS Code. There are a couple TODO comments mentioning a desire to support other editors:

https://github.com/lune-org/lune/blob/94ba331ed0025b45b687a401e06521afbc4ff109/src/cli/setup.rs#L27-L39

https://github.com/lune-org/lune/blob/94ba331ed0025b45b687a401e06521afbc4ff109/src/cli/setup.rs#L84-L99

I've recently created an integration for the Luau Language Server for Emacs at https://github.com/kennethloeffler/eglot-luau, and using this package to support the editing of Lune scripts is an important use case. I'd like to add support for Emacs configuration to lune setup so that users can simply run this command in their projects, and don't have to know all the idiosyncrasies of LSP workspace configuration for Eglot (Emacs' native implementation of an LSP client) to get it working for their Lune scripts.

While it's possible for users to do this setup themselves, it's yet more to learn before the package can be applied to this use case, and it's somewhat fiddly. The eglot documentation even mentions it as a caveat:

For some users, setting eglot-workspace-configuration is a somewhat daunting task. One of the reasons is having to manage the general Elisp syntax of per-mode directory-local variables, which uses alists (see Association Lists in GNU Emacs Lisp Reference Manual), and the specific syntax of Eglot’s variable, which uses plists.

Is Eglot-specific configuration something that fits into lune setup? If so, I'd love some pointers on how to best fit it into the existing code!

[CompeyDev]

This would great to have for neovim too, however it would be a bit tricky considering neovim doesn't have a standard configuration system, and it really depends on what the user has. Even if we knew how they were setting up luau-lsp with lspconfig, it would be a global edit, instead of a workspace-specific one.

Thus, I think it would make more sense to create editor specific plugins for parsing and applying the existing VSCode settings which lune sets up.

[filiptibell]

I think any decently popular editor that has workspace-specific configuration support is probably a good candidate for adding to the lune setup command. I'm mildly concerned that this specific configuration format is not that widely used and it'd be difficult to make a robust solution, but @kennethloeffler you probably have a better idea than me there.

For implementing support for more editors we would need a bit of structural refactoring first:

• SetupCommand needs some kind of SetupEditor enum arg which may be VSCode, Emacs, etc.
  1. If provided as lune setup vscode / lune setup emacs, set up that editor and nothing else
  2. If not provided, try to detect from existing files / directories
  3. If all else fails, maybe we prompt the user with dialoguer?
• Setup for VSCode and Emacs should go in their own sub-files

From there it should be mostly the Emacs-specific setup stuff in its own file, feel free to mirror the VSCode implementation or not, doesn't matter too much to me 👍

[aatxe]

For some context, eglot is one of two widely-used LSP implementations for Emacs, and it is the one that the Emacs team officially adopted for the editor. So, it feels like a reasonable thing for lune to target.

[kennethloeffler]

I think any decently popular editor that has workspace-specific configuration support is probably a good candidate for adding to the lune setup command. I'm mildly concerned that this specific configuration format is not that widely used and it'd be difficult to make a robust solution, but @kennethloeffler you probably have a better idea than me there.

For implementing support for more editors we would need a bit of structural refactoring first:

* `SetupCommand` needs some kind of `SetupEditor` enum arg which may be `VSCode`, `Emacs`, etc.

  1. If provided as `lune setup vscode` / `lune setup emacs`, set up that editor and nothing else
  2. If not provided, try to detect from existing files / directories
  3. If all else fails, maybe we prompt the user with `dialoguer`?

* Setup for VSCode and Emacs should go in their own sub-files

From there it should be mostly the Emacs-specific setup stuff in its own file, feel free to mirror the VSCode implementation or not, doesn't matter too much to me 👍

The configuration format for .dir-locals.el is Just an Emacs Lisp S-expression. It's an association list that maps "major mode" names to yet more association lists that map variable names to their desired values for the directory: https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html.

Eglot uses property lists to represent JSON objects, which (you guessed it) are Just More S-Expressions, except these map keyword symbols to their values (which may be nested property lists): https://joaotavora.github.io/eglot/#JSONRPC-objects-in-Elisp.

When all is said and done, an S-expression containing the desired customizations might look something like this (I've included some other customizations to hopefully show how the format generally works):

;;; nil means that the customizations apply for any major mode
((nil . ((eglot-luau-rojo-project-path . "my-game.project.json")
         (eglot-workspace-configuration
          . (:luau-lsp (:require
                        (:mode "relativeToFile"
                         :directoryAliases (:@lune/ "~/.lune/typedefs/0.8.2/")))))))
 (lua-mode . ((indent-tabs-mode . t))))

S-expressions are pretty easy to parse, so I think Emacs setup ought to have similar behavior to VS Code setup (i.e. merging Lune's customizations with any existing ones). I'm leaning towards pulling in a crate for it; https://crates.io/crates/lexpr is pretty small and has good support for Emacs Lisp. But if you don't want to pull in a whole crate just for Emacs, I'm willing to roll our own parser built specifically for this use case.

All this being said - since it seems like we'll want to support other editors anyway (regardless of if they're Emacs or not), I'll get started on altering the setup command as you've described.

[CompeyDev]

If luau-lsp starts supporting .luaurc aliases - we can virtually support every editor luau-lsp works on with no additional effort.