* 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).