bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

Tags: patch

I noticed Eglot currently sends the languageId "tex" in all TeX-derived
modes, which is not correct; it should be "latex", "bibtex", etc.

See the attached patch for a fix.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-eglot-server-programs-for-TeX-modes.patch --]
[-- Type: text/patch, Size: 1348 bytes --]

From 754127ad8bfa6ade7fe9a836df2a8bea75d711ea Mon Sep 17 00:00:00 2001
From: Augusto Stoffel <arstoffel@gmail.com>
Date: Sun, 28 Jul 2024 20:03:35 +0200
Subject: [PATCH] Fix eglot-server-programs for TeX modes

* lisp/progmodes/eglot.el (eglot-server-programs): Add a dedicated entry
to each TeX format, since the languageId passed to the server is derived
from it.
---
 lisp/progmodes/eglot.el | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 5845aff39b7..ea60b5d9a72 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -292,8 +292,11 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
-     . ,(eglot-alternatives '("digestif" "texlab")))
+    (plain-tex-mode "digestif")
+    (latex-mode . ,(eglot-alternatives '("digestif" "texlab")))
+    (context-mode "digestif")
+    (texinfo-mode "digestif")
+    (bibtex-mode . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
     (nix-mode . ,(eglot-alternatives '("nil" "rnix-lsp" "nixd")))
-- 
2.45.2

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Eli Zaretskii]

> From: Augusto Stoffel <arstoffel@gmail.com>
> Date: Sun, 28 Jul 2024 20:08:11 +0200
> 
> I noticed Eglot currently sends the languageId "tex" in all TeX-derived
> modes, which is not correct; it should be "latex", "bibtex", etc.
> 
> See the attached patch for a fix.

João, any objections to installing this on the emacs-30 release
branch?

> >From 754127ad8bfa6ade7fe9a836df2a8bea75d711ea Mon Sep 17 00:00:00 2001
> From: Augusto Stoffel <arstoffel@gmail.com>
> Date: Sun, 28 Jul 2024 20:03:35 +0200
> Subject: [PATCH] Fix eglot-server-programs for TeX modes
> 
> * lisp/progmodes/eglot.el (eglot-server-programs): Add a dedicated entry
> to each TeX format, since the languageId passed to the server is derived
> from it.
> ---
>  lisp/progmodes/eglot.el | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 5845aff39b7..ea60b5d9a72 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -292,8 +292,11 @@ eglot-server-programs
>      (scala-mode . ,(eglot-alternatives
>                      '("metals" "metals-emacs")))
>      (racket-mode . ("racket" "-l" "racket-langserver"))
> -    ((tex-mode context-mode texinfo-mode bibtex-mode)
> -     . ,(eglot-alternatives '("digestif" "texlab")))
> +    (plain-tex-mode "digestif")
> +    (latex-mode . ,(eglot-alternatives '("digestif" "texlab")))
> +    (context-mode "digestif")
> +    (texinfo-mode "digestif")
> +    (bibtex-mode . ,(eglot-alternatives '("digestif" "texlab")))
>      (erlang-mode . ("erlang_ls" "--transport" "stdio"))
>      ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
>      (nix-mode . ,(eglot-alternatives '("nil" "rnix-lsp" "nixd")))
> -- 
> 2.45.2
> 

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Sun, Jul 28, 2024 at 7:21 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > I noticed Eglot currently sends the languageId "tex" in all TeX-derived
> > modes, which is not correct; it should be "latex", "bibtex", etc.

If that's the goal, I think the :language-id cookie can help.
Has that been tried?  I think it's documented well enough here:

https://joaotavora.github.io/eglot/#index-eglot_002dserver_002dprograms

Also, is it an additional goal to prefer Augusto's 'digestif' sever here?
Unless I'm misreading it, this change seems to have the side
effect  that context-mode, texinfo-mode will no longer be served
by 'texlab' (by default) if the user has that installed.  Probably
plain-tex-mode could also be served by 'texlab'.

João

[-- Attachment #2: Type: text/html, Size: 1403 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

On Sun, 28 Jul 2024 at 22:31, João Távora wrote:

> Also, is it an additional goal to prefer Augusto's 'digestif' sever here?  

I haven't changed the order of preference in the patch.

> Unless I'm misreading it, this change seems to have the side 
> effect  that context-mode, texinfo-mode will no longer be served 
> by 'texlab' (by default) if the user has that installed.  Probably 
> plain-tex-mode could also be served by 'texlab'.

To the best of my knowledge (based on the documentation only; I haven't
tried it), texlab supports only latex and bibtex.  I'm not aware of
other servers that support plain TeX or Texinfo.

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Eli Zaretskii]

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  72343@debbugs.gnu.org
> Date: Mon, 29 Jul 2024 08:15:17 +0200
> 
> On Sun, 28 Jul 2024 at 22:31, João Távora wrote:
> 
> > Also, is it an additional goal to prefer Augusto's 'digestif' sever here?  
> 
> I haven't changed the order of preference in the patch.
> 
> > Unless I'm misreading it, this change seems to have the side 
> > effect  that context-mode, texinfo-mode will no longer be served 
> > by 'texlab' (by default) if the user has that installed.  Probably 
> > plain-tex-mode could also be served by 'texlab'.
> 
> To the best of my knowledge (based on the documentation only; I haven't
> tried it), texlab supports only latex and bibtex.  I'm not aware of
> other servers that support plain TeX or Texinfo.

Thanks, but what about the other part of João's questions, regarding
:language-id?

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

>
> Thanks, but what about the other part of João's questions, regarding
> :language-id?
>

That's precisely the point of the patch: make different derived modes of
tex-mode pass different language IDs to the server. Based on the
documentation João referred to, separate entries in eglot-server-programs
are needed in this case.

[-- Attachment #2: Type: text/html, Size: 800 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Tue, Jul 30, 2024, 19:20 Augusto Stoffel <arstoffel@gmail.com> wrote:

> Thanks, but what about the other part of João's questions, regarding
>> :language-id?
>>
>
> That's precisely the point of the patch: make different derived modes of
> tex-mode pass different language IDs to the server. Based on the
> documentation João referred to, separate entries in eglot-server-programs
> are needed in this case.
>

Have you tried the :language-id _keyword_ as explained in the documentation
I linked to? It should avoid the multiple entries.

João

>
>

[-- Attachment #2: Type: text/html, Size: 1629 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]

On Fri, Aug 2, 2024, 16:01 João Távora <joaotavora@gmail.com> wrote:

> [Did you mean to write only to me?]
>

Sorry, I'm copying the bug list now.

>
> On Fri, Aug 2, 2024 at 2:09 PM Augusto Stoffel <arstoffel@gmail.com>
> wrote:
>
> >> Have you tried the :language-id _keyword_ as explained in the
> documentation I linked to? It should avoid the multiple entries.
> > I had to look at the source code for some examples to see what you mean.
> Sure, that would avoid multiple entries.
>
> I'd think this sentence:
>
> > can be either a symbol of an Emacs major mode or
> > a list of the form (mode :language-id id), with mode being a major-mode
> symbol
> > and id a string that identifies the language to the server
>
> Would be enough.  It's very typical of Emacs variables to have these kinds
> of things.
> But feel free to propose some better documentation.  Maybe an example.
>
> > Still, it's unclear to me why one would prefer a solution that requires
> dabbling into language ids where it could be avoided.
>
> The problem you're trying to solve is related to language-id, as far as I
> understand.
> The "wrong" one is being sent right now, and you want the correct one to
> be sent.
> So it's not a question of dabbling, it's about sending the correct value.
> And there's a
> setting for affecting precisely that value, with no middle man, and it was
> designed
> for solving exactly your problem. Guessing the language-id  from the
> major-mode
> name is much worse than that, IMHO.
>

I think guessing "lang" from lang-mode is perfectly fine. The problem here
is that when eglot-server-program lists a server for tex-mode and the
server is selected for use in a derived mode such as latex-mode, the
guessed language is tex and not latex.


> Also it's a more concise solution.
>

For the reason noted above, there is no "concise solution" to choose, all
derived modes from tex-mode need to be mentioned explicitly in one way or
another (either to make the guess correct, or to provide manually a
language id).


Also it's more in-line with the rest of the variable,
> Also keeps texlab working (or not working) like it did before.  Also
> doesn't spam "digestif"
> multiple times in e-s-programs.
>

Fine, I can change the patch so that texlab will still run on modes that it
doesn't support (plain TeX and ConTeXt, etc). Just please confirm that this
is the behavior you prefer.


> So if you say it works and can actually test it, please use that instead.
>
> João
>

[-- Attachment #2: Type: text/html, Size: 4340 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Fri, Aug 2, 2024 at 4:13 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

>
> I think guessing "lang" from lang-mode is perfectly fine.
>

It's not.  And increasingly less so.  But you're right it should be
perfectly possible to ask a mode: "what programming language, if any, are
you for?".  But it's not.  It's a big discussion, I won't go over it.


> For the reason noted above, there is no "concise solution" to choose, all
> derived modes from tex-mode need to be mentioned explicitly in one way or
> another (either to make the guess correct, or to provide manually a
> language id).
>

The solution I gave is more concise in the number of elements of
eglot-server-programs.  And explicit in what it is doing.


> Fine, I can change the patch so that texlab will still run on modes that
> it doesn't support (plain TeX and ConTeXt, etc). Just please confirm that
> this is the behavior you prefer.
>

Yes, I prefer patches that do only their stated purpose and no other side
effects.

João

[-- Attachment #2: Type: text/html, Size: 1911 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 82 bytes --]

João,

The attached patch should satisfy the requisites you outlined above.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-eglot-server-programs-for-TeX-modes.patch --]
[-- Type: text/x-patch, Size: 1115 bytes --]

From 659a7caede34c3d885f58227aa02c3e062ff980b Mon Sep 17 00:00:00 2001
From: Augusto Stoffel <arstoffel@gmail.com>
Date: Tue, 6 Aug 2024 16:58:06 +0200
Subject: [PATCH] Fix eglot-server-programs for TeX modes

* lisp/progmodes/eglot.el (eglot-server-programs): Explicitly list modes
derived from tex-mode, so that the correct language id is guessed.
---
 lisp/progmodes/eglot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 31948a12d69..758bb9e9d3e 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -292,7 +292,7 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
+    ((plain-tex-mode doctex-mode latex-mode context-mode texinfo-mode bibtex-mode)
      . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
-- 
2.45.2

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

* lisp/progmodes/eglot.el (eglot-server-programs): Explicitly list modes
derived from tex-mode, so that the correct language id is guessed.

Won't it break when another mode is derived from it?  May I ask why
don't you just use the :language-id cookie which is designed
exactly for this -- to avoid a guess?

João

[-- Attachment #2: Type: text/html, Size: 446 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Tue, Aug 6, 2024, 17:34 João Távora <joaotavora@gmail.com> wrote:

> * lisp/progmodes/eglot.el (eglot-server-programs): Explicitly list modes
> derived from tex-mode, so that the correct language id is guessed.
>
> Won't it break when another mode is derived from it?
>

Not really, since such a hypothetical mode has no support from the servers.

May I ask why
> don't you just use the :language-id cookie which is designed
> exactly for this -- to avoid a guess?
>

That doesn't work, because apparently Eglot picks the language id of the
first mode in the listing that applies, which previously was the generic
tex-mode. That doesn't allow distinguishing latex and plain TeX. Again, the
issue is not guessing the language id string from the mode name, but rather
choosing the right mode symbol to guess from.

(Above I say apparently because this is not documented behavior, although
it's easy to check or verify reading the code.)

[-- Attachment #2: Type: text/html, Size: 1736 bytes --]

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Tue, Aug 6, 2024 at 4:45 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> On Tue, Aug 6, 2024, 17:34 João Távora <joaotavora@gmail.com> wrote:
>>
>> * lisp/progmodes/eglot.el (eglot-server-programs): Explicitly list modes
>> derived from tex-mode, so that the correct language id is guessed.
>>
>> Won't it break when another mode is derived from it?
> Not really, since such a hypothetical mode has no support from the servers.

No but it might represent a language that does! servers don't care modes,
they know about languages.  Furthermore, the same server, even
the same server connection might serve multiple documents in multiple
different languages.

> That doesn't work, because apparently Eglot picks the language id

Eglot pairs language ids with modes (plural).  This is what the internal
function eglot--lookup does.  In the same session, multiple language-id
maybe be picked depending on the LSP document being "opened".
So there's no "single pick" in general.

> of the first mode in the listing that applies, which previously was the generic tex-mode. That doesn't allow distinguishing latex and plain TeX. Again, the issue is not guessing the language id string from the mode name, but rather choosing the right mode symbol to guess from.

Previously, you suggested :language-id would work, but you didn't
want to "dabble" with it.  Now you seem to be saying it can't work
at all.

This may be an "XY Problem".  Can you state what exactly is the
end result you're trying to achieve (short of "writing thesis" or "fulfill
life goals") as someone who has never seen Eglot source code
before or has looked at LSP event logs to check what is being sent.
Tell me which server is installed and what file(s) in which major
modes you are visiting just before typing `M-x eglot`.  Then tell me
what happens to said server invocation (if any).  Focusing on the
goal  rather than the means may help me understand what you
want to achieve.

Thanks

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

On Tue,  6 Aug 2024 at 17:27, João Távora wrote:

> Eglot pairs language ids with modes (plural).  This is what the internal
> function eglot--lookup does.  In the same session, multiple language-id
> maybe be picked depending on the LSP document being "opened".
> So there's no "single pick" in general.

You don't need to explain that to me ;-).

> Previously, you suggested :language-id would work, but you didn't
> want to "dabble" with it.  Now you seem to be saying it can't work
> at all.

You're right.

> This may be an "XY Problem".  Can you state what exactly is the end
> result you're trying to achieve (short of "writing thesis" or "fulfill
> life goals") as someone who has never seen Eglot source code before or
> has looked at LSP event logs to check what is being sent.

I don't think there's an XY problem here, but anyway:

> Tell me which server is installed

This doesn't matter, as it's an Eglot issue.  Any TeX server will do.

> and what file(s) in which major modes you are visiting just before
> typing `M-x eglot`.

File x.tex in latex-mode and file y.tex in plain-tex-mode.

> Then tell me what happens to said server invocation (if any).

Currently, file x.tex is sent language id "tex" and file y.tex is sent
language id "tex".

> Focusing on the goal rather than the means may help me understand what
> you want to achieve.

What I want to achieve (or, if I may, what Eglot should do) in case it
wasn't clear yet, is: file x.tex is sent language id "latex" and file
y.tex is sent language id "plain-tex".

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Tue, Aug 6, 2024 at 5:38 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> > So there's no "single pick" in general.
> You don't need to explain that to me ;-).

It is you who alluded to a single pick, so I thought I had to.  Also
earlier you proposed multiple entries in eglot-server-programs, which
would impede this multi-language-per-session feature.  So I figured you
wouldn't be familiar with it.

> What I want to achieve (or, if I may, what Eglot should do) in case it
> wasn't clear yet, is: file x.tex is sent language id "latex" and file
> y.tex is sent language id "plain-tex".

Indeed it wasn't clear, so I'm very glad I asked.  I don't see
"plain-tex" in the list over at

  https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

I just see "tex" and "latex" and "bibtex".

Now, if you want "latex" to be sent for x.tex (in latex-mode) and "tex"
to be sent for x.tex (in plain-tex-mode), there is this possibility.

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 5845aff39b7..2695aa93ffe 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -292,7 +292,7 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
+    ((latex-mode tex-mode context-mode texinfo-mode bibtex-mode)
      . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))

No need to mention plain-tex-mode at all. The "guess" logic will work
(though I still recommend :language-id cookie).

You might notice this will only work for a particular sequence of
invocations (specifically starting the server with the latex-mode file
open, then opening other files in plain-tex-mode).

But it won't for many other cases.  The fact that Emacs models
latex-mode as a descendent of tex-mode is something Eglot can't do
anything about.  It means that Emacs thinks that that every LaTex
program is a TeX program at least at some syntactic level (is this true?
no idea).  So as soon as you have the two files open, M-x
eglot-reconnect will send "tex" for _both_.  Which, according to Emacs's
view of the world, isn't wrong.

This has happened before with the js/json mode and has been fixed in the
mode relations.  I think bug#67463.  The same idea thatfixed it there
could be applied here.

Anyway, if plain-tex-mode is an attempt to fix this, by making a core
mode that is not directly related to latex-mode, then I think it should
appear in the list, but then :language-id set to to "tex".

But I see plain-tex-mode also inherits from tex-mode, so the fundamental
problem remains. Unless you remove tex-mode from the list (which is what
you did).  But then outside descendents of tex-mode would be cut off,
which is what I warned about.

I do think that's the lesser of two evils though.  So anyway this is my
suggestion:

@@ -292,7 +292,7 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
+    ((latex-mode (plain-tex-mode :language-id "tex") context-mode
texinfo-mode bibtex-mode)
      . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))

In theory, this could also be fixed by keeping tex-mode in there, and
then adjusting Eglot's heuristic, by ranking the potential ancestors and
selecting the closest one, in 'eglot--languageId'.  Could be tricky or
could be easy, feel free to give it a shot.

Yet another idea is to not reorder modes at all in 'eglot--lookup-mode'
and use an explicit order to express this ranking.  I admit I don't
remember what the reordering idea (main-mode-sym is the local var name)
is for.  it couldprecede the multiple-language-ids feature.  Or it could
be essential for some other thing: testing would be needed.

> This doesn't matter, as it's an Eglot issue.  Any TeX server will do.

This is not established, at least not yet.  You are requesting for a
"plain-tex" LSP languageId property to be sent and that is outside the
spec as far as I can tell from reading the spec.  Maybe your digestif
server supports and likes it, though.  But it might break "texlab" for
all I know.  Even the fact that "tex" is all that's being sent at the
moment may or may not be a bug -- only LaTex/Tex specialists can say
that.  And certainly a capable enough language server, which is tasked
with analysing a file syntactically, can do much the same as our own
tex-mode.el and figure out the correct language from the contents.
Might do it better than Emacs.

That said, if you really want to send "plain-tex", then there are two
options.  You can change your user value of eglot-server-programs,
obviously.  Or you can confirm with "texlab" that they don't mind, in
which case -- but only in that case -- your latest patch is acceptable.

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

On Tue,  6 Aug 2024 at 19:08, João Távora wrote:

> On Tue, Aug 6, 2024 at 5:38 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
>> > So there's no "single pick" in general.
>> You don't need to explain that to me ;-).
>
> It is you who alluded to a single pick, so I thought I had to.  Also
> earlier you proposed multiple entries in eglot-server-programs, which
> would impede this multi-language-per-session feature.>  So I figured you
> wouldn't be familiar with it.

Fair enough.

>> What I want to achieve (or, if I may, what Eglot should do) in case it
>> wasn't clear yet, is: file x.tex is sent language id "latex" and file
>> y.tex is sent language id "plain-tex".
>
> Indeed it wasn't clear, so I'm very glad I asked.  I don't see
> "plain-tex" in the list over at
>
>   https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
>
> I just see "tex" and "latex" and "bibtex".

I know about the list, but unfortunately "tex" as a language id makes no
sense.  It's like saying a program is written in "lisp" without saying
which Lisp dialect.

> But it won't for many other cases.  The fact that Emacs models
> latex-mode as a descendent of tex-mode is something Eglot can't do
> anything about.  It means that Emacs thinks that that every LaTex
> program is a TeX program at least at some syntactic level (is this true?
> no idea).

Again, every TeX program belongs to a specific dialect: plain TeX, LaTeX
and ConTeXt being the main ones.  Accordingly, tex-mode is not a real
major mode; it's just an "abstract base mode" from which the actual TeX
modes derive (see the docstring for details).

> I do think that's the lesser of two evils though.  So anyway this is my
> suggestion:
>
> @@ -292,7 +292,7 @@ eglot-server-programs
>      (scala-mode . ,(eglot-alternatives
>                      '("metals" "metals-emacs")))
>      (racket-mode . ("racket" "-l" "racket-langserver"))
> -    ((tex-mode context-mode texinfo-mode bibtex-mode)
> +    ((latex-mode (plain-tex-mode :language-id "tex") context-mode
> texinfo-mode bibtex-mode)
>       . ,(eglot-alternatives '("digestif" "texlab")))
>      (erlang-mode . ("erlang_ls" "--transport" "stdio"))
>      ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))

So again, for the reason above, I wouldn't do what you suggest here.

> In theory, this could also be fixed by keeping tex-mode in there, and
> then adjusting Eglot's heuristic, by ranking the potential ancestors and
> selecting the closest one, in 'eglot--languageId'.  Could be tricky or
> could be easy, feel free to give it a shot.

(The status quo is already way too complicated, and this doesn't sound
like an improvement in that regard...)

> Yet another idea is to not reorder modes at all in 'eglot--lookup-mode'
> and use an explicit order to express this ranking.  I admit I don't
> remember what the reordering idea (main-mode-sym is the local var name)
> is for.  it couldprecede the multiple-language-ids feature.  Or it could
> be essential for some other thing: testing would be needed.
>
>> This doesn't matter, as it's an Eglot issue.  Any TeX server will do.
>
> This is not established, at least not yet.  You are requesting for a
> "plain-tex" LSP languageId property to be sent and that is outside the
> spec as far as I can tell from reading the spec.  Maybe your digestif
> server supports and likes it, though.  But it might break "texlab" for
> all I know.

Note also that the LSP spec says nothing about ConTeXt or Texinfo.
Moreover, texlab only supports latex and bibtex.

> Even the fact that "tex" is all that's being sent at the
> moment may or may not be a bug -- only LaTex/Tex specialists can say
> that.  And certainly a capable enough language server, which is tasked
> with analysing a file syntactically, can do much the same as our own
> tex-mode.el and figure out the correct language from the contents.
> Might do it better than Emacs.

That's true, and in fact it's true all languages.  So a server could as
well ignore the language id and deduce it on its own -- except for the
caveat that ultimately the user might know better and it's useful to
rely on the user's choice of major mode / language id.

> That said, if you really want to send "plain-tex", then there are two
> options.  You can change your user value of eglot-server-programs,
> obviously.  Or you can confirm with "texlab" that they don't mind, in
> which case -- but only in that case -- your latest patch is acceptable.

I didn't ask but I don't see what could go wrong, given that texlab is
for latex and bibtex only.

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Tue, Aug 6, 2024 at 7:48PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> I know about the list, but unfortunately "tex" as a language id makes no
> sense.  It's like saying a program is written in "lisp" without saying
> which Lisp dialect.

In that example, the "lisp" identifier is probably enough to derive that
the file in question is a tree of Lisp forms, much like lisp-data-mode
treats Lisp.

> Again, every TeX program belongs to a specific dialect: plain TeX, LaTeX
> and ConTeXt being the main ones.  Accordingly, tex-mode is not a real
> major mode; it's just an "abstract base mode" from which the actual TeX
> modes derive (see the docstring for details).

OK.  That doesn't seem to necessitate that the tex-mode is a parent of
latex-mode or plain-tex-mode.  [Also, I see no need to write "again" for
a point that you've just made once].

> except for the
> caveat that ultimately the user might know better and it's useful to
> rely on the user's choice of major mode / language id.

How so a "caveat" if eglot-server-programs is a user-customizable
variable where the user can explicitly set whatever languageId she
wants??

> I didn't ask but I don't see what could go wrong, given that texlab is
> for latex and bibtex only.

It would be safer to ask.  As far as I am concerned, currently we send
"tex" to texlab and it likes it, or at least doesn't dislike it.  For
all we know, or at least, I know.  "tex" is in the LSP spec, "plain-tex" is
not.  Then I suggest -- for this specific problem:

1. Asking for the spec to correct itself
2. Interpreting "tex" as really "plain-tex" in your server.  You should
   probably be doing that anyway for old Eglot versions or  any client
   who follows the spec.
3. Ignoring my advice and sending "plain-tex" from Eglot anyway
(i.e. installing your patch without :language-id)

For the _other_ orthogonal problem, I suggest:

1. Doing the simplification in eglot--lookup-mode, and then make the
left-hand-side list be like

(latex-mode (plain-tex-mode :language-id "tex") ; see previous problem
            also-derived-from-tex-mode
            tex-mode
            not-derived-from-tex-mode)

Note that tex-mode is kept there, so this is compatible with any
tex-mode derivations we don't know of.  Some testing required, of
course.  I can perform some of it for C/C++ modes.

This patch is after my sig.  It also fixes a broken docstring.

2. Doing the ranking in eglot--languageID
3. fixing tex-mode's relation with its children modes

João

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 5845aff39b7..beff9b17a25 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -292,7 +292,7 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
+    ((latex-mode (plain-tex-mode :language-id "tex") tex-mode
context-mode texinfo-mode bibtex-mode)
      . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
@@ -1238,28 +1238,23 @@ eglot--lookup-mode
   "Lookup `eglot-server-programs' for MODE.
 Return (LANGUAGES . CONTACT-PROXY).

-MANAGED-MODES is a list with MODE as its first element.
-Subsequent elements are other major modes also potentially
-managed by the server that is to manage MODE.
-
-LANGUAGE-IDS is a list of the same length as MANAGED-MODES.  Each
-elem is derived from the corresponding mode name, if not
-specified in `eglot-server-programs' (which see).
+LANGUAGES is a list ((MANAGED-MODE . LANGUAGE-ID) ...).  MANAGED-MODE is
+a major mode also potentially managed by the server that is to manage
+MODE.  LANGUAGE-ID is string identifying the language to the LSP server.
+It's derived from the corresponding mode name, or explicitly specified
+in `eglot-server-programs' (which see).

 CONTACT-PROXY is the value of the corresponding
 `eglot-server-programs' entry."
-  (cl-flet ((languages (main-mode-sym specs)
-              (let* ((res
-                      (mapcar (jsonrpc-lambda (sym &key language-id
&allow-other-keys)
-                                (cons sym
-                                      (or language-id
-                                          (or (get sym 'eglot-language-id)
-                                              (replace-regexp-in-string
-                                               "\\(?:-ts\\)?-mode$" ""
-                                               (symbol-name sym))))))
-                              specs))
-                     (head (cl-find main-mode-sym res :key #'car)))
-                (cons head (delq head res)))))
+  (cl-flet ((languages (specs)
+              (mapcar (jsonrpc-lambda (sym &key language-id &allow-other-keys)
+                        (cons sym
+                              (or language-id
+                                  (or (get sym 'eglot-language-id)
+                                      (replace-regexp-in-string
+                                       "\\(?:-ts\\)?-mode$" ""
+                                       (symbol-name sym))))))
+                      specs)))
     (cl-loop
      for (modes . contact) in eglot-server-programs
      for specs = (mapcar #'eglot--ensure-list
@@ -1268,7 +1263,7 @@ eglot--lookup-mode
      thereis (cl-some (lambda (spec)
                         (cl-destructuring-bind (sym &key
&allow-other-keys) spec
                           (and (provided-mode-derived-p mode sym)
-                               (cons (languages sym specs) contact))))
+                               (cons (languages specs) contact))))
                       specs))))

 (defun eglot--guess-contact (&optional interactive)

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

On Tue,  6 Aug 2024 at 23:52, João Távora wrote:

> On Tue, Aug 6, 2024 at 7:48PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
>> I know about the list, but unfortunately "tex" as a language id makes no
>> sense.  It's like saying a program is written in "lisp" without saying
>> which Lisp dialect.
>
> In that example, the "lisp" identifier is probably enough to derive that
> the file in question is a tree of Lisp forms, much like lisp-data-mode
> treats Lisp.

Sure, but how is that useful information for a language server?

>> Again, every TeX program belongs to a specific dialect: plain TeX, LaTeX
>> and ConTeXt being the main ones.  Accordingly, tex-mode is not a real
>> major mode; it's just an "abstract base mode" from which the actual TeX
>> modes derive (see the docstring for details).
>
> OK.  That doesn't seem to necessitate that the tex-mode is a parent of
> latex-mode or plain-tex-mode.  [Also, I see no need to write "again" for
> a point that you've just made once].
>
>> except for the
>> caveat that ultimately the user might know better and it's useful to
>> rely on the user's choice of major mode / language id.
>
> How so a "caveat" if eglot-server-programs is a user-customizable
> variable where the user can explicitly set whatever languageId she
> wants??

Relegating to users the task of debugging language ids doesn't sound
very user-friendly...

>> I didn't ask but I don't see what could go wrong, given that texlab is
>> for latex and bibtex only.
>
> It would be safer to ask.  As far as I am concerned, currently we send
> "tex" to texlab and it likes it, or at least doesn't dislike it.

Yes, and Digestif is also fine with it.  Clearly when seeing the "tex"
language id, both servers fall back to "latex", which is by far the most
common TeX dialect.

(For the record, the only thing that's currently broken in the
Eglot-Digestif interaction is the plain TeX case.)

>  For all we know, or at least, I know.  "tex" is in the LSP spec,
> "plain-tex" is not.  Then I suggest -- for this specific problem:
>
> 1. Asking for the spec to correct itself

Productivity-wise I don't have a very good experience talking to them
(even less so than on the Emacs mailing lists...), so I will pass on
that one.

> 2. Interpreting "tex" as really "plain-tex" in your server.  You should
>    probably be doing that anyway for old Eglot versions or  any client
>    who follows the spec.

This would definitely be wrong, since editors (including the current
version of Eglot but also others e.g. vim), send out the "tex" language
id when they mean "latex".

What I _could_ do is to interpret "tex" to mean "some kind of tex" and
trigger a heuristic to guess the specific dialect.  (This is a
TODO-comment since the first versions of Digestif, so the "could" in the
previous sentence has a purely hypothetical connotation.)

> 3. Ignoring my advice and sending "plain-tex" from Eglot anyway
> (i.e. installing your patch without :language-id)

You're clearly against this so it is not going to happen, but I hope I
managed to explain to you why I would have done it.

> For the _other_ orthogonal problem, I suggest:
>
> 1. Doing the simplification in eglot--lookup-mode, and then make the
> left-hand-side list be like
>
> (latex-mode (plain-tex-mode :language-id "tex") ; see previous problem
>             also-derived-from-tex-mode
>             tex-mode
>             not-derived-from-tex-mode)
>
> Note that tex-mode is kept there, so this is compatible with any
> tex-mode derivations we don't know of.  Some testing required, of
> course.  I can perform some of it for C/C++ modes.
>
> This patch is after my sig.  It also fixes a broken docstring.
>
> 2. Doing the ranking in eglot--languageID
> 3. fixing tex-mode's relation with its children modes
>
> João
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 5845aff39b7..beff9b17a25 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -292,7 +292,7 @@ eglot-server-programs
>      (scala-mode . ,(eglot-alternatives
>                      '("metals" "metals-emacs")))
>      (racket-mode . ("racket" "-l" "racket-langserver"))
> -    ((tex-mode context-mode texinfo-mode bibtex-mode)
> +    ((latex-mode (plain-tex-mode :language-id "tex") tex-mode
> context-mode texinfo-mode bibtex-mode)

Since you want to send "tex" language id for plain tex, the following
suffices:

    ((latex-mode tex-mode context-mode texinfo-mode bibtex-mode)

>       . ,(eglot-alternatives '("digestif" "texlab")))
>      (erlang-mode . ("erlang_ls" "--transport" "stdio"))
>      ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
> @@ -1238,28 +1238,23 @@ eglot--lookup-mode
>    "Lookup `eglot-server-programs' for MODE.
>  Return (LANGUAGES . CONTACT-PROXY).
>
> -MANAGED-MODES is a list with MODE as its first element.
> -Subsequent elements are other major modes also potentially
> -managed by the server that is to manage MODE.
> -
> -LANGUAGE-IDS is a list of the same length as MANAGED-MODES.  Each
> -elem is derived from the corresponding mode name, if not
> -specified in `eglot-server-programs' (which see).
> +LANGUAGES is a list ((MANAGED-MODE . LANGUAGE-ID) ...).  MANAGED-MODE is
> +a major mode also potentially managed by the server that is to manage
> +MODE.  LANGUAGE-ID is string identifying the language to the LSP server.
> +It's derived from the corresponding mode name, or explicitly specified
> +in `eglot-server-programs' (which see).
>
>  CONTACT-PROXY is the value of the corresponding
>  `eglot-server-programs' entry."
> -  (cl-flet ((languages (main-mode-sym specs)
> -              (let* ((res
> -                      (mapcar (jsonrpc-lambda (sym &key language-id
> &allow-other-keys)
> -                                (cons sym
> -                                      (or language-id
> -                                          (or (get sym 'eglot-language-id)
> -                                              (replace-regexp-in-string
> -                                               "\\(?:-ts\\)?-mode$" ""
> -                                               (symbol-name sym))))))
> -                              specs))
> -                     (head (cl-find main-mode-sym res :key #'car)))
> -                (cons head (delq head res)))))
> +  (cl-flet ((languages (specs)
> +              (mapcar (jsonrpc-lambda (sym &key language-id &allow-other-keys)
> +                        (cons sym
> +                              (or language-id
> +                                  (or (get sym 'eglot-language-id)
> +                                      (replace-regexp-in-string
> +                                       "\\(?:-ts\\)?-mode$" ""
> +                                       (symbol-name sym))))))
> +                      specs)))
>      (cl-loop
>       for (modes . contact) in eglot-server-programs
>       for specs = (mapcar #'eglot--ensure-list
> @@ -1268,7 +1263,7 @@ eglot--lookup-mode
>       thereis (cl-some (lambda (spec)
>                          (cl-destructuring-bind (sym &key
> &allow-other-keys) spec
>                            (and (provided-mode-derived-p mode sym)
> -                               (cons (languages sym specs) contact))))
> +                               (cons (languages specs) contact))))
>                        specs))))
>
>  (defun eglot--guess-contact (&optional interactive)

I have no opinion on that one, except to say that it looks really
complicated, although that's probably out of necessity.

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Wed, Aug 7, 2024 at 8:02 AM Augusto Stoffel <arstoffel@gmail.com> wrote:

> Sure, but how is that useful information for a language server?

Fairly useful. If someone tells me this upfront about some stream of
data they're about to send I know I can use a very simple parser.
Or I can reject it altogether if I don't like "lisp" for some reason.
If working on a language server multiplexer, for example
that information is possibly enough to know where to redirect the
didOpen.

> Relegating to users the task of debugging language ids doesn't sound
> very user-friendly...

It was you, not me, who talked about "ultimately the user". So ultimately
the user has control over things, always has had.

> (For the record, the only thing that's currently broken in the
> Eglot-Digestif interaction is the plain TeX case.)

Interesting, this is the X problem I was looking for.

> > 3. Ignoring my advice and sending "plain-tex" from Eglot anyway
> > (i.e. installing your patch without :language-id)
>
> You're clearly against this so it is not going to happen, but I hope I
> managed to explain to you why I would have done it.

Ultimately, I have to leave room for a pragmatic decision from
domain experts,  even if it violates the spec.  I'm just trying to
understand the angles and judge the probability of breakage
later on.

> > For the _other_ orthogonal problem, I suggest:
> >      (racket-mode . ("racket" "-l" "racket-langserver"))
> > -    ((tex-mode context-mode texinfo-mode bibtex-mode)
> > +    ((latex-mode (plain-tex-mode :language-id "tex") tex-mode
> > context-mode texinfo-mode bibtex-mode)
>
> Since you want to send "tex" language id for plain tex, the following
> suffices:
>
>     ((latex-mode tex-mode context-mode texinfo-mode bibtex-mode)

Again, I don't "want" to (see above for the reasons).  This patch
is concerned with the orthogonal requirement of keeping tex-mode
(and not removing it as you proposed)

So:

* please make up your mind, i.e. make a (possibly overriding) decision
  whether sending off-spec "plain-tex" for tex-mode is really what is
  needed.

* whatever your decision, keep 'tex-mode' in the list.

* help me test the patch below by checking that problem X is now
  solved and now new problem Z has popped up.

> >  (defun eglot--guess-contact (&optional interactive)
>
> I have no opinion on that one, except to say that it looks really
> complicated, although that's probably out of necessity.

OK, then don't bother giving an opinion, but how can it look
complicated?? It removes cyclomatic complexity (and lines of code)
from the program.

João

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Wed,  7 Aug 2024 at 09:47, João Távora wrote:

> On Wed, Aug 7, 2024 at 8:02 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
>> Sure, but how is that useful information for a language server?
>
> Fairly useful. If someone tells me this upfront about some stream of
> data they're about to send I know I can use a very simple parser.
> Or I can reject it altogether if I don't like "lisp" for some reason.
> If working on a language server multiplexer, for example
> that information is possibly enough to know where to redirect the
> didOpen.

(That's a tangent, but in practice your multiplexer will be required to
know what to do with more specific language ids such as "common-lisp" or
"scheme".  So I still see no advantage in sending less specific language
ids.)

>> > 3. Ignoring my advice and sending "plain-tex" from Eglot anyway
>> > (i.e. installing your patch without :language-id)
>>
>> You're clearly against this so it is not going to happen, but I hope I
>> managed to explain to you why I would have done it.
>
> Ultimately, I have to leave room for a pragmatic decision from
> domain experts,  even if it violates the spec.  I'm just trying to
> understand the angles and judge the probability of breakage
> later on.
>
>> > For the _other_ orthogonal problem, I suggest:
>> >      (racket-mode . ("racket" "-l" "racket-langserver"))
>> > -    ((tex-mode context-mode texinfo-mode bibtex-mode)
>> > +    ((latex-mode (plain-tex-mode :language-id "tex") tex-mode
>> > context-mode texinfo-mode bibtex-mode)
>>
>> Since you want to send "tex" language id for plain tex, the following
>> suffices:
>>
>>     ((latex-mode tex-mode context-mode texinfo-mode bibtex-mode)
>
> Again, I don't "want" to (see above for the reasons).  This patch
> is concerned with the orthogonal requirement of keeping tex-mode
> (and not removing it as you proposed)
>
> So:
>
> * please make up your mind, i.e. make a (possibly overriding) decision
>   whether sending off-spec "plain-tex" for tex-mode is really what is
>   needed.
>
> * whatever your decision, keep 'tex-mode' in the list.
>
> * help me test the patch below by checking that problem X is now
>   solved and now new problem Z has popped up.

So this is my final suggestion then:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-eglot-server-programs-for-TeX-modes.patch --]
[-- Type: text/x-patch, Size: 1112 bytes --]

From 22b876a153e8bbede02804e374c5c234213181f2 Mon Sep 17 00:00:00 2001
From: Augusto Stoffel <arstoffel@gmail.com>
Date: Tue, 6 Aug 2024 16:58:06 +0200
Subject: [PATCH] Fix eglot-server-programs for TeX modes

* lisp/progmodes/eglot.el (eglot-server-programs): Explicitly list modes
derived from tex-mode, so that the correct language id is guessed.
---
 lisp/progmodes/eglot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 31948a12d69..67bd26f6f02 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -292,7 +292,7 @@ eglot-server-programs
     (scala-mode . ,(eglot-alternatives
                     '("metals" "metals-emacs")))
     (racket-mode . ("racket" "-l" "racket-langserver"))
-    ((tex-mode context-mode texinfo-mode bibtex-mode)
+    ((latex-mode plain-tex-mode context-mode texinfo-mode bibtex-mode tex-mode)
      . ,(eglot-alternatives '("digestif" "texlab")))
     (erlang-mode . ("erlang_ls" "--transport" "stdio"))
     ((yaml-ts-mode yaml-mode) . ("yaml-language-server" "--stdio"))
-- 
2.45.2


[-- Attachment #3: Type: text/plain, Size: 176 bytes --]


It solves problem X and my estimated breakage probability is
"infinitesimally small" since it works for LaTeX, BibTeX and ConTeXt and
all other dialects are very very fringe.

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Wed, Aug 7, 2024 at 10:18 AM Augusto Stoffel <arstoffel@gmail.com> wrote:

> "scheme".  So I still see no advantage in sending less specific language
> ids.)

It's at the very least useful to know to _not_ send that file to the c/c++
server.

> So this is my final suggestion then:
>
>
> It solves problem X and my estimated breakage probability is
> "infinitesimally small" since it works for LaTeX, BibTeX and ConTeXt and
> all other dialects are very very fringe.

Alright, and yes it even works without the simplification fix (that I'll
also push, anyway).

João

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Augusto Stoffel]

On Tue,  6 Aug 2024 at 19:08, João Távora wrote:

> Also earlier you proposed multiple entries in eglot-server-programs,
> which would impede this multi-language-per-session feature.  So I
> figured you wouldn't be familiar with it.

By the way, if Eglot relies on that for the multi-language-per-session
feature, then such feature would be incompatible with an
`eglot-server-program' variable (note the singular) that major modes can
set independently as a buffer-local variable.

Wouldn't it make more sense to reuse a running server if a new one would
be started at the same directory and with the same command line
arguments?

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Wed, Aug 7, 2024 at 7:33 AM Augusto Stoffel <arstoffel@gmail.com> wrote:

> By the way, if Eglot relies on that for the multi-language-per-session
> feature, then such feature would be incompatible with an
> `eglot-server-program' variable (note the singular) that major modes can
> set independently as a buffer-local variable.

Yes, I think I mentioned this before. Depends on how you design the feature.
And you can't just defenestrate eglot-server-programs, you have to keep
backward compatibility to it.

> Wouldn't it make more sense to reuse a running server if a new one would
> be started at the same directory and with the same command line
> arguments?

The feature hasn't been designed so I don't understand the comparative
"more".  But yes, it could make a lot of sense.  But instead of "directory",
"project".  And instead of "command line arguments", "contact".

CCing Philip who proposed working on this.
João

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> On Wed, Aug 7, 2024 at 7:33 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
>> By the way, if Eglot relies on that for the multi-language-per-session
>> feature, then such feature would be incompatible with an
>> `eglot-server-program' variable (note the singular) that major modes can
>> set independently as a buffer-local variable.
>
> Yes, I think I mentioned this before. Depends on how you design the feature.
> And you can't just defenestrate eglot-server-programs, you have to keep
> backward compatibility to it.
>
>> Wouldn't it make more sense to reuse a running server if a new one would
>> be started at the same directory and with the same command line
>> arguments?
>
> The feature hasn't been designed so I don't understand the comparative
> "more".  But yes, it could make a lot of sense.  But instead of "directory",
> "project".  And instead of "command line arguments", "contact".
>
> CCing Philip who proposed working on this.

FWIW I have a number of other things on my todo list, and this isn't on
the top for now.  So unless I can help and advise someone, this is going
to take a while.

> João

-- 
	Philip Kaludercic on peregrine

bug#72343: [PATCH] Fix eglot-server-programs for TeX modes

[João Távora]

On Mon, Aug 12, 2024 at 5:37 PM Philip Kaludercic <philipk@posteo.net> wrote:
> FWIW I have a number of other things on my todo list, and this isn't on
> the top for now.  So unless I can help and advise someone, this is going
> to take a while.

I'm not going to rush you or anyone. But since you proposed this this
in the past,
 I thought  you'd want to be aware of Augusto's observation.

João