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[2]: bug#57996: 28.2; imenu doesn't differentiate overloaded c++ functions Date: Wed, 05 Oct 2022 10:47:06 +0000 Message-ID: References: <87v8p22wsz.fsf@posteo.net> Reply-To: Chris Hecker Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB81CF0EDA-EDB4-47CD-AF48-6B1499652518" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20530"; 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 12:55:46 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 1og240-0005AO-Hm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 12:55:44 +0200 Original-Received: from localhost ([::1]:55672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og23z-0008Ss-Gj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 06:55:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og1wY-0005Gg-Sq for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 06:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56939) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1og1wY-0002VP-K0 for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 06:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1og1wY-0005yv-FP for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 06:48: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 10:48: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.166496683722815 (code B ref 57996); Wed, 05 Oct 2022 10:48:02 +0000 Original-Received: (at 57996) by debbugs.gnu.org; 5 Oct 2022 10:47:17 +0000 Original-Received: from localhost ([127.0.0.1]:56017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1vo-0005vv-FH for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:47:17 -0400 Original-Received: from mail-pl1-f170.google.com ([209.85.214.170]:43909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1vl-0005vc-8d for 57996@debbugs.gnu.org; Wed, 05 Oct 2022 06:47:15 -0400 Original-Received: by mail-pl1-f170.google.com with SMTP id z20so8539029plb.10 for <57996@debbugs.gnu.org>; Wed, 05 Oct 2022 03:47:13 -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=QfxrXd2Gfx6/QKak9Q9EHqGFKR61UJRpwnNJeUErNnk=; b=oMyiCQTwRCAil4OYpIoOEkRTsTWfowihqq0vWBJw+GkI1cdakKrSPMVPOvYFGxt4+A QK9xJn/PwiELpahIeLVfH5Spu+cCDj3TGBtNXULHVL1b+mRz6kyoHoNlFpo2QUp2wttK 4D8uEmpW7Ws2Ft/3roHe3GSLA6CHpFOwPmdZ63meYnOJkcpB5DmRVH4ZjrhYLoYFfcN+ RiWmX2dIMvaaElHrRDd91XrO3M+FgGiCXPxIObNwu2i5s22fYWWmB7plIrevAnN3SElY 9+tYWygnOVJVM6VW3ujBzKr5c2lPLImLGhOXcDTsGMh5TbhWMXs9rBEcSyECYTysgFa+ HpVg== 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=QfxrXd2Gfx6/QKak9Q9EHqGFKR61UJRpwnNJeUErNnk=; b=Xpmgm9Rp2jkDl694D8YafdZ7Ylkk2hhwbRX/Vq0EkQHfqWTvi5hGqxmllv139cgsfx AQ5Xf+m4OjBIHudnPrDDX/6jqi44sj3jmzc61jbkMlg0Kv9Jr5yxqYqivN9/kn0gd5+f kifBYx+OK8QtBHCvlyO24GObNoA+RNtof1jdIhCqHoRoGKTknbj8vexQDJnFiFja4T9h 5Otafi4570ihqlYYoSe7HT7z21LzsKHSTQHmlnjX7fHXfX0pyb1BdR/OrdKbUOWtPLFG 8pBTS5jT23mmW3ymxDfXrVLdSx2EwaUbnOzIqLGlxbQjqsUR3tCeyhE30tRMgvWmdwsI TDtQ== X-Gm-Message-State: ACrzQf20oRKZp0Zq0PzFhABf+ks0MpZF3is5i0P8aAHFCwq66dywoZGc XKOg0j8f4Ofdp5bX7JZAy1GXYA== X-Google-Smtp-Source: AMsMyM6QErsFQdA1eX8zdtiQMsCCqSfwvo6uUC9YEIdKDPS4KelCsQ8yqGQ7AXsNR/5gLlMvPw3HtQ== X-Received: by 2002:a17:902:db08:b0:176:d40e:4b57 with SMTP id m8-20020a170902db0800b00176d40e4b57mr31536721plx.172.1664966827361; Wed, 05 Oct 2022 03:47:07 -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 u5-20020a170902e80500b00177faf558b5sm10042672plg.250.2022.10.05.03.47.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2022 03:47:07 -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:244510 Archived-At: --------=_MB81CF0EDA-EDB4-47CD-AF48-6B1499652518 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 time=20 across all machines and shells and stuff. It definitely gets confused=20 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 c++=20 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 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 fro= m >> > 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). --------=_MB81CF0EDA-EDB4-47CD-AF48-6B1499652518 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

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


The scanning interface to imenu allows just function names 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).
--------=_MB81CF0EDA-EDB4-47CD-AF48-6B1499652518--