GNU bug report logs - #76423
Major-mode provided LSP server for Eglot

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>, 76423 <at> debbugs.gnu.org
Subject: bug#76423: Major-mode provided LSP server for Eglot
Date: Fri, 21 Feb 2025 09:49:32 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> As it stands, looking at the `eval-after-load' code for bicep-ts-mode,
>> I wonder if it is really a "funny dance" or just the way it should be
>> until past decisions are revisited (but not by me :-))
>
> Having to play such games just to update some kind of central DB of all
> the modes seems really silly when the DB is only ever consulted for the
> major mode of current buffer.

Let see:

- Is it so?  Something is only really "silly" if it serves no purpose
  beyond its exhuberance or idiosyncrasy.  If you were to take away the
  "silly" centralized e-s-programs db now -- like someone recently
  naively suggested -- you would break eglot.el as loaded in older
  Emacsen, and that would upset a fair number of people.  Of course, you
  could move it into compat.el (no longer in use by Eglot) and maintain
  it there.  You would only be increasing the level of silliness.

- Everything in Emacs happens in a buffer and in a major mode, and the
  only useful hookage we get to set things up before minor modes kick in
  is tied to those, so any db -- centralized or not -- is going to be
  consulted within those boundaries.

- LSP stands for Language Server Protocol, and its mapped to the concept
  of "language".  As is much other tooling outside the Emacs ecosystem
  (frequently utterly uninterested in what a "major mode" is).
  Snippets, syntax highlighters, linters etc.  The fact that there is no
  easy way to "run this bit of code if the current buffer is in this
  language" is IMO a very glaring omission in an editor which is
  frequently used for source code.

- Your patch would probably work for biceps-ts-mode and whatever
  "Biceps" is but when dealing with major modes that must cooperate with
  each other (c-mode and c-ts-mode ... json-mode and json-js-mode,
  tuareg-mode and ocaml-mode, many others) etc, it would lead to
  repetition and duplication: a newcomer mode would always need to beg
  the maintainers of other major modes to reference it.  Dead modes
  would linger around scattered.  Duplication, at least in my book,
  always tips the pendulum of silliness towards it.

So, again, until past decisions are revisited (that bug#somesuch of 1/2
years ago) and there exists a way for a major mode to say "I serve this
language and I want to suggest a language server for it so that other
modes that also serve it can use it" I think the current state of
affairs is the best we have.

What real problem is there in the current biceps-ts-mode.el code?
Doesn't it work?  There is no duplication.  It's a DRY and idempotent
statement.  It is a dislike of eval-after-load?  In that case, if
loading order is the problem, maybe `add-hook` semantics (which solves
the same problem by other means) could be leveraged.  But unless a real
problem (and a real solution) can be presented just calling out the
formal exhuberance of a solution is no real argument for change.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.