Description of problem:
Using emacs and etags for kernel (and other) development, the search to find a
macro definition doesn't work. When I put the cursor on a macro, and hit M-. to
find where it is defined, it gives me just another instance of the macro. I can
repeat the search (C-u M-.) serveral times and it will evetually get to the
definition (but not always). I do not have this problem on Debian Testing,
where there it gives me the macro definition the first time, everytime.
Version-Release number of selected component (if applicable):
$ emacs --version
GNU Emacs 21.4.1
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
everytime I do a macro search on a Linux kernel or Xen tree.
Steps to Reproduce:
1. find . -name '*.[ch]' | xargs etags # done in a Xen or Linux Kernel tree, and
yes this also works with a "make TAGS" in a Linux kernel.
2. Start emacs on some C file with macros
3. Place cursor on a macro (where there are lots of instances of it).
4. Hit M-. (will need to also load the TAGS file).
Then it takes you to another instance of the macro instead of the defined.
Brought to another instance of the requested macro.
Brought to the definition of the macro.
Which etags are you using? The one that comes with emacs, or the one from
the ctags package?
FWIW the only time this happens to me is when the macro is used on
a line that is a definition for some other tag. In this case, emacs
seems to get confused and not realize that it is visiting the
"wrong kind" of definition. E.g., the Emacs sources use a DEFUN(...)
macro to define functions; if I search for DEFUN it takes me to
If this is what is happening for you, then I think it is an upstream bug.
I suggest M-x report-emacs-bug
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
The information we've requested above is required in order
to review this problem report further and diagnose or fix the
issue if it is still present. Since it has been thirty days or
more since we first requested additional information, we're assuming
the problem is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "CLOSED INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.