From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Error in C++ mode with Emacs 27.0.90 Date: Sat, 4 Apr 2020 11:46:38 +0000 Message-ID: <20200404114638.GC5329@ACM> References: <1385091004.1458082.1585083014184@mail1.libero.it> <2124649786.1598258.1585324562989@mail1.libero.it> <20200328151944.GF7449@ACM> <56971920.1649844.1585416890173@mail1.libero.it> <20200328201057.GH7449@ACM> <3d764ea5-0d60-1070-0d8a-f9820d013033@yandex.ru> <20200329115056.GA5469@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97017"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Angelo Graziosi , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 04 13:47:43 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jKhH5-000P99-F9 for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 13:47:43 +0200 Original-Received: from localhost ([::1]:37858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKhH4-0004W5-FS for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 07:47:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49050) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKhG7-0003g7-K3 for emacs-devel@gnu.org; Sat, 04 Apr 2020 07:46:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKhG6-0006Gs-CC for emacs-devel@gnu.org; Sat, 04 Apr 2020 07:46:43 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:56837 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jKhG5-0006D1-Iu for emacs-devel@gnu.org; Sat, 04 Apr 2020 07:46:42 -0400 Original-Received: (qmail 84478 invoked by uid 3782); 4 Apr 2020 11:46:39 -0000 Original-Received: from acm.muc.de (p2E5D54F1.dip0.t-ipconnect.de [46.93.84.241]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sat, 04 Apr 2020 13:46:38 +0200 Original-Received: (qmail 6372 invoked by uid 1000); 4 Apr 2020 11:46:38 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246393 Archived-At: Hello, Dmitry. On Mon, Mar 30, 2020 at 01:32:48 +0300, Dmitry Gutov wrote: > On 29.03.2020 14:50, Alan Mackenzie wrote: > > It seems unlikely that we can get a nested list (in imenu--index-alist) > > with only one element. I have tried creating a C++ buffer with 25 > > functions in it. This gives a simple list of 25 elements. With 26 > > functions, I get a nested alist with two elements. > What's the worst that can happen in this case? We get a nested submenu > with just one element? Probably. > > However, in an emacs-lisp-mode buffer, we get things like "Variables" > > and "*Rescan*", but I've not yet succeeded in causing a nested list with > > just one element. I'm not convinced enough that it couldn't happen, > > though. > > The latter part of the function looks like this (before my patch): > > (let* ((menu (imenu--split-menu index-alist > > (buffer-name))) > > (menu1 (imenu--create-keymap (car menu) > > ========> (cdr (if (< 1 (length (cdr menu))) > > menu > > (car (cdr menu)))) > > 'imenu--menubar-select))) > > (setcdr imenu--menubar-keymap (cdr menu1))))))) > > That `if' form has been there since imenu-update-menubar was first > > written by Karl Heuer in 1997 (commit 0a8e8bc63e3). Presumably, it > > really was needed back then. > If you're implying we can get rid of the check and always return (cdr > menu), I say let's try. I think we can get rid of the check and just use (cdr menu), yes. In master, that is. > >> In any case, imenu--create-keymap is also called from imenu--mouse-menu, > >> which probably needs the same kind of fix. > > Possibly. I've not managed to create the same error in > > imenu--mouse-menu, > (setq imenu-use-popup-menu t) > followed by > M-x imenu > did that for me in the example buffer. Yes, thanks. For me, too. > > but perhaps it could do with the same correction, > > just in case. What do you think? > Yup. Sorry it didn't get into my patch for emacs-27. > > Incidentally, that patch from last night was a bit untidy. I think it > > needs cleaning up a bit. > So how about this one? In my very brief testing, it seems to work, both > in the example buffer, and for imenu indices in several bigger files: > diff --git a/lisp/imenu.el b/lisp/imenu.el > index fb8b3de662..809ddd7ed1 100644 > --- a/lisp/imenu.el > +++ b/lisp/imenu.el > @@ -814,9 +814,7 @@ imenu--mouse-menu > (setq index-alist (imenu--split-submenus index-alist)) > (let* ((menu (imenu--split-menu index-alist (or title (buffer-name)))) > (map (imenu--create-keymap (car menu) > - (cdr (if (< 1 (length (cdr menu))) > - menu > - (car (cdr menu))))))) > + (cdr menu)))) > (popup-menu map event))) > (defun imenu-choose-buffer-index (&optional prompt alist) > @@ -912,9 +910,7 @@ imenu-update-menubar > (let* ((menu (imenu--split-menu index-alist > (buffer-name))) > (menu1 (imenu--create-keymap (car menu) > - (cdr (if (< 1 (length (cdr menu))) > - menu > - (car (cdr menu)))) > + (cdr menu) > 'imenu--menubar-select))) > (setcdr imenu--menubar-keymap (cdr menu1))))))) I think this would be a good patch for master. I don't think Eli would let it into the release branch, though I may be wrong. Maybe for the release branch he would let in a patch like the one I've already applied. imenu is _complicated_. -- Alan Mackenzie (Nuremberg, Germany).