Subject: bug#78392: 31.0.50; eglot breaks on xref-find-definitions

From: Eli Zaretskii <[email-masked]>
Date: Mon, 12 May 2025 22:19:44 +0300

> From: "[email-masked]" <[email-masked]>
> 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?