GNU bug report logs - #38749
27.0.50; objc-mode: wrong imenu item

Previous Next

Packages: emacs, cc-mode;

Reported by: HaiJun Zhang <netjune <at> outlook.com>

Date: Thu, 26 Dec 2019 10:33:01 UTC

Severity: normal

Found in version 27.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 38749 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 38749 <at> debbugs.gnu.org
Subject: Re: bug#38749: 27.0.50; objc-mode: wrong imenu item
Date: Wed, 8 Jan 2020 12:03:32 +0800
[Message part 1 (text/plain, inline)]
I tried. It is fixed. Thanks.
在 2020年1月8日 +0800 AM4:54,Alan Mackenzie <acm <at> muc.de>,写道:
> Hello, HaiJun.
>
> On Tue, Jan 07, 2020 at 10:09:49 +0800, HaiJun Zhang wrote:
> > 在 2020年1月7日 +0800 AM2:08,Alan Mackenzie <acm <at> muc.de>,写道:
> > > I've just spent some time fixing a more serious bug in the
> > > Objective-C imenu mechanism. This only occurs when I invoke imenu
> > > through the keyboard (e.g. with M-x imenu), which might explain why
> > > it's survived so long without detection. If I invoke imenu with a
> > > mouse click, it works.
>
> > > Anyhow, with nsfns.m, do M-x imenu <tab> C <tab> and select any
> > > item. This works. Now do M-x imenu. This throws the error "Wrong
> > > type argument: stringp, nil".
>
> > > I've fixed this now, but haven't committed the fix yet.
>
> It turns out, that bug had been fixed in the Emacs core version of CC
> Mode back in 2012. ;-)
>
> > Thanks.
>
> > > Back to your bug - clearly what is happening is that the regular
> > > expression search for functions is finding things in comments (such as
> > > "Copyright (C)") which look like functions but aren't. This is easy
> > > enough to fix, by checking for comments and strings, but comes with a
> > > fairly stiff time penalty. On my 2½ year old Ryzen machine, scanning
> > > the freshly visited Objc buffer currently takes 0.0196s. With the check
> > > for comments/strings, it takes 0.0650s.
>
> > > That's a factor of ~3.25 slower. On a slower machine (factor 3) with a
> > > larger file (factor 3) this could mean the scanning would take 0.6s
> > > rather than 0.2s. This might be slow enough to annoy somebody a little.
>
> I tried the timings again this evening, and I no longer see this factor
> of ~3 slowdown. In fact just a few 10s of percent.
>
> So I've committed this fix, both to standalone CC Mode and the emacs-27
> branch at savannah (from where it will soon find its way to the master
> branch).
>
> > I'm not familiar with objc. What about searching the char '{' after
> > the current pattern? But then I see the following snippet in nsfns.m:
>
> This isn't needed any more
>
> > static Lisp_Object
> > interpret_services_menu (NSMenu *menu, Lisp_Object prefix, Lisp_Object old)
> > /* —————————————————————————————————————
> >    Turn the input menu (an NSMenu) into a lisp list for tracking on lisp side.
> >    ————————————————————————————————————— */
> > {
>
> Could I ask you to try out the new code, and if everything's OK, we can
> close the bug as fixed.
>
> Thanks!
>
> --
> Alan Mackenzie (Nuremberg, Germany).
[Message part 2 (text/html, inline)]

This bug report was last modified 5 years and 138 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.