unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#38749: 27.0.50; objc-mode: wrong imenu item
       [not found] <66aa470b-7c40-4eeb-ba54-1af0adf1fc50@Spark>
@ 2019-12-26 10:31 ` HaiJun Zhang
  2020-01-06 18:07   ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: HaiJun Zhang @ 2019-12-26 10:31 UTC (permalink / raw)
  To: Emanuel, Berg, via, Bug, reports, for, GNU, Emacs, 38749

[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]

In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin17.7.0, NS appkit-1561.61 Version 10.13.6 (Build 17G10021))
 of 2019-12-23 built on jundeMac
Repository revision: 3ee8ee8476fef2a5e8159f7597e36e0953295ce2
Repository branch: mod
Windowing system distributor ‘Apple', version 10.3.1561
System Description: Mac OS X 10.13.6

Open file nsfns.m in emacs source(src/nsfns.m). Many imenu items are invalid.
For example, “C/Copyright” and some more are in the header comment.


Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Quit
Configured using:
 ‘configure —with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp’ --with-modules --disable-acl
 —without-makeinfo CFLAGS=-O2’

Configured features:
RSVG GLIB NOTIFY KQUEUE GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: zh_CN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ObjC//l

Minor modes in effect:
  bug-reference-prog-mode: t
  ido-everywhere: t
  global-hl-line-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils thingatpt imenu
bug-reference cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs octave smie comint ansi-color ring
package easymenu browse-url url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars cl-loaddefs cl-lib windmove ido seq byte-opt gv bytecomp
byte-compile cconv display-line-numbers hl-line china-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win
ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 92568 6733)
 (symbols 48 10865 0)
 (strings 32 31238 1963)
 (string-bytes 1 1102306)
 (vectors 16 18200)
 (vector-slots 8 265523 13352)
 (floats 8 31 33)
 (intervals 56 467 0)
 (buffers 1000 12))


[-- Attachment #2: Type: text/html, Size: 5077 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#38749: 27.0.50; objc-mode: wrong imenu item
  2019-12-26 10:31 ` bug#38749: 27.0.50; objc-mode: wrong imenu item HaiJun Zhang
@ 2020-01-06 18:07   ` Alan Mackenzie
  2020-01-07  2:09     ` HaiJun Zhang
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-01-06 18:07 UTC (permalink / raw)
  To: HaiJun Zhang; +Cc: for, Bug, Emanuel, Emacs, 38749, reports, GNU, Berg, via

Hello, HaiJun.

On Thu, Dec 26, 2019 at 18:31:55 +0800, HaiJun Zhang wrote:
> In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin17.7.0, NS appkit-1561.61 Version 10.13.6 (Build 17G10021))
>  of 2019-12-23 built on jundeMac
> Repository revision: 3ee8ee8476fef2a5e8159f7597e36e0953295ce2
> Repository branch: mod
> Windowing system distributor ‘Apple', version 10.3.1561
> System Description: Mac OS X 10.13.6

> Open file nsfns.m in emacs source(src/nsfns.m). Many imenu items are invalid.
> For example, “C/Copyright” and some more are in the header comment.

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.

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.

Getting spurious entries in the index, like "Copyright" also is clearly
annoying, otherwise you wouldn't have submitted the bug report.  So
please give me a little time to decide which annoyance is the more
important.  Sorry!

-- 
Alan Mackenzie (Nuremberg, Germany).





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#38749: 27.0.50; objc-mode: wrong imenu item
  2020-01-06 18:07   ` Alan Mackenzie
@ 2020-01-07  2:09     ` HaiJun Zhang
  2020-01-07 20:53       ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: HaiJun Zhang @ 2020-01-07  2:09 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: for, Bug, Emanuel, Emacs, 38749, reports, GNU, Berg, via

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

在 2020年1月7日 +0800 AM2:08,Alan Mackenzie <acm@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.
>

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'm not familiar with objc. What about searching the char '{' after the current pattern? But then I see the following snippet in nsfns.m:

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.
   ————————————————————————————————————— */
{



[-- Attachment #2: Type: text/html, Size: 2769 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#38749: 27.0.50; objc-mode: wrong imenu item
  2020-01-07  2:09     ` HaiJun Zhang
@ 2020-01-07 20:53       ` Alan Mackenzie
  2020-01-08  4:03         ` HaiJun Zhang
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-01-07 20:53 UTC (permalink / raw)
  To: HaiJun Zhang; +Cc: 38749

Hello, HaiJun.

On Tue, Jan 07, 2020 at 10:09:49 +0800, HaiJun Zhang wrote:
> 在 2020年1月7日 +0800 AM2:08,Alan Mackenzie <acm@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).





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#38749: 27.0.50; objc-mode: wrong imenu item
  2020-01-07 20:53       ` Alan Mackenzie
@ 2020-01-08  4:03         ` HaiJun Zhang
  2020-01-08  7:09           ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: HaiJun Zhang @ 2020-01-08  4:03 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 38749

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

I tried. It is fixed. Thanks.
在 2020年1月8日 +0800 AM4:54,Alan Mackenzie <acm@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@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).

[-- Attachment #2: Type: text/html, Size: 5086 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#38749: 27.0.50; objc-mode: wrong imenu item
  2020-01-08  4:03         ` HaiJun Zhang
@ 2020-01-08  7:09           ` Alan Mackenzie
  0 siblings, 0 replies; 6+ messages in thread
From: Alan Mackenzie @ 2020-01-08  7:09 UTC (permalink / raw)
  To: HaiJun Zhang; +Cc: 38749-done

Hello, HaiJun.

On Wed, Jan 08, 2020 at 12:03:32 +0800, HaiJun Zhang wrote:
> I tried. It is fixed. Thanks.

OK, Thanks!  I'm closing the bug with this post.

> 在 2020年1月8日 +0800 AM4:54,Alan Mackenzie <acm@muc.de>,写道:
> > Hello, HaiJun.

[ .... ]

> > Could I ask you to try out the new code, and if everything's OK, we can
> > close the bug as fixed.

--
Alan Mackenzie (Nuremberg, Germany).





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-01-08  7:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <66aa470b-7c40-4eeb-ba54-1af0adf1fc50@Spark>
2019-12-26 10:31 ` bug#38749: 27.0.50; objc-mode: wrong imenu item HaiJun Zhang
2020-01-06 18:07   ` Alan Mackenzie
2020-01-07  2:09     ` HaiJun Zhang
2020-01-07 20:53       ` Alan Mackenzie
2020-01-08  4:03         ` HaiJun Zhang
2020-01-08  7:09           ` Alan Mackenzie

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).