On 07.11.2020 01:22, Pierre Rouleau wrote:
> This problem was detected in emacs 26.3, but is also present in emacs
> 27.1, according to the code posted inside
Do you see the same problem with 'M-x find-tag'?
Short answer: yes
Longer answer: you can try it on Emacs lib files.
For example, I created a TAGS file that contains the following:
(define-derived-mode prog-mode ^?251,10485
(defvar cc-bytecomp-unbound-variables ^?76,2968
(defvar cc-bytecomp-original-functions ^?77,3011
(defvar cc-bytecomp-original-properties ^?78,3055
(defvar cc-bytecomp-loaded-files ^?79,3100
(defvar cc-bytecomp-environment-set ^?86,3302
(defmacro cc-bytecomp-debug-msg ^?88,3344
(defun cc-bytecomp-compiling-or-loading ^?93,3432
(defsubst cc-bytecomp-is-compiling ^?134,4714
(defsubst cc-bytecomp-is-loading ^?138,4857
(defun cc-bytecomp-setup-environment ^?143,5065
(defun cc-bytecomp-restore-environment ^?191,6703
(defun cc-bytecomp-load ^?256,8749
(defmacro cc-require ^?293,10222
(defmacro cc-conditional-require ^?305,10617
(defmacro cc-conditional-require-after-load ^?318,11068
(defmacro cc-provide ^?333,11627
(defmacro cc-load ^?340,11887
(defmacro cc-require-when-compile ^?351,12266
(defmacro cc-external-require ^?362,12703
(defmacro cc-bytecomp-defvar ^?371,13055
(defmacro cc-bytecomp-defun ^?392,13857
(defmacro cc-bytecomp-put ^?419,14990
(defmacro cc-bytecomp-boundp ^?437,15739
(defmacro cc-bytecomp-fboundp ^?447,16140
(defgroup makefile ^?95,3661
Then with the file /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-cmds.el.gz in a buffer and cc-bytecomp not loaded trying both
M-x xref-find-definitions cc-require
M-x find-tag cc-require
Rerun etags: ‘^(defmacro cc-require ’ not found in /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el
If I update the etags.el with my suggested code, M-x xref-find-definition works but find-tag still does not.
Since find-tag is obsolete since emacs 25.1 I did not look into it.
I did not look into the etags utility itself yet. This looks like a consistency problem.
I would think that the etags utility should generate a reference for el.gz files listing
the real file name. On the other hand having the fix in both places both in etags utility
and in emacs etags.el would reduce probability of errors.