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. How reproducible: 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. Actual results: Brought to another instance of the requested macro. Expected results: Brought to the definition of the macro. Additional info:
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 those lines. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.