Re: Extending define-derived-mode

[Theodor Thornhill]

On 30 May 2023 07:16:49 CEST, Yuan Fu <casouri@gmail.com> wrote:
>When we were adding tree-sitter modes a couple of month ago, it was
>clear that the current major mode model needs some upgrade, I’d like
>to discuss the things we need and how can we address them.

Thanks for bringing this up!

I'll quickly just add one more thing, and respond more thoroughly in a 
different mail:


Maybe we can consider another abstraction to cover the following:

 - configure what set of modes to use for a given language
 - set choice of diagnostic tool (flymake/flycheck etc)
 - set LSP client implementation with config to use
 - project based configs
 - separate mode name and implementation

I posted some time ago a simple idea covering this, and maybe the time is now 
to revisit this idea? People seem to like doom Emacs/spacemacs etc, so their 
idea of "layers" may be a nice route to consider.

We can supply some DSL with preconfigured settings, and add extensible 
functionalities.

Maybe something like:

(define-layer 'javascript-mode
  :mode 'treesit
  :enabled-in '(".js", ".mjs")
  :diagnostic-backend 'flymake
  :lsp-client 'lsp-mode ;; default is 'eglot
  :project '(:root-function #'some-rootfinder-fn)
  :other-stuff '(eslint json-something nvm))

This may seem only tangentially related to your email, but I believe it is, in 
that mode inheritance touches the "the first language mode implementation owns 
the namespace"-problem.
 
WDYT?

Theo