bug#59575: 29.0.50; add-log-current-defun-header-regexp matches Windows drive letter

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 25 Nov 2022 16:53:51 +0100
> 
> If you have an *xref* buffer with absolute Windows filenames, like
> 
> ~/.emacs.d/init.el
>   93:             server-name    (replace-regexp-in-string "\\\\+" "\\" serv 
> t t)
> 1102:   (let ((s (when server-name
> 1104:                (string-match (rx (+ (not (any ?\\))) line-end) 
> server-name)
> 1105:                (upcase (match-string 0 server-name))))))
> d:/Devel/emacs/repo/trunk/lisp/erc/erc-backend.el
> 1820:   (pcase-let ((`(,server-name ,server-version)
> 1823:     (setq erc-server-announced-name server-name)
> 1827:      's004 ?s server-name ?v server-version
> 
> and put the cursor in an absolute filename line (like the one d:/Devel/[etc] 
> above), calling
> `add-log-current-defun' returns the drive letter "d", because it matches 
> a-l-c-d-header-regexp.
> 
> The effect is visible when you have which-function-mode enabled, because the 
> function returns non-nil, so
> which-function does not resort to imenu, and you end with "d" in the 
> mode-line.
> 
> I suppose this should be fixed in xref.el, which apparently assumes that file 
> name lines will be either relative
> or Unix-style (/path/file works correctly, it's just d:/path/file that fails) 
> and the add-log heuristics will always
> fail.

xref.el doesn't know anything about add-log, and AFAICT doesn't customize it
in any way, shape, or form.  So I think this should be fixed in add-log.el.
Its regexp is too naïve, and should be beefed-up not to fail in this way.
For example, is it really reasonable to accept "defuns" whose name is a
single letter?  Or if it's impossible to do that in the regexp, then we
should reject such "matches" in add-log-current-defun instead.

It is also possible to have xref.el define its customized
add-log-current-defun-function, but that sounds like overkill to me.
Dmitry, WDYT?