GNU bug report logs - #22884
25.0.92; C/l mode editing takes waaaayy too long

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22884 in the body.
You can then email your comments to 22884 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: GNU Emacs bugs <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 2 Mar 2016 10:08:53 -0800

[Message part 1 (text/plain, inline)]

I've been noticing this problem for a bit and figured it'd get fixed but 
it hasn't so here is a bug report.

With the Emacs 25 pretests, it takes waaaaayyy too long to edit some C 
code. To reproduce the problem use the attached file (taken from the 
Emacs source code) and run:

emacs -Q config.h
M-x goto-line RET 1661 RET / /

On my six-year-old desktop the second '/' takes about 10 seconds to 
echo.  This sort of thing makes Emacs effectively unusable for editing 
config.h.


In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.7)
 of 2016-03-02 built on penguin.cs.ucla.edu
Repository revision: 100346aa226e4eacc56f390c099bb9aab585b5f4
Windowing system distributor 'Fedora Project', version 11.0.11800000
Configured using:
 'configure --enable-gcc-warnings'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: C/l

Minor modes in effect:
  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

Recent messages:
config.h has auto save data; consider M-x recover-this-file
Mark set
You can run the command ‘goto-line’ with M-g g
Mark set
Undo!
Mark set
Undo!
Mark set
Mark saved where search started
Auto-saving...done

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils character-fold
misearch multi-isearch cl-extra help-mode cc-mode cc-fonts easymenu
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer 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
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 123955 4665)
 (symbols 48 21742 0)
 (miscs 40 57 290)
 (strings 32 28264 16097)
 (string-bytes 1 748499)
 (vectors 16 14562)
 (vector-slots 8 502379 4556)
 (floats 8 166 20)
 (intervals 56 4059 0)
 (buffers 976 12)
 (heap 1024 29227 2318))

[config.h (text/plain, attachment)]

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 12:49:10 +0000

Hello, Paul.

On Wed, Mar 02, 2016 at 10:08:53AM -0800, Paul Eggert wrote:
> I've been noticing this problem for a bit and figured it'd get fixed but 
> it hasn't so here is a bug report.

> With the Emacs 25 pretests, it takes waaaaayyy too long to edit some C 
> code. To reproduce the problem use the attached file (taken from the 
> Emacs source code) and run:

> emacs -Q config.h
> M-x goto-line RET 1661 RET / /

> On my six-year-old desktop the second '/' takes about 10 seconds to 
> echo.  This sort of thing makes Emacs effectively unusable for editing 
> config.h.

The problem is in config.h.  At line 14, inside a comment, appears the
following string:
    "(at your option) any later version."
.  The open paren is at column zero, so the fancy code in syntax.c then
fails to recognise the comment as a comment.  CC Mode is then
effectively communicating across the continent between L1661 and L14 by
carrier pigeon in the belief that there is non-syntactic-ws code at L14.
(Syntactic whitespace includes comments and preprocessor constructs.)

Inserting a backslash at the beginning of L14 solves the problem, as
does setting open-paren-in-column-0-is-defun-start to nil.

The next problem is that there are around 324 occurrences of "(" at
column zero in the src directory, and quite a few in lib and lib-src.
Most of them are in comments, some of them are parameter lists, and some
of them (e.g. in lisp.h) are wierd constructs of some sort.  These
contravene GNU coding standards and really need sorting out.

> In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.7)
>   of 2016-03-02 built on penguin.cs.ucla.edu
> Repository revision: 100346aa226e4eacc56f390c099bb9aab585b5f4
> Windowing system distributor 'Fedora Project', version 11.0.11800000
> Configured using:
>   'configure --enable-gcc-warnings'

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 09:54:54 -0800

[Message part 1 (text/plain, inline)]

On 03/03/2016 04:49 AM, Alan Mackenzie wrote:
> Inserting a backslash at the beginning of L14 solves the problem, as 
> does setting open-paren-in-column-0-is-defun-start to nil.

I presume the latter is not really on the table. We can't put a 
backslash there, as it's license text and shouldn't be fiddled with in 
that way. We could fold it differently (as in the attached proposed 
patch, which does this only for config.h and friends).

> The next problem is that there are around 324 occurrences of "(" at 
> column zero in the src directory, and quite a few in lib and lib-src. 
> Most of them are in comments, some of them are parameter lists, and 
> some of them (e.g. in lisp.h) are wierd constructs of some sort. These 
> contravene GNU coding standards and really need sorting out.

The lisp.h constructs are weird, but they don't violate the GNU coding 
standards as the parens at the start of a line do indeed mark the start 
of a function definition. Do these parens break cc-mode somehow? If so, 
what's the breakage? and how would you suggest reformatting lisp.h 
(and/or fixing cc-mode)?

The attached proposed patch fixes all the problems I found, except (1) 
it leaves license wording alone for the most part (config.h excepted, 
since the performance disaster is there), and (2) it leaves the weird 
lisp.h constructs alone as per the above paragraph. Is this the sort of 
thing you had in mind (except I guess we need to fix (1) too?).

[emacs.diff (text/x-patch, attachment)]

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 19:23:30 +0000

Hello, Paul.

First of all, congratulations on getting such a long patch prepared by
10 o'clock in the morning.  :-)

On Thu, Mar 03, 2016 at 09:54:54AM -0800, Paul Eggert wrote:
> On 03/03/2016 04:49 AM, Alan Mackenzie wrote:
> > Inserting a backslash at the beginning of L14 solves the problem, as 
> > does setting open-paren-in-column-0-is-defun-start to nil.

> I presume the latter is not really on the table.

No, indeed not.

> We can't put a backslash there, as it's license text and shouldn't be
> fiddled with in that way. We could fold it differently (as in the
> attached proposed patch, which does this only for config.h and
> friends).

Why only for the one file?  The performance hit comes from the amount of
contiguous syntactic whitespace following the "failed" comment.  Have
you checked this is the only file with so much SWS?

The effect of of these "failed" comments on CC Mode is as follows:
c-beginning-of-statement-1 uses c-backward-syntactic-ws.  The latter
goes back to just before the ostensible "//" comment marker in the GNU
URL, that is, just after "http:".  c-beginning-of-statement-1 then moves
back over the "label", then moves back one sexp at a time, looking for
statement boundaries, keywords, etc.  It recognises "for" in "for more
details" as a C keyword, assumes that "more" is the parenthetical
expression and that "details" is the beginning of the substatement.

Although this (probably) won't hit the performance in most files, it is
going to throw out the syntactic analysis sometimes.  Is there any
chance you could put in the refolding of the copyright message into all
the files, to avoid this?

By the way, I've tried out your patch.  It applies fine to the emacs-25
branch, it builds OK, and the new Emacs seems to start and run OK.

> > The next problem is that there are around 324 occurrences of "(" at 
> > column zero in the src directory, and quite a few in lib and lib-src. 
> > Most of them are in comments, some of them are parameter lists, and 
> > some of them (e.g. in lisp.h) are wierd constructs of some sort. These 
> > contravene GNU coding standards and really need sorting out.

> The lisp.h constructs are weird, but they don't violate the GNU coding 
> standards as the parens at the start of a line do indeed mark the start 
> of a function definition.

OK.  Could you give me a clue as to what they mean, please?  For
example, in

    INLINE EMACS_INT
    (XLI) (Lisp_Object o)
    {
      return lisp_h_XLI (o);
    }

, what does "(XLI)" do?  It looks like a cast, but it's in the wrong
place to be a cast.  It can't be an expansion of the CPP macro "XLI",
surely, lacking, as it does, an argument.  What is this thing?

> Do these parens break cc-mode somehow? If so, what's the breakage? and
> how would you suggest reformatting lisp.h (and/or fixing cc-mode)?

No, they don't cause breakage.

> The attached proposed patch fixes all the problems I found, except (1) 
> it leaves license wording alone for the most part (config.h excepted, 
> since the performance disaster is there), and (2) it leaves the weird 
> lisp.h constructs alone as per the above paragraph. Is this the sort of 
> thing you had in mind (except I guess we need to fix (1) too?).

Yes.  I was half way through constructing such a patch myself, but you
beat me to it.  :-)  As I said above, I'd be happier if you could fix
the license text in all the files.  It cannot be too much work (a short
sed script, or something similar).

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 03 Mar 2016 22:38:36 +0200

> Date: Thu, 3 Mar 2016 19:23:30 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: 22884 <at> debbugs.gnu.org
> 
> OK.  Could you give me a clue as to what they mean, please?  For
> example, in
> 
>     INLINE EMACS_INT
>     (XLI) (Lisp_Object o)
>     {
>       return lisp_h_XLI (o);
>     }
> 
> , what does "(XLI)" do?

It's an age-old method of calling a function without risking it being
shadowed by a macro, AFAIK.

> It can't be an expansion of the CPP macro "XLI", surely, lacking, as
> it does, an argument.

Exactly.  And that's why it ensures a function will be called instead
of the macro.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 03 Mar 2016 22:40:42 +0200

> Date: Thu, 3 Mar 2016 12:49:10 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: 22884 <at> debbugs.gnu.org
> 
> > emacs -Q config.h
> > M-x goto-line RET 1661 RET / /
> 
> > On my six-year-old desktop the second '/' takes about 10 seconds to 
> > echo.  This sort of thing makes Emacs effectively unusable for editing 
> > config.h.
> 
> The problem is in config.h.  At line 14, inside a comment, appears the
> following string:
>     "(at your option) any later version."
> .  The open paren is at column zero, so the fancy code in syntax.c then
> fails to recognise the comment as a comment.

I think we should change syntax.c to fix this.  (Alternatively, CC
mode could stop depending on it, but I doubt this is a viable
alternative.)  We cannot really tell people we don't support such
files, as they are valid C code.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: acm <at> muc.de, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 03 Mar 2016 22:51:42 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 3 Mar 2016 09:54:54 -0800
> Cc: 22884 <at> debbugs.gnu.org
> 
> The attached proposed patch fixes all the problems I found, except (1) 
> it leaves license wording alone for the most part (config.h excepted, 
> since the performance disaster is there), and (2) it leaves the weird 
> lisp.h constructs alone as per the above paragraph. Is this the sort of 
> thing you had in mind (except I guess we need to fix (1) too?).

Thanks.  However, I'd rather we fixed CC Mode instead of "fixing" the
sources it chokes on.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 13:57:11 -0800

On 03/03/2016 11:23 AM, Alan Mackenzie wrote:
> Why only for the one file?

Because I didn't have time to fix all the source files (I was about to 
rush off and teach a class....). It could easily be added, at least for 
files we maintain. Though, as Eli says, it'd be nicer if cc-mode didn't 
think lines beginning with '(' were relevant for function-start in C.

> The performance hit comes from the amount of contiguous syntactic 
> whitespace following the "failed" comment. Have you checked this is 
> the only file with so much SWS?

No. It's easier for me to simply fix all instances of code that have '(' 
at line start. I can propose a more-complete patch along those lines.

>
> OK.  Could you give me a clue as to what they mean, please?  For
> example, in
>
>      INLINE EMACS_INT
>      (XLI) (Lisp_Object o)
>      {
>        return lisp_h_XLI (o);
>      }
>
> , what does "(XLI)" do?

It defines a function named 'XLI' even though there's also a 
function-like macro named 'XLI', without expanding the macro.

> No, they don't cause breakage.

Good, in that case we can leave them alone.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 22:27:49 +0000

Hello, Eli.

On Thu, Mar 03, 2016 at 10:40:42PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Mar 2016 12:49:10 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: 22884 <at> debbugs.gnu.org

> > > emacs -Q config.h
> > > M-x goto-line RET 1661 RET / /

> > > On my six-year-old desktop the second '/' takes about 10 seconds to 
> > > echo.  This sort of thing makes Emacs effectively unusable for editing 
> > > config.h.

> > The problem is in config.h.  At line 14, inside a comment, appears the
> > following string:
> >     "(at your option) any later version."
> > .  The open paren is at column zero, so the fancy code in syntax.c then
> > fails to recognise the comment as a comment.

> I think we should change syntax.c to fix this.

In particular, get syntax.c to recognise open parens in column zero as
defun starts _ONLY_ when they're not in strings or comments.  This will
clearly impact performance to some (unknown) degree.

> (Alternatively, CC mode could stop depending on it, but I doubt this is
> a viable alternative.)

This was tried for some time, by internally binding
open-paren-in-column-0-is-defun-start to nil.  It cost too much in
performance on large files (ask Martin!).

> We cannot really tell people we don't support such files, as they are
> valid C code.

I agree.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 22:59:49 +0000

Hello, Paul.

On Thu, Mar 03, 2016 at 01:57:11PM -0800, Paul Eggert wrote:
> On 03/03/2016 11:23 AM, Alan Mackenzie wrote:
> > Why only for the one file?

> Because I didn't have time to fix all the source files .... It could
> easily be added, at least for files we maintain. Though, as Eli says,
> it'd be nicer if cc-mode didn't think lines beginning with '(' were
> relevant for function-start in C.

This is an Emacs thing rather than a CC Mode one.  It's all about how
syntax.c goes backwards over a comment.  You've just gone back over a
comment ender, so you start searching for the comment starter, but when
do you stop and give up?  Currently the answer is at a paren in column
zero (unless open-paren-in-column-0-is-defun-start is nil).

It's a difficult problem.  In previous versions of CC Mode,
open-paren-..-start was bound to nil internally, "solving" the problem,
but at an unacceptable cost in performance, particularly when editing
later portions of a large file.

> > The performance hit comes from the amount of contiguous syntactic 
> > whitespace following the "failed" comment. Have you checked this is 
> > the only file with so much SWS?

> No. It's easier for me to simply fix all instances of code that have '(' 
> at line start. I can propose a more-complete patch along those lines.

OK.

> > OK.  Could you give me a clue as to what they mean, please?  For
> > example, in

> >      INLINE EMACS_INT
> >      (XLI) (Lisp_Object o)
> >      {
> >        return lisp_h_XLI (o);
> >      }

> > , what does "(XLI)" do?

> It defines a function named 'XLI' even though there's also a 
> function-like macro named 'XLI', without expanding the macro.

Ah, thank you!  Now you've explained it, it's obvious.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 23:18:23 +0000

Hello, Eli.

On Thu, Mar 03, 2016 at 10:40:42PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Mar 2016 12:49:10 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: 22884 <at> debbugs.gnu.org

> > > emacs -Q config.h
> > > M-x goto-line RET 1661 RET / /

> > > On my six-year-old desktop the second '/' takes about 10 seconds to 
> > > echo.  This sort of thing makes Emacs effectively unusable for editing 
> > > config.h.

> > The problem is in config.h.  At line 14, inside a comment, appears the
> > following string:
> >     "(at your option) any later version."
> > .  The open paren is at column zero, so the fancy code in syntax.c then
> > fails to recognise the comment as a comment.

> I think we should change syntax.c to fix this.  (Alternatively, CC
> mode could stop depending on it, but I doubt this is a viable
> alternative.)  We cannot really tell people we don't support such
> files, as they are valid C code.

Would it be practicable to mark comments with text properties?  Say, a
property called `comment-depth' which would be either nil (meaning
currently unknown), 0 (definitely not in a comment), 1 (definitely in a
comment), 2 (in a nested comment), 3, ...... ?  That way we could always
scan comments in the forwards direction (which is easy) - if we need to
go backwards over a comment without the property, we can just go back to
a known point and scan forward.

Or would this just overwhelm the text property mechanism?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 15:44:05 -0800

[Message part 1 (text/plain, inline)]

On 03/03/2016 12:51 PM, Eli Zaretskii wrote:
> I'd rather we fixed CC Mode instead of "fixing" the
> sources it chokes on.

Me too, but I don't see a straightforward cc-mode fix for this.

Even if we come up with a fix, for some time we'll have the problem of 
people using old versions of Emacs to look at the new Emacs source code. 
And until there's a fix Emacs is reeeaally sluggish when editing 
config.h at least. So I'd rather fix at least config.h, and (since I've 
already done the work) I'm also mildly inclined to fix the other files 
to be consistent, as in the attached patch (which also covers licenses 
in the other .c and .h files).

[0001-Rework-C-source-files-to-avoid.fix (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 04 Mar 2016 10:32:56 +0200

> Date: Thu, 3 Mar 2016 23:18:23 +0000
> Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> Would it be practicable to mark comments with text properties?  Say, a
> property called `comment-depth' which would be either nil (meaning
> currently unknown), 0 (definitely not in a comment), 1 (definitely in a
> comment), 2 (in a nested comment), 3, ...... ?  That way we could always
> scan comments in the forwards direction (which is easy) - if we need to
> go backwards over a comment without the property, we can just go back to
> a known point and scan forward.

I don't see any immediate problems with this.  But doesn't creating
these properties require to solve the same problem with the specific
cases we are discussing now?

> Or would this just overwhelm the text property mechanism?

No, I don't think it should.  Text properties scale reasonably well.
And we already have the same with faces (since comments have a
specific face), don't we?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 09:37:07 +0000

Hello, Eli.

On Fri, Mar 04, 2016 at 10:32:56AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Mar 2016 23:18:23 +0000
> > Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > Would it be practicable to mark comments with text properties?  Say, a
> > property called `comment-depth' which would be either nil (meaning
> > currently unknown), 0 (definitely not in a comment), 1 (definitely in a
> > comment), 2 (in a nested comment), 3, ...... ?  That way we could always
> > scan comments in the forwards direction (which is easy) - if we need to
> > go backwards over a comment without the property, we can just go back to
> > a known point and scan forward.

> I don't see any immediate problems with this.  But doesn't creating
> these properties require to solve the same problem with the specific
> cases we are discussing now?

No, it doesn't.  The difficulties with scanning comments only happen when
scanning backwards.  For example, on scanning backwards for a putative
line comment, we're only guessing that there's going to be a "//" earlier
in the line.  And that token might easily be inside a string, so we've
got to keep track of string delimiters, too.  Etc.
open-paren-in-column-0-is-defun-start is only tested twice in syntax.c,
the "most important" time being in `back-comment', where we break off the
scanning when it is non-nil and we've found an open paren at column zero.

By contrast, scanning comments going forward is trivial.  We see the
opening comment delimiter, and scan forward for the closing one, ignoring
strings, possibly nested openers (/*.../*..*/), and so on.

So a (forward-comment -1) would just involve going back over the closing
delimiter and searching back for the `comment-depth' property being zero.
If the property was unset at that point, we go back to the last place it
is set and scan comments forward till we get back to our starting place.

Additionally, we'd need to zap the property between point and EOB on each
buffer change.  Not difficult.

> > Or would this just overwhelm the text property mechanism?

> No, I don't think it should.  Text properties scale reasonably well.
> And we already have the same with faces (since comments have a
> specific face), don't we?

Then we have a project!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 14:47:59 +0000

Hello, Paul.

On Thu, Mar 03, 2016 at 03:44:05PM -0800, Paul Eggert wrote:
> On 03/03/2016 12:51 PM, Eli Zaretskii wrote:
> > I'd rather we fixed CC Mode instead of "fixing" the
> > sources it chokes on.

> Me too, but I don't see a straightforward cc-mode fix for this.

> Even if we come up with a fix, for some time we'll have the problem of 
> people using old versions of Emacs to look at the new Emacs source code. 
> And until there's a fix Emacs is reeeaally sluggish when editing 
> config.h at least. So I'd rather fix at least config.h, and (since I've 
> already done the work) I'm also mildly inclined to fix the other files 
> to be consistent, as in the attached patch (which also covers licenses 
> in the other .c and .h files).

Thanks for the (new) patch.  I've tried it out, and it appears to build
and run just fine.

I have had an idea for fixing Emacs so that we don't have this problem
with parens in column 0.  That is only to scan comments in the forward
direction, and to mark them with text properties.  `back_comment' will
then be little more than checking these text properties are up to date,
and then doing a backward text property search.

> From c7c5fa7e01492963aab142d91b00cb872cb49686 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 3 Mar 2016 15:42:28 -0800
> Subject: [PATCH] Rework C source files to avoid ^(
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit

> Work around Bug#22884 by rewording comments and strings to avoid ‘(’
> at the start of a line unless it starts a function.  Although this
> change is a hack and we should fix cc-mode’s performance for C files
> that have ‘(’ at the start of a line in a comment or string, the
> change does fix the immediate problem.
> ---

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 12:32:06 -0800

Alan Mackenzie wrote:
> I have had an idea for fixing Emacs so that we don't have this problem
> with parens in column 0.  That is only to scan comments in the forward
> direction, and to mark them with text properties.  `back_comment' will
> then be little more than checking these text properties are up to date,
> and then doing a backward text property search.

Would this mean we no longer need to put \( into Elisp doc strings too? It has 
always been annoying that we have to do that.

If it's practical to fold your idea into the emacs-25 branch it sounds like 
it'll solve the problem. If it's safer to put such a change into the master 
branch, I can install the patch I already wrote into the emacs-25 branch, as a 
stopgap. What do you think?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 21:08:18 +0000

Hello, Paul.

On Fri, Mar 04, 2016 at 12:32:06PM -0800, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > I have had an idea for fixing Emacs so that we don't have this problem
> > with parens in column 0.  That is only to scan comments in the forward
> > direction, and to mark them with text properties.  `back_comment' will
> > then be little more than checking these text properties are up to date,
> > and then doing a backward text property search.

> Would this mean we no longer need to put \( into Elisp doc strings too? It has 
> always been annoying that we have to do that.

It would mean this, yes.  open-paren-in-column-0-is-defun-start would
become obsolete.

> If it's practical to fold your idea into the emacs-25 branch it sounds like 
> it'll solve the problem. If it's safer to put such a change into the master 
> branch, I can install the patch I already wrote into the emacs-25 branch, as a 
> stopgap. What do you think?

Definitely the master branch.  The change is far too involved to slip
into emacs-25 at this late stage.  So I think you should install your
patch.

The new scheme would come with some restrictions: the use of category
properties to effect instantaeous global changes to syntax-table text
properties throughout a buffer would have to be deprecated (i.e.
forbidden).  CC Mode currently does this.  Setting
`inhibit-modification-hooks' non-nil and making substantive buffer
changes would likewise be taboo.  There may be other minor restrictions.
Because of this, it might be an idea to make the new comment handling
optional (default on).

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Tue, 8 Mar 2016 14:02:05 +0000

Hello, Paul.

On Fri, Mar 04, 2016 at 12:32:06PM -0800, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > I have had an idea for fixing Emacs so that we don't have this problem
> > with parens in column 0.  That is only to scan comments in the forward
> > direction, and to mark them with text properties.  `back_comment' will
> > then be little more than checking these text properties are up to date,
> > and then doing a backward text property search.

> Would this mean we no longer need to put \( into Elisp doc strings too? It has 
> always been annoying that we have to do that.

> If it's practical to fold your idea into the emacs-25 branch it sounds like 
> it'll solve the problem. If it's safer to put such a change into the master 
> branch, I can install the patch I already wrote into the emacs-25 branch, as a 
> stopgap. What do you think?

OK, I've hacked this out and committed it to the new branch
"comment-cache", branched off of master.

To use it, (setq comment-cacheing-flag t), and enjoy!  The old
`back_comment' is still in syntax.c, renamed to `old_back_comment', and
it is used when that flag is left at nil.

There should no longer be any restrictions about open parentheses in
column 0, neither in comments nor in strings.
open-paren-in-column-0-is-defun-start should now be a relic (although it
still appears in some lisp files).

At the moment, the code only uses the cached information (on the
`comment-depth' text property) for moving backwards over comments.  It
could be enhanced also to use this information for moving back over
strings, or moving forward over comments and strings, but this is more
of an optimisation than new functionality, and I'm not convinced the
saving would be all that much.  (At the end of any such move, the
variables `from' and `from_byte' are out of synch, and a CHAR_TO_BYTE
invocation is necessary.  I don't know how slow or fast this is.)

As I've said already, the new scheme comes with one or two minor
restrictions: any Lisp code which chnages the syntax table in a way
which affects how literals are handled needs also to call
`trim-comment-cache' to invalidate the cache.  The same applies to
anybody tweaking the `syntax-table' property of a symbol which is the
value of a `category' text property.  CC Mode does the latter
extensively, and I'll need to prepare a version which doesn't do this.

At the moment, the code hasn't yet been tested with nestable comments,
or `category' text properties.  Can you recommend me a major mode with
nestable comments?  I haven't really tested it for narrowing, either, or
anything like indirect buffers.  

I'm not convinced by the names I've chosen for all the new functions and
variables, and I think I ought to rename "comment-cache" to
"literal-cache", and likewise for all the rest.

Some amendment of the Elisp manual will be needed to document the new
minor restrictions.

I look forward to your comments!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, John Wiegley <johnw <at> gnu.org>,
 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 00:25:19 -0800

Alan Mackenzie wrote:
> Can you recommend me a major mode with
> nestable comments?

How about Coq?  I think John Wiegley is a Coq user and can advise.

I'm afraid I know little about major modes and wouldn't be of much help as a 
reviewer for your patch (though it sounds good).

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>,
 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 09 Mar 2016 01:28:58 -0800

>>>>> Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Alan Mackenzie wrote:
>> Can you recommend me a major mode with nestable comments?

> How about Coq? I think John Wiegley is a Coq user and can advise.

Coq supports (* foo (* bar *) *), in the same way that C does with /* */.  Was
there something more you wanted to know?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Wiegley <johnw <at> gnu.org>
Cc: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>,
 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 01:37:45 -0800

John Wiegley wrote:
> Coq supports (* foo (* bar *) *), in the same way that C does with /* */.

It's not the same way as C, since C comments do not nest.

> Was there something more you wanted to know?

It's up to Alan, but I suppose Alan may want simple directions to try out nested 
comments in Coq, for someone who does not know Coq at all.  E.g., what should 
the file name and contents be, and what emacs -Q keystrokes should one type to 
illustrate how nested comments work.

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

From: Alan Mackenzie <acm <at> muc.de>
To: John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 10:56:08 +0000

Hello, John.

On Wed, Mar 09, 2016 at 01:28:58AM -0800, John Wiegley wrote:
> >>>>> Paul Eggert <eggert <at> cs.ucla.edu> writes:

> > Alan Mackenzie wrote:
> >> Can you recommend me a major mode with nestable comments?

> > How about Coq? I think John Wiegley is a Coq user and can advise.

> Coq supports (* foo (* bar *) *), in the same way that C does with /* */.  Was
> there something more you wanted to know?

Well, C doesn't do nested comments, but it looks like Coq does.  I need
a mode and some code to test nested comments with.

Can you give me a URL for coq-mode.el, and possibly a sample Coq file
(doesn't need to be anything fancy or long).

Thanks!

> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>, John Wiegley <johnw <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 22884 <at> debbugs.gnu.org
Subject: RE: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 06:44:31 -0800 (PST)

I'm not following this thread, but Common Lisp has nested
block comments, and they are very well specified in the
spec/standard.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22884 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 17:04:42 +0000

Hello, Drew.

On Wed, Mar 09, 2016 at 06:44:31AM -0800, Drew Adams wrote:
> I'm not following this thread, but Common Lisp has nested
> block comments, and they are very well specified in the
> spec/standard.

Thank you, thank you!  Those nested comments in Lisp were just what I
needed.  And yes, I found a problem in my code.

So, if you're still listening, John, I don't need the Coq URL and files
any more.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22884 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: RE: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 9 Mar 2016 09:14:53 -0800 (PST)

> Hello, Drew.
> 
> > I'm not following this thread, but Common Lisp has nested
> > block comments, and they are very well specified in the
> > spec/standard.
> 
> Thank you, thank you!  Those nested comments in Lisp were
> just what I needed.  And yes, I found a problem in my code.

Glad it helped.  In general, I think it would be good if more
Emacs Dev hackers were a bit more familiar with Common Lisp.

"Common Lisp The Language" is very readable, and it explicitly
presents the _reasons_ for many of the design decisions etc.

You can read it from front to back.  It is truly a pleasure to
dig into, and Guy Steele is a good writer.  Consider curling up
with it on one of these cold or rainy nights.  You won't regret it.

https://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html

I still have and use the first edition.  The 2nd is longer and
includes `loop', CLOS, etc. but the meat is essentially the same.

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>,
 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Wed, 09 Mar 2016 13:30:38 -0800

>>>>> Paul Eggert <eggert <at> cs.ucla.edu> writes:

> John Wiegley wrote:
>> Coq supports (* foo (* bar *) *), in the same way that C does with /* */.

> It's not the same way as C, since C comments do not nest.

Ah, there are some C compilers (Borland I think?) that allowed nested comments
in C as an extension. But you're right, standard C does not.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Sun, 13 Mar 2016 10:03:54 +0000

Hello, Paul.

On Fri, Mar 04, 2016 at 09:08:18PM +0000, Alan Mackenzie wrote:
> On Fri, Mar 04, 2016 at 12:32:06PM -0800, Paul Eggert wrote:
> > Alan Mackenzie wrote:
> > > I have had an idea for fixing Emacs so that we don't have this problem
> > > with parens in column 0.  That is only to scan comments in the forward
> > > direction, and to mark them with text properties.  `back_comment' will
> > > then be little more than checking these text properties are up to date,
> > > and then doing a backward text property search.

> > Would this mean we no longer need to put \( into Elisp doc strings too? It has 
> > always been annoying that we have to do that.

> It would mean this, yes.  open-paren-in-column-0-is-defun-start would
> become obsolete.

Apologies, but I was mistaken on this point.  Being able to put "(" at
column 0 in Elisp strings would entail some further work, though that
work would not be difficult or disruptive.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Mon, 14 Mar 2016 23:07:58 -0400

[ Just to clarify and keep it in the corresponding bug, rather than in
  some side-thread in emacs-devel.  ]

> emacs -Q config.h
> M-x goto-line RET 1661 RET / /

The patch below seems to fix this pathological case, making the "/ /"
instantaneous again.


        Stefan


diff --git a/src/syntax.c b/src/syntax.c
index 8e14bf3..b712e45 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -597,6 +597,26 @@ find_defun_start (ptrdiff_t pos, ptrdiff_t pos_byte)
       && MODIFF == find_start_modiff)
     return find_start_value;
 
+  if (!NILP (Vcomment_use_syntax_ppss))
+    {
+      EMACS_INT modiffs = CHARS_MODIFF;
+      Lisp_Object ppss = call1 (Qsyntax_ppss, make_number (pos));
+      if (modiffs != CHARS_MODIFF)
+	error ("syntax-ppss modified the buffer!");
+      TEMP_SET_PT_BOTH (opoint, opoint_byte);
+      Lisp_Object boc = Fnth (make_number (8), ppss);
+      if (NUMBERP (boc))
+        {
+          find_start_value = XINT (boc);
+          find_start_value_byte = CHAR_TO_BYTE (find_start_value);
+        }
+      else
+        {
+          find_start_value = pos;
+          find_start_value_byte = pos_byte;
+        }
+      goto found;
+    }
   if (!open_paren_in_column_0_is_defun_start)
     {
       find_start_value = BEGV;
@@ -864,6 +884,7 @@ back_comment (ptrdiff_t from, ptrdiff_t from_byte, ptrdiff_t stop,
 	case Sopen:
 	  /* Assume a defun-start point is outside of strings.  */
 	  if (open_paren_in_column_0_is_defun_start
+              && NILP (Vcomment_use_syntax_ppss)
 	      && (from == stop
 		  || (temp_byte = dec_bytepos (from_byte),
 		      FETCH_CHAR (temp_byte) == '\n')))
@@ -3647,6 +3668,11 @@ void
 syms_of_syntax (void)
 {
   DEFSYM (Qsyntax_table_p, "syntax-table-p");
+  DEFSYM (Qsyntax_ppss, "syntax-ppss");
+  DEFVAR_LISP ("comment-use-syntax-ppss",
+	       Vcomment_use_syntax_ppss,
+	       doc: /* Non-nil means `forward-comment' can use `syntax-ppss' internally.  */);
+  Vcomment_use_syntax_ppss = Qt;
 
   staticpro (&Vsyntax_code_object);
 

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Mon, 9 May 2016 02:10:04 +0300

I think this bug should be made a non-blocker for 25.1: we have a 
workaround in the Emacs sources, and both proposed solutions are better 
suited for master.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 13 May 2016 12:35:00 -0700

Yes, the workaround already installed in the emacs-25 branch (namely, 
mutate the sources so they don't run afoul of the problem) is good 
enough to solve the immediate problem, so I changed the status of 
Bug#22884 so that it is no longer a blocker for emacs-25.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 13 May 2016 16:37:58 -0400

Paul Eggert wrote:

> Yes, the workaround already installed in the emacs-25 branch (namely,
> mutate the sources so they don't run afoul of the problem) is good
> enough to solve the immediate problem, so I changed the status of
> Bug#22884 so that it is no longer a blocker for emacs-25.

What about other C code, besides the Emacs sources?
What if anyone ever wants to edit an older version of the Emacs sources?

Your initial report said: "This sort of thing makes Emacs effectively
unusable for editing [some C code]", which is, y'know, a pretty bad state.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 13 May 2016 14:09:27 -0700

On 05/13/2016 01:37 PM, Glenn Morris wrote:
> What about other C code, besides the Emacs sources?
> What if anyone ever wants to edit an older version of the Emacs sources?

Older versions of Emacs have smaller config.h files, which makes the 
problem significantly smaller. I just now visited a config.h file for 
Emacs 23.4, and the same “type ‘/ /’” benchmark took about two seconds 
on my six-year-old desktop (Fedora 23 x86-64, AMD Phenom II X4 910e). 
Although two seconds is pretty annoying, it's considerably better than 
the ten seconds I was seeing with emacs-25 before we worked around the 
problem there.

Although Non-Emacs sources may have the problem, I imagine it's 
reasonably rare.

> Your initial report said: "This sort of thing makes Emacs effectively
> unusable for editing [some C code]", which is, y'know, a pretty bad state.

Yes, it is indeed a bad state. However, the problematic situations are 
rare and cause slowdowns rather than crashes, so the case for making it 
a blocker is not as strong as it could be.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22884 <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 28 Apr 2022 13:22:14 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Yes, the workaround already installed in the emacs-25 branch (namely,
> mutate the sources so they don't run afoul of the problem) is good
> enough to solve the immediate problem, so I changed the status of
> Bug#22884 so that it is no longer a blocker for emacs-25.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, it's not quite clear to me what the remaining
problems were.  I can confirm that the test case (going to config.h when
there's "(something in a parenthesis in a comment earlier)" and editing)
is still fast on the trunk, so is there anything more to do in this bug
report?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #112 received at 22884-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 22884-done <at> debbugs.gnu.org
Subject: Re: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 28 Apr 2022 12:35:09 -0700

On 4/28/22 04:22, Lars Ingebrigtsen wrote:

> I can confirm that the test case (going to config.h when
> there's "(something in a parenthesis in a comment earlier)" and editing)
> is still fast on the trunk, so is there anything more to do in this bug
> report?

No, I think this was fixed in CC mode a while ago. Thanks for checking. 
I'll close the bug report.

Previous Next

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