bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 3503 bytes --]


With this dumb c++ file:
----
int Function( int n ) {
   return n;
}
int Function( float v ) {
   return (int)(v + 0.5);
}
----

Hitting imenu only gives a single Function entry.  It should probably
give two, maybe with a line number after them like "Function(123)" or
whatever.  Currently there's no way to get to the second Function from
imenu.

Thanks,
Chris


In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
  of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Home (v10.0.2009.19044.2006)

Configured using:
  'configure --with-modules --without-dbus --with-native-compilation
  --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

Important settings:
   value of $LANG: ENU
   locale-coding-system: cp1252

Major mode: C++//l

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug comp comp-cstr warnings rx cl-extra
help-mode message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs
auth-source eieio eieio-core cl-macs eieio-loaddefs password-cache json
map text-property-search seq byte-opt gv bytecomp byte-compile cconv
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date subr-x misearch multi-isearch thingatpt cl-seq
imenu vc-bzr vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 124613 8089)
  (symbols 48 9959 1)
  (strings 32 30565 2202)
  (string-bytes 1 1088980)
  (vectors 16 20627)
  (vector-slots 8 384011 13594)
  (floats 8 32 290)
  (intervals 56 529 0)
  (buffers 992 14))

[-- Attachment #2: Type: text/html, Size: 4630 bytes --]

bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Philip Kaludercic]

"Chris Hecker" <checker@d6.com> writes:

> With this dumb c++ file:
> ----
> int Function( int n ) {
>   return n;
> }
> int Function( float v ) {
>   return (int)(v + 0.5);
> }
> ----
>
> Hitting imenu only gives a single Function entry.  It should probably
> give two, maybe with a line number after them like "Function(123)" or
> whatever.  Currently there's no way to get to the second Function from
> imenu.

Note that this is not the case when using Eglot and a LSP server like
clangd.

I've CC'ed Alan to see if he knows how this could be done by c++-mode
itself.

bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Alan Mackenzie]

Hello, Chris and Philip.

On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote:
> "Chris Hecker" <checker@d6.com> writes:

> > With this dumb c++ file:
> > ----
> > int Function( int n ) {
> >   return n;
> > }
> > int Function( float v ) {
> >   return (int)(v + 0.5);
> > }
> > ----

> > Hitting imenu only gives a single Function entry.  It should probably
> > give two, maybe with a line number after them like "Function(123)" or
> > whatever.  Currently there's no way to get to the second Function from
> > imenu.

imenu is old and rather simplistic.  It parses a buffer, then stores the
results in an association list.  It then uses the function assoc on that
list to get "the" match.  What we could do with is a function which gets
_all_ the matches from an alist, and I've asked on emacs-devel about
this.

> Note that this is not the case when using Eglot and a LSP server like
> clangd.

Much more modern!

> I've CC'ed Alan to see if he knows how this could be done by c++-mode
> itself.

I'm pretty sure it couldn't be.  I think it would involve enhancing
imenu.  The scanning interface to imenu allows just function names to be 
collected.  It doesn't allow anything extra (such as a line number) to
be included into the alist.

I've looked at problems with imenu in C++ Mode before, but got bogged
down without coming up with a workable solution.  There the problem was
identically named methods in different classes, or something like that.

So, maybe we can enhance imenu.  But not for Emacs 29.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#57996: Re[2]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]


Yeah, I should probably switch to something a little more modern, but 
imenu has the advantage of just being there and working most of the time 
across all machines and shells and stuff.  It definitely gets confused 
occasionally (like it doesn't find inline functions in class 
declarations) but this overload thing seemed like it might be a simple 
fix.


The scanning interface to imenu allows just function names to be
collected.  It doesn't allow anything extra (such as a line number) to
be included into the alist.

I guess you could mangle the name to include the line number or match 
number...kinda hacky but it'd work...maybe I'll take a look.

Chris


------ Original Message ------
From: "Alan Mackenzie" <acm@muc.de>
To: "Philip Kaludercic" <philipk@posteo.net>
Cc: "Chris Hecker" <checker@d6.com>; 57996@debbugs.gnu.org
Sent: 2022-10-05 03:31:11
Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ 
functions

>Hello, Chris and Philip.
>
>On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote:
>>  "Chris Hecker" <checker@d6.com> writes:
>
>>  > With this dumb c++ file:
>>  > ----
>>  > int Function( int n ) {
>>  >   return n;
>>  > }
>>  > int Function( float v ) {
>>  >   return (int)(v + 0.5);
>>  > }
>>  > ----
>
>>  > Hitting imenu only gives a single Function entry.  It should probably
>>  > give two, maybe with a line number after them like "Function(123)" or
>>  > whatever.  Currently there's no way to get to the second Function from
>>  > imenu.
>
>imenu is old and rather simplistic.  It parses a buffer, then stores the
>results in an association list.  It then uses the function assoc on that
>list to get "the" match.  What we could do with is a function which gets
>_all_ the matches from an alist, and I've asked on emacs-devel about
>this.
>
>>  Note that this is not the case when using Eglot and a LSP server like
>>  clangd.
>
>Much more modern!
>
>>  I've CC'ed Alan to see if he knows how this could be done by c++-mode
>>  itself.
>
>I'm pretty sure it couldn't be.  I think it would involve enhancing
>imenu.  The scanning interface to imenu allows just function names to be
>collected.  It doesn't allow anything extra (such as a line number) to
>be included into the alist.
>
>I've looked at problems with imenu in C++ Mode before, but got bogged
>down without coming up with a workable solution.  There the problem was
>identically named methods in different classes, or something like that.
>
>So, maybe we can enhance imenu.  But not for Emacs 29.
>
>--
>Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Type: text/html, Size: 5950 bytes --]

bug#57996: Re[3]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 4170 bytes --]


Hmm...

item is selected by the user.  This function is called with
arguments consisting of the item name, the buffer position, and
the ARGUMENTS.

This looks like it might work...  I just opened my .emacs and found I'd 
already hacked my own version of the c++ matching function, so maybe 
I'll try this.

A few minutes later...

Okay, so this function does indeed get called, but both Function 
elements in the imenu list pass the marker for the first Function, so 
that's unfortunate...  I will look at that...

Another few minutes...

Well, it looks like imenu--generic-function generates the right alist 
with the two functions and the two different markers, so it's something 
about choosing in the buffer...

Here's the alist return, looks good:

(("Function" . #<marker at 2 in c.cpp>)
  ("Function" . #<marker at 41 in c.cpp>)
  ("Bar" . #<marker at 95 in c.cpp>))

I should sleep, but maybe there's just a bug in the code that selects 
the function, or it searches by name instead of by index.   I wish there 
was some way for the regex match to return a mangled name...I'll look 
into imenu next.

Chris

------ Original Message ------
From: "Chris Hecker" <checker@d6.com>
To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
<philipk@posteo.net>
Cc: 57996@debbugs.gnu.org
Sent: 2022-10-05 03:47:06
Subject: Re[2]: bug#57996: 28.2; imenu doesn't differentiate overloaded 
c++ functions

>
>Yeah, I should probably switch to something a little more modern, but 
>imenu has the advantage of just being there and working most of the 
>time across all machines and shells and stuff.  It definitely gets 
>confused occasionally (like it doesn't find inline functions in class 
>declarations) but this overload thing seemed like it might be a simple 
>fix.
>
>
>The scanning interface to imenu allows just function names to be
>collected.  It doesn't allow anything extra (such as a line number) to
>be included into the alist.
>
>I guess you could mangle the name to include the line number or match 
>number...kinda hacky but it'd work...maybe I'll take a look.
>
>Chris
>
>
>------ Original Message ------
>From: "Alan Mackenzie" <acm@muc.de>
>To: "Philip Kaludercic" <philipk@posteo.net>
>Cc: "Chris Hecker" <checker@d6.com>; 57996@debbugs.gnu.org
>Sent: 2022-10-05 03:31:11
>Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded 
>c++ functions
>
>>Hello, Chris and Philip.
>>
>>On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote:
>>>  "Chris Hecker" <checker@d6.com> writes:
>>
>>>  > With this dumb c++ file:
>>>  > ----
>>>  > int Function( int n ) {
>>>  >   return n;
>>>  > }
>>>  > int Function( float v ) {
>>>  >   return (int)(v + 0.5);
>>>  > }
>>>  > ----
>>
>>>  > Hitting imenu only gives a single Function entry.  It should probably
>>>  > give two, maybe with a line number after them like "Function(123)" or
>>>  > whatever.  Currently there's no way to get to the second Function from
>>>  > imenu.
>>
>>imenu is old and rather simplistic.  It parses a buffer, then stores the
>>results in an association list.  It then uses the function assoc on that
>>list to get "the" match.  What we could do with is a function which gets
>>_all_ the matches from an alist, and I've asked on emacs-devel about
>>this.
>>
>>>  Note that this is not the case when using Eglot and a LSP server like
>>>  clangd.
>>
>>Much more modern!
>>
>>>  I've CC'ed Alan to see if he knows how this could be done by c++-mode
>>>  itself.
>>
>>I'm pretty sure it couldn't be.  I think it would involve enhancing
>>imenu.  The scanning interface to imenu allows just function names to be
>>collected.  It doesn't allow anything extra (such as a line number) to
>>be included into the alist.
>>
>>I've looked at problems with imenu in C++ Mode before, but got bogged
>>down without coming up with a workable solution.  There the problem was
>>identically named methods in different classes, or something like that.
>>
>>So, maybe we can enhance imenu.  But not for Emacs 29.
>>
>>--
>>Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Type: text/html, Size: 9114 bytes --]

bug#57996: Re[4]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 5813 bytes --]


Okay, I figured out a way to do this that works pretty easily, and the 
same idea could be integrated into imenu fairly trivially:

>(defun checker-imenu-make-unique-alist (index-alist)
>   "De-duplicate the imenu alist by adding indices to duplicate names."
>   (let ((h (make-hash-table :test #'equal)))
>     (mapc (lambda (el)
>             (let* ((k (car el))
>                    (v (gethash k h)))
>               (if v
>                   (let ((n (car v)))
>                     (if (= n 1)
>                         (setcar (car (cdr v)) (format "%s(1)" k)))
>                     (setq n (1+ n))
>                     (puthash k '(n nil) h)
>                     (setcar el (format "%s(%d)" k n)))
>                 (puthash k (list 1 el) h))))
>           index-alist)))
>(advice-add 'imenu--truncate-items :filter-return 
>#'checker-imenu-make-unique-alist)

So this just hooks the imenu--truncate-items function because it was the 
easiest function that was hookable on the pre-cached side of the code 
(meaning it doesn't get called every imenu, just on *rescan*).  It puts 
the function names in a hash, and if they are dupes, it puts (n) after 
the name.  Works great.

Chris



------ Original Message ------
From: "Chris Hecker" <checker@d6.com>
To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
<philipk@posteo.net>
Cc: 57996@debbugs.gnu.org
Sent: 2022-10-05 04:15:12
Subject: Re[3]: bug#57996: 28.2; imenu doesn't differentiate overloaded 
c++ functions

>
>Hmm...
>
>item is selected by the user.  This function is called with
>arguments consisting of the item name, the buffer position, and
>the ARGUMENTS.
>
>This looks like it might work...  I just opened my .emacs and found I'd 
>already hacked my own version of the c++ matching function, so maybe 
>I'll try this.
>
>A few minutes later...
>
>Okay, so this function does indeed get called, but both Function 
>elements in the imenu list pass the marker for the first Function, so 
>that's unfortunate...  I will look at that...
>
>Another few minutes...
>
>Well, it looks like imenu--generic-function generates the right alist 
>with the two functions and the two different markers, so it's something 
>about choosing in the buffer...
>
>Here's the alist return, looks good:
>
>(("Function" . #<marker at 2 in c.cpp>)
>  ("Function" . #<marker at 41 in c.cpp>)
>  ("Bar" . #<marker at 95 in c.cpp>))
>
>I should sleep, but maybe there's just a bug in the code that selects 
>the function, or it searches by name instead of by index.   I wish 
>there was some way for the regex match to return a mangled name...I'll 
>look into imenu next.
>
>Chris
>
>------ Original Message ------
>From: "Chris Hecker" <checker@d6.com>
>To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
><philipk@posteo.net>
>Cc: 57996@debbugs.gnu.org
>Sent: 2022-10-05 03:47:06
>Subject: Re[2]: bug#57996: 28.2; imenu doesn't differentiate overloaded 
>c++ functions
>
>>
>>Yeah, I should probably switch to something a little more modern, but 
>>imenu has the advantage of just being there and working most of the 
>>time across all machines and shells and stuff.  It definitely gets 
>>confused occasionally (like it doesn't find inline functions in class 
>>declarations) but this overload thing seemed like it might be a simple 
>>fix.
>>
>>
>>The scanning interface to imenu allows just function names to be
>>collected.  It doesn't allow anything extra (such as a line number) to
>>be included into the alist.
>>
>>I guess you could mangle the name to include the line number or match 
>>number...kinda hacky but it'd work...maybe I'll take a look.
>>
>>Chris
>>
>>
>>------ Original Message ------
>>From: "Alan Mackenzie" <acm@muc.de>
>>To: "Philip Kaludercic" <philipk@posteo.net>
>>Cc: "Chris Hecker" <checker@d6.com>; 57996@debbugs.gnu.org
>>Sent: 2022-10-05 03:31:11
>>Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded 
>>c++ functions
>>
>>>Hello, Chris and Philip.
>>>
>>>On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote:
>>>>  "Chris Hecker" <checker@d6.com> writes:
>>>
>>>>  > With this dumb c++ file:
>>>>  > ----
>>>>  > int Function( int n ) {
>>>>  >   return n;
>>>>  > }
>>>>  > int Function( float v ) {
>>>>  >   return (int)(v + 0.5);
>>>>  > }
>>>>  > ----
>>>
>>>>  > Hitting imenu only gives a single Function entry.  It should probably
>>>>  > give two, maybe with a line number after them like "Function(123)" or
>>>>  > whatever.  Currently there's no way to get to the second Function from
>>>>  > imenu.
>>>
>>>imenu is old and rather simplistic.  It parses a buffer, then stores the
>>>results in an association list.  It then uses the function assoc on that
>>>list to get "the" match.  What we could do with is a function which gets
>>>_all_ the matches from an alist, and I've asked on emacs-devel about
>>>this.
>>>
>>>>  Note that this is not the case when using Eglot and a LSP server like
>>>>  clangd.
>>>
>>>Much more modern!
>>>
>>>>  I've CC'ed Alan to see if he knows how this could be done by c++-mode
>>>>  itself.
>>>
>>>I'm pretty sure it couldn't be.  I think it would involve enhancing
>>>imenu.  The scanning interface to imenu allows just function names to be
>>>collected.  It doesn't allow anything extra (such as a line number) to
>>>be included into the alist.
>>>
>>>I've looked at problems with imenu in C++ Mode before, but got bogged
>>>down without coming up with a workable solution.  There the problem was
>>>identically named methods in different classes, or something like that.
>>>
>>>So, maybe we can enhance imenu.  But not for Emacs 29.
>>>
>>>--
>>>Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Type: text/html, Size: 10337 bytes --]

bug#57996: Re[5]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 6349 bytes --]


Er, wait, this won't handle nested alists, I'll fix it tomorrow.

Chris


------ Original Message ------
From: "Chris Hecker" <checker@d6.com>
To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
<philipk@posteo.net>
Cc: 57996@debbugs.gnu.org
Sent: 2022-10-05 06:45:05
Subject: Re[4]: bug#57996: 28.2; imenu doesn't differentiate overloaded 
c++ functions

>
>Okay, I figured out a way to do this that works pretty easily, and the 
>same idea could be integrated into imenu fairly trivially:
>
>>(defun checker-imenu-make-unique-alist (index-alist)
>>   "De-duplicate the imenu alist by adding indices to duplicate names."
>>   (let ((h (make-hash-table :test #'equal)))
>>     (mapc (lambda (el)
>>             (let* ((k (car el))
>>                    (v (gethash k h)))
>>               (if v
>>                   (let ((n (car v)))
>>                     (if (= n 1)
>>                         (setcar (car (cdr v)) (format "%s(1)" k)))
>>                     (setq n (1+ n))
>>                     (puthash k '(n nil) h)
>>                     (setcar el (format "%s(%d)" k n)))
>>                 (puthash k (list 1 el) h))))
>>           index-alist)))
>>(advice-add 'imenu--truncate-items :filter-return 
>>#'checker-imenu-make-unique-alist)
>
>So this just hooks the imenu--truncate-items function because it was 
>the easiest function that was hookable on the pre-cached side of the 
>code (meaning it doesn't get called every imenu, just on *rescan*).  It 
>puts the function names in a hash, and if they are dupes, it puts (n) 
>after the name.  Works great.
>
>Chris
>
>
>
>------ Original Message ------
>From: "Chris Hecker" <checker@d6.com>
>To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
><philipk@posteo.net>
>Cc: 57996@debbugs.gnu.org
>Sent: 2022-10-05 04:15:12
>Subject: Re[3]: bug#57996: 28.2; imenu doesn't differentiate overloaded 
>c++ functions
>
>>
>>Hmm...
>>
>>item is selected by the user.  This function is called with
>>arguments consisting of the item name, the buffer position, and
>>the ARGUMENTS.
>>
>>This looks like it might work...  I just opened my .emacs and found 
>>I'd already hacked my own version of the c++ matching function, so 
>>maybe I'll try this.
>>
>>A few minutes later...
>>
>>Okay, so this function does indeed get called, but both Function 
>>elements in the imenu list pass the marker for the first Function, so 
>>that's unfortunate...  I will look at that...
>>
>>Another few minutes...
>>
>>Well, it looks like imenu--generic-function generates the right alist 
>>with the two functions and the two different markers, so it's 
>>something about choosing in the buffer...
>>
>>Here's the alist return, looks good:
>>
>>(("Function" . #<marker at 2 in c.cpp>)
>>  ("Function" . #<marker at 41 in c.cpp>)
>>  ("Bar" . #<marker at 95 in c.cpp>))
>>
>>I should sleep, but maybe there's just a bug in the code that selects 
>>the function, or it searches by name instead of by index.   I wish 
>>there was some way for the regex match to return a mangled name...I'll 
>>look into imenu next.
>>
>>Chris
>>
>>------ Original Message ------
>>From: "Chris Hecker" <checker@d6.com>
>>To: "Alan Mackenzie" <acm@muc.de>; "Philip Kaludercic" 
>><philipk@posteo.net>
>>Cc: 57996@debbugs.gnu.org
>>Sent: 2022-10-05 03:47:06
>>Subject: Re[2]: bug#57996: 28.2; imenu doesn't differentiate 
>>overloaded c++ functions
>>
>>>
>>>Yeah, I should probably switch to something a little more modern, but 
>>>imenu has the advantage of just being there and working most of the 
>>>time across all machines and shells and stuff.  It definitely gets 
>>>confused occasionally (like it doesn't find inline functions in class 
>>>declarations) but this overload thing seemed like it might be a 
>>>simple fix.
>>>
>>>
>>>The scanning interface to imenu allows just function names to be
>>>collected.  It doesn't allow anything extra (such as a line number) to
>>>be included into the alist.
>>>
>>>I guess you could mangle the name to include the line number or match 
>>>number...kinda hacky but it'd work...maybe I'll take a look.
>>>
>>>Chris
>>>
>>>
>>>------ Original Message ------
>>>From: "Alan Mackenzie" <acm@muc.de>
>>>To: "Philip Kaludercic" <philipk@posteo.net>
>>>Cc: "Chris Hecker" <checker@d6.com>; 57996@debbugs.gnu.org
>>>Sent: 2022-10-05 03:31:11
>>>Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded 
>>>c++ functions
>>>
>>>>Hello, Chris and Philip.
>>>>
>>>>On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote:
>>>>>  "Chris Hecker" <checker@d6.com> writes:
>>>>
>>>>>  > With this dumb c++ file:
>>>>>  > ----
>>>>>  > int Function( int n ) {
>>>>>  >   return n;
>>>>>  > }
>>>>>  > int Function( float v ) {
>>>>>  >   return (int)(v + 0.5);
>>>>>  > }
>>>>>  > ----
>>>>
>>>>>  > Hitting imenu only gives a single Function entry.  It should probably
>>>>>  > give two, maybe with a line number after them like "Function(123)" or
>>>>>  > whatever.  Currently there's no way to get to the second Function from
>>>>>  > imenu.
>>>>
>>>>imenu is old and rather simplistic.  It parses a buffer, then stores the
>>>>results in an association list.  It then uses the function assoc on that
>>>>list to get "the" match.  What we could do with is a function which gets
>>>>_all_ the matches from an alist, and I've asked on emacs-devel about
>>>>this.
>>>>
>>>>>  Note that this is not the case when using Eglot and a LSP server like
>>>>>  clangd.
>>>>
>>>>Much more modern!
>>>>
>>>>>  I've CC'ed Alan to see if he knows how this could be done by c++-mode
>>>>>  itself.
>>>>
>>>>I'm pretty sure it couldn't be.  I think it would involve enhancing
>>>>imenu.  The scanning interface to imenu allows just function names to be
>>>>collected.  It doesn't allow anything extra (such as a line number) to
>>>>be included into the alist.
>>>>
>>>>I've looked at problems with imenu in C++ Mode before, but got bogged
>>>>down without coming up with a workable solution.  There the problem was
>>>>identically named methods in different classes, or something like that.
>>>>
>>>>So, maybe we can enhance imenu.  But not for Emacs 29.
>>>>
>>>>--
>>>>Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Type: text/html, Size: 11719 bytes --]