GNU bug report logs - #62907
Eglot does not start managing LaTeX buffer despite reporting successful connection

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: João Távora <joaotavora <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#62907: closed (Eglot does not start managing LaTeX buffer
 despite reporting successful connection)
Date: Wed, 19 Apr 2023 00:10:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 19 Apr 2023 01:10:57 +0100
with message-id <CALDnm52K6w2Co2pPyj2ouiitwKq6Lyg5YLboH2WvGQn4ZzXNmw <at> mail.gmail.com>
and subject line Re: bug#62907: Eglot does not start managing LaTeX buffer despite reporting successful connection
has caused the debbugs.gnu.org bug report #62907,
regarding Eglot does not start managing LaTeX buffer despite reporting successful connection
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
62907: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62907
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Michael Eliachevitch <m.eliachevitch <at> posteo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Eglot does not start managing LaTeX buffer despite reporting
 successful connection
Date: Mon, 17 Apr 2023 15:21:12 +0000

[Message part 3 (text/plain, inline)]

User-agent: mu4e 1.11.2; emacs 30.0.50

When I run `M-x eglot' in a LaTeX-buffer and select "texlab" as a language-server, I get an echo-area message indicating that the connection was successful:

 [eglot] Connected! Server `TexLab' now managing `(tex-mode context-mode texinfo-mode bibtex-mode)' buffers in project `phd-thesis'.

However, I don't get any mode-line indication and the variable `eglot--managed-mode' is nil, so it seems it didn't properly activate.

I initally noticed the error in that when I tried auto-completing with `eglot-completion-at-point', I got the error message

 (jsonrpc-error "No current JSON-RPC connection" (jsonrpc-error-code . 32603) (jsonrpc-error-message . "No current JSON-RPC connection"))

I get the same message when e.g. running `M-x eglot-stderr-buffer', so I cannot attach that, but I attached the contents of eglot-events-buffer. With debug-on-error enabled I get the backtrace

 Debugger entered--Lisp error: (jsonrpc-error "No current JSON-RPC connection" (jsonrpc-error-code . 32603) (jsonrpc-error-message . "No current JSON-RPC connection"))
   jsonrpc-error("No current JSON-RPC connection")
   eglot--current-server-or-lose()
   byte-code("\300 C\207" [eglot--current-server-or-lose] 1)
   command-execute(eglot-stderr-buffer record)
   execute-extended-command(nil "eglot-stderr-buffer" nil)
   funcall-interactively(execute-extended-command nil "eglot-stderr-buffer" nil)
   command-execute(execute-extended-command)

But the initial bug is that Eglot didn't start managing the buffer when I run the command and that doesn't raise an error initially.

I can reproduce the error with "emacs -Q". It seemed to work in the past (couple of weeks ago) and now it doesn't anymore. I changed a lot in my Emacs config but that it works with emacs -Q suggests something else changed rather than just my emacs init file.

I tried two texlab versions, 5.4.1 and 5.5.0 and also other latex language-servers such as digestif and ltex-ls and got the same issue. Also it doesn't matter whether I use AucTeX or plain latex.el (which I had in emacs -Q anyway). I also disabled my dir-local variables when testing. So it doesn't seem to depend on the latex language server version.

However, I don't have problems running Eglot in other major modes, e.g. it works in Python with the pylsp  server.

For reproducing, any latex file seemed to work for me, but I attached a very minimal latex-project for testing anyway. texlab can be downloaded as a static binary from https://github.com/latex-lsp/texlab/releases/tag/v5.5.0. Then, to reproduce, just open the latex file in the attached project, run `M-x eglot', select texlab, and check if it starts managing the buffer. Then, `eglot--managed-mode' should be `t' and I expect auto-completion to work.

I'm still not 100% sure this is a bug or something messed up in my local configuration, but I just couldn't find the issue, so I thought I might as well report it just in case it's not known. If you cannot reproduce it with the above instructions, feel free to close this bug. Below is the additional system and config information as provided by report-emacs-bug.

Cheers, Michael

---

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.17.8) of 2023-04-17 built on e490
Repository revision: a46201f57eb114b8107435caf3588edbb666829e
Repository branch: master
System Description: Arch Linux

Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-libotf --without-m17n-flt --without-gconf
--enable-link-time-optimization --with-native-compilation=yes
--with-xinput2 --with-pgtk --without-xaw3d --with-sound=alsa
--with-xwidgets --with-tree-sitter --without-gpm
--without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fuse-ld=mold -fuse-ld=mold'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
 value of $LC_ALL: C.UTF-8
 value of $LC_COLLATE: C.UTF-8
 value of $LC_CTYPE: en_GB.UTF-8
 value of $LC_MESSAGES: en_US.UTF-8
 value of $LC_MONETARY: de_DE.UTF-8
 value of $LC_NUMERIC: en_US.UTF-8
 value of $LC_TIME: de_DE.UTF-8
 value of $LANG: C
 value of $XMODIFIERS: @im=fcitx
 locale-coding-system: utf-8-unix

Major mode: LaTeX

Minor modes in effect:
 shell-dirtrack-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 show-paren-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 tool-bar-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 line-number-mode: t
 transient-mark-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils tutorial thai-util thai-word mule-util lao-util
enriched disp-table facemenu view face-remap time-date cus-edit
cus-start cus-load wid-edit eglot external-completion jsonrpc xref
flymake-proc flymake thingatpt project ert pp ewoc debug backtrace
find-func filenotify pcase url-util url-parse auth-source eieio
eieio-core password-cache json map byte-opt url-vars imenu comp
comp-cstr warnings icons rx cl-seq cl-macs gv cl-extra help-mode
bytecomp byte-compile vc-git diff-mode easy-mmode vc-dispatcher
cl-loaddefs cl-lib tex-mode compile text-property-search shell subr-x
pcomplete comint ansi-osc ansi-color ring latexenc rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads xwidget-internal dbusbind inotify dynamic-setting
system-font-setting font-render-setting cairo gtk pgtk lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 299038 29240)
(symbols 48 14103 0)
(strings 32 63171 2952)
(string-bytes 1 1850467)
(vectors 16 37399)
(vector-slots 8 678882 29431)
(floats 8 97 380)
(intervals 56 856 0)
(buffers 984 19))

[eglot-events-buffer.eld (text/plain, attachment)]

[latex-mwe.tar.gz (application/gzip, attachment)]

[Message part 6 (message/rfc822, inline)]

From: João Távora <joaotavora <at> gmail.com>
To: Michael Eliachevitch <m.eliachevitch <at> posteo.de>, 62907-done <at> debbugs.gnu.org
Subject: Re: bug#62907: Eglot does not start managing LaTeX buffer despite
 reporting successful connection
Date: Wed, 19 Apr 2023 01:10:57 +0100

On Mon, Apr 17, 2023 at 10:31 PM Michael Eliachevitch
<m.eliachevitch <at> posteo.de> wrote:
>
>
> >> I just compiled the latest emacs29 git branch and there I can't
> >> reproduce
> >> the error
> >
> > This is good.  You could try a Git bisection if you have time and
> > know
> > how.
>
> I did a minimal Git bisection on the eglot.el file only, without
> recompiling the rest of Emacs. Seems the error was introduced in
> eglot.el in
>
>   a74403adda0d67b6f0430d1c038a7c96579f3450
>   Eglot: fix LSP "languageId" detection
>
> It still works for the previous commit 43290391ce2.

Your bisection was very effective and found the culprit.
Don't worry about your "awkward" setup and configuration just
for this bug, because I also found and reproduced the bug with
your instructions and it was just a plain old oversight after
a deeper-than-usual refactor.

The bug is fixed now on master, just pushed the following commit:

  commit 9093834d0b590bc15ed994bd62f18f7b47a48f55 (HEAD -> master)
  Author: João Távora <joaotavora <at> gmail.com>
  Date:   Wed Apr 19 00:59:17 2023 +0100

      Eglot: unbreak activation/management of derived modes (bug#62907)

So thanks for this report and perfectly complete recipe.  I'm
closing the bug (if you find it to be somehow _not_ fixed I will
reopen).

> 2. I'm sending my Emails from mu4e with format=flowed and long
> lines, inspired by [*], so that Email viewers with f=f support
> reflow the lines and non-compliant clients like Gmail just reflow
> them because the lines are too long. But I found this kind of sucks
> when viewing the Email text on the debbugs.gnu.org website for
> instance. Do you know if these long-line f=f mails are discouraged
> on Emacs mailing lists, bugs or patches? Probably I should adapt
> `fill-flowed-encode-column` based on the recipient and not use the
> setup with long default lines on software mailing lists, will try a
> smaller value now. Hopefully my mails looked okay to you.

They looked OK but not the usual. The usual being the hard line
breaks and about 70/80 columns  I'm guilty of using Gmail to answer
half of the mails I send to these lists (the other half I use Gnus).
In Gmail, I break the lines manually (sometimes horribly).  In Gnus
I use M-q to justify the text.  I have no idea what flags any of these
MUAs is sending.

João

Previous Next

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