From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Chris Hecker" Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <87v8p22wsz.fsf@posteo.net> Reply-To: Chris Hecker Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB2BB425C4-7CDE-41E2-AD7E-1EBC946A8BB9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7422"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/8.2.1721.0 Cc: 57996@debbugs.gnu.org To: "Alan Mackenzie" , "Philip Kaludercic" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 05 13:17:58 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1og2PW-0001hA-KG for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 13:17:58 +0200 Original-Received: from localhost ([::1]:52578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og2PT-0003oF-NL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 07:17:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49862) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og2Ne-0003kB-GU for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 07:16:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57004) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1og2Ne-0001XD-7X for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 07:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1og2Ne-0006rS-2c for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 07:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Chris Hecker" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2022 11:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57996 X-GNU-PR-Package: emacs Original-Received: via spool by 57996-submit@debbugs.gnu.org id=B57996.166496852326279 (code B ref 57996); Wed, 05 Oct 2022 11:16:02 +0000 Original-Received: (at 57996) by debbugs.gnu.org; 5 Oct 2022 11:15:23 +0000 Original-Received: from localhost ([127.0.0.1]:56073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2N0-0006pm-55 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:22 -0400 Original-Received: from mail-pl1-f181.google.com ([209.85.214.181]:40802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2Mx-0006pU-8w for 57996@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:20 -0400 Original-Received: by mail-pl1-f181.google.com with SMTP id b2so10228297plc.7 for <57996@debbugs.gnu.org>; Wed, 05 Oct 2022 04:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d6-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:cc:subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=PZSvoddJCL1yyom2KzMf3NkvIUf0Eug3JUHIpyCQohs=; b=ahQMBpC2U0FJ89kvI6ZMurRf6yg/ga5SQ1vyRltP7LddEU/9qtdrU8Qn75cj/FsReK qn2Ug4T7WXcDDLhBPzD+gqbyPf4pNzzyNn3NtmkyhxrJhjJ8FaXKD5FpBnTHOnoD1lg9 zgyeye6efKLub3A3glbspwAsuERoQO97edYuklpS7yz5+MWO8QIohas7KKPI9qMB1lhT KAr6JqauMDYUEEiZGaGI5H9YaVVUDKLBAJG/1uo+zVDqgtot+5tIH1SXprieCLtPgLTx nPKOiXLCJ1+j3hFAMehS3XNnzibGtfbDg2N1h4Y2V+r1ugsveIcFP6dxteysYsvsV/4X vuxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:cc:subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PZSvoddJCL1yyom2KzMf3NkvIUf0Eug3JUHIpyCQohs=; b=ToNlDp+P/PgLZY/A81S0dr1xUt9u8x2jkJPjUABBLPg0nR7PciofjEhFSHbON+xHRm D1Y2Grj+13wggr8lnyF03RQKqrpXGvt0AVp05DXXQP+S5SoRKlaxBH4eXJhv4TF5eiYH D+aIvAFWwHxCKUSb69FwMeu37vd8DuJQy4Gq+/1NsH/ptvXLvCQSOlpJM20cJqPjaTUR /TjAA5Tc0PTQX75eKqJRfi1S/kFg+upx/NRk28bQpd5rQS1IFF0mdp4b+W/N6qn3LhmJ 35wT1fG/caSTsRXnYhG+wUd77T8pcVQFtEkDd6xKWeHT/RPg3J9nkt/O2acrmOlXWUBQ 25mQ== X-Gm-Message-State: ACrzQf2xYMTkT9fHTpmHK4TZkQY7g7B0qrsRx98WTjU/WGsMEA9eLgqY DgXLVgVxxafWhg0p5oYs6RucKA== X-Google-Smtp-Source: AMsMyM4OoXO/QAy3y18munvvZGUfUWnatlfrYM7d5PiQ3ySO/tdjBdTPZadDynPzZN7KrKYIY6ikVg== X-Received: by 2002:a17:902:aa89:b0:178:a537:f386 with SMTP id d9-20020a170902aa8900b00178a537f386mr31751811plr.124.1664968513310; Wed, 05 Oct 2022 04:15:13 -0700 (PDT) Original-Received: from [192.168.1.217] (157-131-207-86.fiber.dynamic.sonic.net. [157.131.207.86]) by smtp.gmail.com with ESMTPSA id l11-20020a17090a384b00b0020a8f44e52csm948697pjf.38.2022.10.05.04.15.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2022 04:15:12 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244518 Archived-At: --------=_MB2BB425C4-7CDE-41E2-AD7E-1EBC946A8BB9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 already hacked my own version of the c++ matching function, so maybe=20 I'll try this. A few minutes later... Okay, so this function does indeed get called, but both Function=20 elements in the imenu list pass the marker for the first Function, so=20 that's unfortunate... I will look at that... Another few minutes... Well, it looks like imenu--generic-function generates the right alist=20 with the two functions and the two different markers, so it's something=20 about choosing in the buffer... Here's the alist return, looks good: (("Function" . #) ("Function" . #) ("Bar" . #)) I should sleep, but maybe there's just a bug in the code that selects=20 the function, or it searches by name instead of by index. I wish there=20 was some way for the regex match to return a mangled name...I'll look=20 into imenu next. Chris ------ Original Message ------ From: "Chris Hecker" To: "Alan Mackenzie" ; "Philip Kaludercic"=20 Cc: 57996@debbugs.gnu.org Sent: 2022-10-05 03:47:06 Subject: Re[2]: bug#57996: 28.2; imenu doesn't differentiate overloaded=20 c++ functions > >Yeah, I should probably switch to something a little more modern, but=20 >imenu has the advantage of just being there and working most of the=20 >time across all machines and shells and stuff. It definitely gets=20 >confused occasionally (like it doesn't find inline functions in class=20 >declarations) but this overload thing seemed like it might be a simple=20 >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=20 >number...kinda hacky but it'd work...maybe I'll take a look. > >Chris > > >------ Original Message ------ >From: "Alan Mackenzie" >To: "Philip Kaludercic" >Cc: "Chris Hecker" ; 57996@debbugs.gnu.org >Sent: 2022-10-05 03:31:11 >Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded=20 >c++ functions > >>Hello, Chris and Philip. >> >>On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Kaludercic wrote: >>> "Chris Hecker" 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 probabl= y >>> > give two, maybe with a line number after them like "Function(123)" o= r >>> > whatever. Currently there's no way to get to the second Function fr= om >>> > 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). --------=_MB2BB425C4-7CDE-41E2-AD7E-1EBC946A8BB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hmm...

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

This looks = like it might work...=C2=A0 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...

<= /div>
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...=C2=A0 I will look at that...

Another few minutes...

Well, it looks like= imenu--generic-function generates the right alist with the two functions an= d 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>)
=C2=A0("Function" . #&= lt;marker at 41 in c.cpp>)
=C2=A0("Bar" . #<ma= rker 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= .=C2=A0 =C2=A0I wish there was some way for the regex match to return a man= gled name...I'll look into imenu next.

Chris

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


Yeah, I should probably switch to something a little= more modern, but imenu has the advantage of just being there and working mo= st of the time across all machines and shells and stuff.=C2=A0 It definitel= y gets confused occasionally (like it doesn't find inline functions in clas= s declarations) but this overload thing seemed like it might be a simple fi= x.


The scanning interface to imenu allows just function n= ames to be
collect= ed. It doesn't allow anything extra (such as a line number) to
be incl= uded into the alist.

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

C= hris


------ Original Message ------
From: "Alan Mackenzie" <acm@muc.de>
Sent: 2022-10-05 03:31:11
Subject: Re: bug#57996: 28.2; imenu doesn't differentiate overloaded c= ++ functions

Hello, Chris and Philip.
=C2=A0
On Sun, Oct 02, 2022 at 13:13:16 +0000, Philip Ka= ludercic wrote:
"Chris Hecker" <checker@d6.com> writes:
=C2=A0
> With this dumb c++ file:
> ----
> int Function( int n ) {
> return n;
> }
> int Function( float v ) {
> return (int)(v + 0.5);
> }
> ----
=C2=A0
> Hitting imenu only gives a single Function= entry. It should probably
> give two, maybe with a line number after th= em like "Function(123)" or
> whatever. Currently there's no way to get= to the second Function from
> imenu.
=C2=A0
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 i= s a function which gets
_all_ the matches from an alist, and I've asked o= n emacs-devel about
this.
=C2=A0
Note that this is not the case when using Eglot= and a LSP server like
clangd.
=C2=A0
Much more modern!
=C2=A0
I've CC'ed Alan to see if he knows how this coul= d be done by c++-mode
itself.
=C2=A0
I'm pretty sure it couldn't be. I think it would = involve enhancing
imenu. The scanning interface to imenu allows ju= st function names to be
collected. It doesn't allow anything extra (such = as a line number) to
be included into the alist.
=C2=A0
I've looked at problems with imenu in C++ Mode be= fore, but got bogged
down without coming up with a workable solution. = There the problem was
identically named methods in different classes, o= r something like that.
=C2=A0
So, maybe we can enhance imenu. But not for Emac= s 29.
=C2=A0
--
Alan Mackenzie (Nuremberg, Germany).
--------=_MB2BB425C4-7CDE-41E2-AD7E-1EBC946A8BB9--