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

Previous Next

Full log

Message #14 received at 62907 <at> debbugs.gnu.org (full text, mbox):

From: Michael Eliachevitch <m.eliachevitch <at> posteo.de>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62907 <at> debbugs.gnu.org
Subject: Re: bug#62907: Eglot does not start managing LaTeX buffer despite
 reporting successful connection
Date: Mon, 17 Apr 2023 20:29:26 +0000

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

I started it with

   git bisect start master emacs-29  -- lisp/progmodes/eglot.el

in an Emacs repository. Than, at each step, I opened "emacs -Q", 
where the Emacs executable is compiled from the same Emacs 29 branch 
(as I said I didn't recompile). At each git-bisect step I just 
opened the eglot.el file from the Emacs repository and ran `M-x 
eval-buffer`, then opened the LaTeX file, ran `M-x eglot` and 
checked the value of `eglot--managed-buffer`.

1. At the moment my Emacs setup is a bit awkward as I compile Emacs 
from the Archlinux AUR repository via the emacs-git package. I 
tested emacs-29 by just editing the branch into the PKGBUILD, but 
this PKGBUILD-editing approach wouldn't be appropriate for a git 
bisect, for that I should probably just clone and compile Emacs 
normally. I have cloned the Emacs repo, but never set the compile 
flags myself. But probably should do that in the future if I want to 
follow Emacs development and be able to patch things myself).

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.

 [*]: https://vxlabs.com/2019/08/25/format-flowed-with-long-lines/

Previous Next

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