all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Chris Hecker" <checker@d6.com>
To: "Alan Mackenzie" <acm@muc.de>, "Philip Kaludercic" <philipk@posteo.net>
Cc: 57996@debbugs.gnu.org
Subject: bug#57996: Re[3]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions
Date: Wed, 05 Oct 2022 11:15:12 +0000	[thread overview]
Message-ID: <em35cdca27-cc1a-4e4c-8971-4df43aab68b1@checker-blade15> (raw)
In-Reply-To: <emd474b896-1b01-4a2a-8d44-d43f17d7634c@checker-blade15>

[-- 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 --]

  reply	other threads:[~2022-10-05 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  4:16 bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions Chris Hecker
2022-10-02 13:13 ` Philip Kaludercic
2022-10-05 10:31   ` Alan Mackenzie
     [not found]   ` <Yz1c721Ohisf5909@acm>
2022-10-05 10:47     ` bug#57996: Re[2]: " Chris Hecker
2022-10-05 11:15       ` Chris Hecker [this message]
2022-10-05 13:45         ` bug#57996: Re[4]: " Chris Hecker
2022-10-05 13:58           ` bug#57996: Re[5]: " Chris Hecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=em35cdca27-cc1a-4e4c-8971-4df43aab68b1@checker-blade15 \
    --to=checker@d6.com \
    --cc=57996@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.