GNU bug report logs -
#78392
31.0.50; eglot breaks on xref-find-definitions
Previous Next
Full log
Message #14 received at 78392 <at> debbugs.gnu.org (full text, mbox):
> From: "admin <at> sonictk.com" <admin <at> sonictk.com>
> Date: Mon, 12 May 2025 14:52:13 +0000
>
> As an addendum, I tried downloading the latest provided Emacs Windows build from
> https://gnu.mirror.constant.com/emacs/windows/ , which reads as:
>
> ```
> In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
> AVALON
> Windowing system distributor 'Microsoft Corp.', version 10.0.19045
> System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.5737)
>
> Configured using:
> 'configure --with-modules --without-dbus
> --with-native-compilation=aot --without-compress-install
> --with-tree-sitter CFLAGS=-O2 prefix=/g/rel/install/emacs-30.1'
>
> ```
>
> And with no other configuration changes and with the same clangd, things work fine (opened the same
> test2.cpp and attempted to navigate to definition.) So this is most likely a regression, but I haven't been
> able to pin it down to a specific commit yet.
I believe it was the change in url-generic-parse-url, which now
produces correct Windows file names, without the extra leading slash.
IOW, when we fixed url-generic-parse-url, that fix exposed a subtle
bug in Eglot, because Eglot was trying to fix the bug in
url-generic-parse-url locally...
However, since Eglot is on ELPA and supports earlier Emacs versions,
that code should be left in Eglot, just under an additional condition
that the file name indeed starts with a slash.
Did you have an opportunity to test the patch I suggested with Emacs
31?
This bug report was last modified 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.