[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: two imenu entries for same function in C-mode

From: David Hunter
Subject: Re: two imenu entries for same function in C-mode
Date: Sat, 16 Apr 2005 20:49:30 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

Richard Stallman wrote:
    On GNU Emacs (i386-mingw-windows98.3000) of 2005-04-11 imenu
    creates _two_ entries for, say

    static void
    describe_abbrev (sym, stream)
          Lisp_Object sym, stream;

I can't reproduce this.  Would you please give a complete test case,
saying exactly what to type so as to observe the bug?

This test case shows the bug:
emacs -Q
C-x C-f ..../emacs/src/abbrev.c
M-x imenu

The completion list shows two entries for each _abbrev function:

*Rescan*                           DEFUN
DEFUN                              DEFUN
DEFUN                              DEFUN
DEFUN                              DEFUN
DEFUN                              DEFUN
DEFUN                              DEFUN
default                            describe_abbrev
describe_abbrev                    expand
form                               or
syms_of_abbrev                     syms_of_abbrev
write_abbrev                       write_abbrev

The change was introduced by lisp/imenu.el revision 1.107.  Specifically, in 
imenu--generic-function, usage of the variable beg was replaced by start.

Part of the problem is that multiple patterns in 
cc-imenu-c++-generic-expression match the same function, but they do so at 
different starting points.  For example, from abbrev.c:

static void
write_abbrev (sym, stream)
    Lisp_Object sym, stream;

This function is matched by both the second pattern (Special case to match a line like `main() {}') 
starting at "write_abbrev (..." and the third pattern (General function name regexp) 
starting at "static void".

In both cases, beg (match-beginning index) is the same (at "write_abbrev"), but 
start (point, or match-beginning 0) is not.  When INDEX-POSITION was beg, index-alist 
only got the first match, as ensured by the member test on imenu.el:841.  But now that 
INDEX-POSITION is start, index-alist gets two entries for the same-named item, albeit at 
slightly different positions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]