bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files

[Eli Zaretskii <eliz@gnu.org>]

> From: Pierre Rouleau <prouleau001@gmail.com>
> Date: Sat, 7 Nov 2020 09:15:12 -0500
> Cc: dgutov@yandex.ru, 44494@debbugs.gnu.org
> 
> To recap you need to try searching for something that is not already 
> loaded and use the etags xref backend with a file that contains the definition
> of what one is searching and that is located inside a compressed file.

OK, I've now tried this with paren.el, which is not loaded in "emacs
-Q".  I can confirm that M-. fails to find functions in paren.el (I
tried show-paren-function, FTR), even if I use xref-etags-mode, but
"M-x find-tag" succeeds.

So I think we should try to understand why find-tag does work in this
case, and see how to make xref-find-definitions do the same.  Could
you perhaps do that?

> . emacs -Q
> . C-x C-f lisp/simple.el.gz
> . M-x xref-etags-mode
> . C-u M-x cc-require
> emacs==> prompts Visit tags table (default TAGS): ....
> me ====> I select the TAGS file where all definitions are stored and hit RET
> - emacs 26.3 ==> Rerun etags: ‘^(defmacro cc-require ’ not found in
> /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\
> es/cc-bytecomp.el
> - emacs 27.1 ==> Rerun etags: ‘^(defmacro cc-require ’ not found in
> /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-bytecomp.el

Note that at this point, you have an empty cc-bytecomp.el buffer.
Which I think gives a clue as to where the problem lies.