unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Augusto Stoffel <arstoffel@gmail.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 72343@debbugs.gnu.org
Subject: bug#72343: [PATCH] Fix eglot-server-programs for TeX modes
Date: Wed, 07 Aug 2024 11:17:58 +0200	[thread overview]
Message-ID: <87y158pu7t.fsf@gmail.com> (raw)
In-Reply-To: <CALDnm530v0p=b+29p9p==6kHQ+D1OpRBMZPqsB5BFz3o=vr4NQ@mail.gmail.com> ("João Távora"'s message of "Wed, 7 Aug 2024 09:47:59 +0100")

[-- 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.

  reply	other threads:[~2024-08-07  9:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-28 18:08 bug#72343: [PATCH] Fix eglot-server-programs for TeX modes Augusto Stoffel
2024-07-28 18:20 ` Eli Zaretskii
2024-07-28 21:31   ` João Távora
2024-07-29  6:15     ` Augusto Stoffel
2024-07-29 11:26       ` Eli Zaretskii
2024-07-30 18:20         ` Augusto Stoffel
2024-07-30 20:29           ` João Távora
     [not found]             ` <CAHixrvYMZTMRSpixw2CAkdx_b+hdPZDkB7s+1X1sUX4E7jPWHw@mail.gmail.com>
     [not found]               ` <CALDnm50sjTEnSxJ3Rzna3pets2bjHnVF=6vix1gM_54+VoHNvQ@mail.gmail.com>
2024-08-02 15:13                 ` Augusto Stoffel
2024-08-02 15:29                   ` João Távora
2024-08-06 15:04                     ` Augusto Stoffel
2024-08-06 15:34                       ` João Távora
2024-08-06 15:45                         ` Augusto Stoffel
2024-08-06 16:27                           ` João Távora
2024-08-06 16:38                             ` Augusto Stoffel
2024-08-06 18:08                               ` João Távora
2024-08-06 18:48                                 ` Augusto Stoffel
2024-08-06 22:52                                   ` João Távora
2024-08-07  7:02                                     ` Augusto Stoffel
2024-08-07  8:47                                       ` João Távora
2024-08-07  9:17                                         ` Augusto Stoffel [this message]
2024-08-07 13:17                                           ` João Távora
2024-08-07  6:33                                 ` Augusto Stoffel
2024-08-07 13:23                                   ` João Távora
2024-08-12 16:37                                     ` Philip Kaludercic
2024-08-12 16:53                                       ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y158pu7t.fsf@gmail.com \
    --to=arstoffel@gmail.com \
    --cc=72343@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).