bug#23476: 25.0.93; Visiting C files on master signals an error

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

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

If you visit any C file on the master branch with Emacs 25.0.93, Emacs
asks an annoying question about unsafe local variables:


[-- Attachment #2: unsafe.PNG --]
[-- Type: image/png, Size: 11917 bytes --]

[-- Attachment #3: Type: text/plain, Size: 3088 bytes --]


If you answer "y", Emacs signals an error:

  File local-variables error: (void-function c-make-noise-macro-regexps)

If I do the same with Emacs built from master, the problem doesn't
happen.  Did someone assume that the sources on master are only edited
by an Emacs produced from that master?  If so, that's bad assumption.

In GNU Emacs 25.0.93.26 (i686-pc-mingw32)
 of 2016-05-06 built on HOME-C4E4A596F7
Repository revision: c760a600da6dbfa495613aa5042ab073b9490c85
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Configured using:
 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int
 --with-modules 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: C/l

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

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Please type y, n, or !: y
File local-variables error: (void-function c-make-noise-macro-regexps)

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache 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 vc-git
diff-mode easy-mmode 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 dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win 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 w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 16 116432 10734)
 (symbols 56 23147 0)
 (miscs 48 39 108)
 (strings 16 24613 5438)
 (string-bytes 1 744521)
 (vectors 16 15373)
 (vector-slots 8 461756 4184)
 (floats 8 168 57)
 (intervals 40 414 102)
 (buffers 856 12))

bug#23476: 25.0.93; Visiting C files on master signals an error

[Andy Moreton]

On Sat 07 May 2016, Eli Zaretskii wrote:

> If you visit any C file on the master branch with Emacs 25.0.93, Emacs
> asks an annoying question about unsafe local variables:
>
>
>
>
> If you answer "y", Emacs signals an error:
>
>   File local-variables error: (void-function c-make-noise-macro-regexps)
>
> If I do the same with Emacs built from master, the problem doesn't
> happen.  Did someone assume that the sources on master are only edited
> by an Emacs produced from that master?  If so, that's bad assumption.

I assume that is due to c-make-noise-macro-regexps being a new feature
on the master branch. The following patch fixes it for me:

diff --git a/.dir-locals.el b/.dir-locals.el
index 1aa71ff..3725cc1 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -3,7 +3,8 @@
          (fill-column . 70)))
  (c-mode . ((c-file-style . "GNU")
             (c-noise-macro-with-parens-names . ("IF_LINT"))
-            (eval . (c-make-noise-macro-regexps))
+            (eval . (when (fboundp 'c-make-noise-macro-regexps)
+                      (c-make-noise-macro-regexps)))

Regards,

    AndyM

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sat, 07 May 2016 17:43:12 +0100
> 
> On Sat 07 May 2016, Eli Zaretskii wrote:
> 
> > If you visit any C file on the master branch with Emacs 25.0.93, Emacs
> > asks an annoying question about unsafe local variables:
> >
> >
> >
> >
> > If you answer "y", Emacs signals an error:
> >
> >   File local-variables error: (void-function c-make-noise-macro-regexps)
> >
> > If I do the same with Emacs built from master, the problem doesn't
> > happen.  Did someone assume that the sources on master are only edited
> > by an Emacs produced from that master?  If so, that's bad assumption.
> 
> I assume that is due to c-make-noise-macro-regexps being a new feature
> on the master branch. The following patch fixes it for me:

Thanks.  This eliminates the error, but not the annoying question
about unsafe variables.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2016 at 08:32:20PM +0300, Eli Zaretskii wrote:
> > From: Andy Moreton <andrewjmoreton@gmail.com>
> > Date: Sat, 07 May 2016 17:43:12 +0100

> > On Sat 07 May 2016, Eli Zaretskii wrote:

> > > If you visit any C file on the master branch with Emacs 25.0.93, Emacs
> > > asks an annoying question about unsafe local variables:




> > > If you answer "y", Emacs signals an error:

> > >   File local-variables error: (void-function c-make-noise-macro-regexps)

> > > If I do the same with Emacs built from master, the problem doesn't
> > > happen.  Did someone assume that the sources on master are only edited
> > > by an Emacs produced from that master?  If so, that's bad assumption.

Guilty as charged.

> > I assume that is due to c-make-noise-macro-regexps being a new feature
> > on the master branch. The following patch fixes it for me:

Andy, from my point of view, that patch should be committed (to master).

> Thanks.  This eliminates the error, but not the annoying question
> about unsafe variables.

The annoying question, you only need to answer once (with !).  The
setting eliminates the annoying misfontification of the constructs using
the IF_LINT macro, e.g. in window.c, in the following:

    int top IF_LINT (= 0), ...

, top now gets correctly fontified as a variable declaration, not as a
function declaration, as still happens in the emacs-25 branch.

To be fair, I did warn everybody about this in a post to emacs-devl on
2016-04-30.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Sat, 7 May 2016 17:50:30 +0000
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, 23476@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Thanks.  This eliminates the error, but not the annoying question
> > about unsafe variables.
> 
> The annoying question, you only need to answer once (with !).  The
> setting eliminates the annoying misfontification of the constructs using
> the IF_LINT macro, e.g. in window.c, in the following:
> 
>     int top IF_LINT (= 0), ...
> 
> , top now gets correctly fontified as a variable declaration, not as a
> function declaration, as still happens in the emacs-25 branch.

No, I'd like that question to go away completely.  Visiting Emacs
sources shouldn't trigger such questions, IMO it's absurd.

> To be fair, I did warn everybody about this in a post to emacs-devl on
> 2016-04-30.

Why warn?  Just let's not do it at all.

Thanks.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2016 at 09:19:13PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2016 17:50:30 +0000
> > Cc: Andy Moreton <andrewjmoreton@gmail.com>, 23476@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Thanks.  This eliminates the error, but not the annoying question
> > > about unsafe variables.

> > The annoying question, you only need to answer once (with !).  The
> > setting eliminates the annoying misfontification of the constructs using
> > the IF_LINT macro, e.g. in window.c, in the following:

> >     int top IF_LINT (= 0), ...

> > , top now gets correctly fontified as a variable declaration, not as a
> > function declaration, as still happens in the emacs-25 branch.

> No, I'd like that question to go away completely.  Visiting Emacs
> sources shouldn't trigger such questions, IMO it's absurd.

IF_LINT is an absurd macro, and C macros in general are absurd (unlike
Lisp ones).  Something's got to give.

> > To be fair, I did warn everybody about this in a post to emacs-devl on
> > 2016-04-30.

> Why warn?  Just let's not do it at all.

Because the one-time inconvenience (not counting emacs -Q invocations) of
answering the question is far less than the irritation and possible
misunderstading caused by the unvarying mis-fontification of variables
near IF_LINTs (of which there are 84 in the C sources, including 15 in
xdisp.c).

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Sat, 7 May 2016 18:52:25 +0000
> Cc: andrewjmoreton@gmail.com, 23476@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > No, I'd like that question to go away completely.  Visiting Emacs
> > sources shouldn't trigger such questions, IMO it's absurd.
> 
> IF_LINT is an absurd macro, and C macros in general are absurd (unlike
> Lisp ones).  Something's got to give.

Correct fontification is not important enough to be annoyed like
that.  IMO, this cure is worse than the disease.

> > > To be fair, I did warn everybody about this in a post to emacs-devl on
> > > 2016-04-30.
> 
> > Why warn?  Just let's not do it at all.
> 
> Because the one-time inconvenience (not counting emacs -Q invocations) of
> answering the question is far less than the irritation and possible
> misunderstading caused by the unvarying mis-fontification of variables
> near IF_LINTs (of which there are 84 in the C sources, including 15 in
> xdisp.c).

I frequently visit and edit Emacs sources with "emacs -Q", so the
annoyance will be constant for me.

Let's try to find a solution that doesn't involve unsafe values.  I
hope there is such a solution; if not, I'd rather have the macro
mis-fontified than be annoyed by these questions each time I visit an
Emacs source file.

Thanks.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Sat, 07 May 2016 21:57:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23476@debbugs.gnu.org, andrewjmoreton@gmail.com
> 
> Let's try to find a solution that doesn't involve unsafe values.

One way is to turn on by default the feature that fontifies these
macros correctly.  Why does it have to be off by default?

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2016 at 09:57:50PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2016 18:52:25 +0000
> > Cc: andrewjmoreton@gmail.com, 23476@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > IF_LINT is an absurd macro, and C macros in general are absurd (unlike
> > Lisp ones).  Something's got to give.

> Correct fontification is not important enough to be annoyed like
> that.  IMO, this cure is worse than the disease.

Apologies.  I hadn't anticipated this could be so annoying.

[ .... ]

> I frequently visit and edit Emacs sources with "emacs -Q", so the
> annoyance will be constant for me.

> Let's try to find a solution that doesn't involve unsafe values.  I
> hope there is such a solution; if not, I'd rather have the macro
> mis-fontified than be annoyed by these questions each time I visit an
> Emacs source file.

OK.  Let's see what we can do to make this better.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2016 at 10:30:39PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 07 May 2016 21:57:50 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 23476@debbugs.gnu.org, andrewjmoreton@gmail.com

> > Let's try to find a solution that doesn't involve unsafe values.

> One way is to turn on by default the feature that fontifies these
> macros correctly.  Why does it have to be off by default?

The feature is dependent on _configuration_: the '("IF_LINT") is that
configuration.  After reading the list of "noise macros", CC Mode has to
turn them into a regexp with `regexp-opt'.  This is what the `eval' part
of the configuration is for.

We could make `c-noise-macro-with-parens-names' (and
`c-noise-macro-names') safe local variables (after all, they do nothing
more than set regexps used for fontification).

The call (eval . (c-make-noise-macro-regexps)) is more problematic; the
eval "variable" is always going to be unsafe - it's got to be.  One
possible solution would be to enhance `define-derived-mode' with an
:after-hook argument (define-minor-mode already has one), a lisp form
which gets evaluated after the mode hooks have been run.
`c-make-noise-macro-regexps' could be put into this form.

I've reverted the change to .dir-locals.el which caused the problem.
This should take the pressure off, so that we can find a good solution.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Sat, 7 May 2016 20:40:22 +0000
> Cc: 23476@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > One way is to turn on by default the feature that fontifies these
> > macros correctly.  Why does it have to be off by default?
> 
> The feature is dependent on _configuration_: the '("IF_LINT") is that
> configuration.

But the IF_LINT part is AFAIU the _only_ part of the configuration
that the user needs to supply.  All the rest, including the forms to
evaluate, doesn't have to be in file-local variables.  Right?  And a
list of strings can easily be a safe local variable, so if you devise
a variable that will accept lists like '("IF_LINT"), it could easily
be specified without prompting those annoying questions.

Moreover, we could support these particular macros by default: I doubt
that Paul invented them for Emacs, and even if he did, they are by now
probably used elsewhere, so it should be good to have their support
built-in.

Am I missing something?

> I've reverted the change to .dir-locals.el which caused the problem.
> This should take the pressure off, so that we can find a good solution.

Thanks.  I hope the considerations above will allow to restore the
feature soon.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Sun, May 08, 2016 at 06:48:23PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2016 20:40:22 +0000
> > Cc: 23476@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > One way is to turn on by default the feature that fontifies these
> > > macros correctly.  Why does it have to be off by default?

> > The feature is dependent on _configuration_: the '("IF_LINT") is that
> > configuration.

> But the IF_LINT part is AFAIU the _only_ part of the configuration
> that the user needs to supply.  All the rest, including the forms to
> evaluate, doesn't have to be in file-local variables.  Right?

Right.  I've amended C(etc.) Mode to use the new :after-hook parameter
to define-derived-mode which I committed yesterday.  The eval form which
used to be in .dir-locals.el is now run by C Mode after the mode hooks
(and file/dir local variables stuff) have been done.

> And a list of strings can easily be a safe local variable, so if you
> devise a variable that will accept lists like '("IF_LINT"), it could
> easily be specified without prompting those annoying questions.

Done.  So now, Emacs master will now accept the "IF_LINT" value from
.dir-locals.el without asking the user any questions.  (I haven't
commited the change yet, though.)

However, visiting a master C source file using the emacs-25 branch would
still ask the question.  One way to get round this would be to add the
safe-local-variable stuff into emacs-25, but nobody wants to change
emacs-25 at this late stage.

> Moreover, we could support these particular macros by default: I doubt
> that Paul invented them for Emacs, and even if he did, they are by now
> probably used elsewhere, so it should be good to have their support
> built-in.

To me, this doesn't feel like the Right Thing to do.  A user might
easily define a macro (or even a variable) called IF_LINT and be puzzled
as to why it wasn't fontifying or indenting correctly.

> Am I missing something?

For the master branch, making IF_LINT a noise macro by default wouldn't
gain us anything.  For visiting a master branch C file from the emacs-25
branch, this wouldn't help.

> > I've reverted the change to .dir-locals.el which caused the problem.
> > This should take the pressure off, so that we can find a good solution.

> Thanks.  I hope the considerations above will allow to restore the
> feature soon.

Just how bad would it be to get the question about unsafe local
variables when visiting master C files from emacs-25 emacs -Q?  If the
answer is "not too bad", I can also commit the change to .dir-locals.el.
Otherwise, probably the best thing is just to commit the changes to CC
Mode for now, and amend .dir-locals.el after the Emacs 25 release, when
people will mostly be using the code in the master branch for
development.

What do you say?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Stefan Monnier]

> One possible solution would be to enhance `define-derived-mode' with
> an :after-hook argument (define-minor-mode already has one), a lisp
> form which gets evaluated after the mode hooks have been run.
> `c-make-noise-macro-regexps' could be put into this form.

No need for that.
E.g. you can use `hack-local-variables-hook' to get the
same result (especially with the new behavior of hack-local-variables).

Or you can make the construction of this regexp more lazy.


        Stefan

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Mon, 9 May 2016 11:07:13 +0000
> Cc: 23476@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > But the IF_LINT part is AFAIU the _only_ part of the configuration
> > that the user needs to supply.  All the rest, including the forms to
> > evaluate, doesn't have to be in file-local variables.  Right?
> 
> Right.  I've amended C(etc.) Mode to use the new :after-hook parameter
> to define-derived-mode which I committed yesterday.  The eval form which
> used to be in .dir-locals.el is now run by C Mode after the mode hooks
> (and file/dir local variables stuff) have been done.

Thanks.

> However, visiting a master C source file using the emacs-25 branch would
> still ask the question.

Why, because Emacs 25 doesn't know about the new variable and its safe
values?  Or for some other reason?

> One way to get round this would be to add the safe-local-variable
> stuff into emacs-25, but nobody wants to change emacs-25 at this
> late stage.

Adding a variable that is not used for anything but declaring its safe
values should be OK, I think.

> Just how bad would it be to get the question about unsafe local
> variables when visiting master C files from emacs-25 emacs -Q?

It's better, but still an annoyance.  And if the solution in non-Q
sessions is to accept the variable as safe anyway, then adding the
variable instead for the same purpose is not different, and should be
"safe" (pun intended ;-).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Hello, Eli.

On Mon, May 09, 2016 at 07:52:08PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 9 May 2016 11:07:13 +0000
> > Cc: 23476@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > Right.  I've amended C(etc.) Mode to use the new :after-hook parameter
> > to define-derived-mode which I committed yesterday.  The eval form which
> > used to be in .dir-locals.el is now run by C Mode after the mode hooks
> > (and file/dir local variables stuff) have been done.

> Thanks.

[ .... ]

> > One way to get round this would be to add the safe-local-variable
> > stuff into emacs-25, but nobody wants to change emacs-25 at this
> > late stage.

> Adding a variable that is not used for anything but declaring its safe
> values should be OK, I think.

> > Just how bad would it be to get the question about unsafe local
> > variables when visiting master C files from emacs-25 emacs -Q?

> It's better, but still an annoyance.  And if the solution in non-Q
> sessions is to accept the variable as safe anyway, then adding the
> variable instead for the same purpose is not different, and should be
> "safe" (pun intended ;-).

OK, Done.  (Full patch in master, minimal patch in emacs-25).

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Alan Mackenzie]

Bug fixed in master, and papered over (for compatibility) in emacs-25.

> Thanks.  This eliminates the error, but not the annoying question
> about unsafe variables.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> Date: Mon, 9 May 2016 18:22:06 +0000
> Cc: 23476@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > It's better, but still an annoyance.  And if the solution in non-Q
> > sessions is to accept the variable as safe anyway, then adding the
> > variable instead for the same purpose is not different, and should be
> > "safe" (pun intended ;-).
> 
> OK, Done.  (Full patch in master, minimal patch in emacs-25).

Thanks, the problem is gone on both branches.

Btw, I noticed that CC Mode is quite a bit slower on master than it is
on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
to these changes in any way?

bug#23476: 25.0.93; Visiting C files on master signals an error

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I noticed that CC Mode is quite a bit slower on master than it is
> on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> to these changes in any way?

FWIW, I'm using master version

GNU Emacs 25.0.92.4 (x86_64-pc-linux-gnu, X toolkit) of 2016-04-23

which includes the noise macros feature. Searching for IF_LINT in
xdisp.c is instantaneous. Also, on my work with large-ish C++ source
files I didn't observe any slow down.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 09 May 2016 22:46:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I noticed that CC Mode is quite a bit slower on master than it is
> > on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> > to these changes in any way?
> 
> FWIW, I'm using master version
> 
> GNU Emacs 25.0.92.4 (x86_64-pc-linux-gnu, X toolkit) of 2016-04-23
> 
> which includes the noise macros feature. Searching for IF_LINT in
> xdisp.c is instantaneous. Also, on my work with large-ish C++ source
> files I didn't observe any slow down.

How (with what configure-time options) was your binary built?  Is it
an optimized build?

And btw, 25.0.93 is not a master branch version, it's an emacs-25
branch version.  The slowdown I saw was in 25.1.50.106.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Glenn Morris]

Eli Zaretskii wrote:

> Btw, I noticed that CC Mode is quite a bit slower on master than it is
> on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> to these changes in any way?

Slower than the version that is slower than the previous version?

http://debbugs.gnu.org/20352

bug#23476: Slowdown in C Mode fontification [Was: bug#23476: 25.0.93; Visiting C files on master signals an error]

[Alan Mackenzie]

Hello, Eli.

On Mon, May 09, 2016 at 10:11:14PM +0300, Eli Zaretskii wrote:

[ .... ]

> Btw, I noticed that CC Mode is quite a bit slower on master than it is
> on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> to these changes in any way?

Whoops!  No, this slowdown is caused by commit
89d1776b81ab552192ee41f13ce84ff86bda4556 on 2016-04-25, a fix for bug
#7918.  The bug was the spurious fontification of something like "for (;
a * b;)".

I'll see if I can find a better fix; if not, it would probably be best to
remove the commit and leave the bug unfixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: Slowdown in C Mode fontification [Was: bug#23476: 25.0.93; Visiting C files on master signals an error]

[Alan Mackenzie]

Hello, Eli.

On Tue, May 10, 2016 at 07:51:32AM +0000, Alan Mackenzie wrote:
> On Mon, May 09, 2016 at 10:11:14PM +0300, Eli Zaretskii wrote:

> [ .... ]

> > Btw, I noticed that CC Mode is quite a bit slower on master than it is
> > on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> > to these changes in any way?

> Whoops!  No, this slowdown is caused by commit
> 89d1776b81ab552192ee41f13ce84ff86bda4556 on 2016-04-25, a fix for bug
> #7918.  The bug was the spurious fontification of something like "for (;
> a * b;)".

> I'll see if I can find a better fix; if not, it would probably be best to
> remove the commit and leave the bug unfixed.

I've reverted that commit, and reopened bug #7918.  It's going to be
difficult to fix in a manner which doesn't slow down CC Mode's
fontification.  :-(

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23476: Slowdown in C Mode fontification [Was: bug#23476: 25.0.93; Visiting C files on master signals an error]

[Eli Zaretskii]

> Date: Tue, 10 May 2016 07:51:32 +0000
> Cc: 23476@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> From: Alan Mackenzie <acm@muc.de>
> 
> > Btw, I noticed that CC Mode is quite a bit slower on master than it is
> > on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> > to these changes in any way?
> 
> Whoops!  No, this slowdown is caused by commit
> 89d1776b81ab552192ee41f13ce84ff86bda4556 on 2016-04-25, a fix for bug
> #7918.  The bug was the spurious fontification of something like "for (;
> a * b;)".
> 
> I'll see if I can find a better fix; if not, it would probably be best to
> remove the commit and leave the bug unfixed.

Since this is only on master (right?), there's no rush to revert the
commit, perhaps you or someone else will come up with a solution that
doesn't bring back bug #7918.

Thanks.

bug#23476: 25.0.93; Visiting C files on master signals an error

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Btw, I noticed that CC Mode is quite a bit slower on master than it is
>> > on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
>> > to these changes in any way?
>> 
>> FWIW, I'm using master version
>> 
>> GNU Emacs 25.0.92.4 (x86_64-pc-linux-gnu, X toolkit) of 2016-04-23
>> 
>> which includes the noise macros feature. Searching for IF_LINT in
>> xdisp.c is instantaneous. Also, on my work with large-ish C++ source
>> files I didn't observe any slow down.
>
> How (with what configure-time options) was your binary built?  Is it
> an optimized build?
>
> And btw, 25.0.93 is not a master branch version, it's an emacs-25
> branch version.  The slowdown I saw was in 25.1.50.106.

Ooops! It is emacs-25 indeed, but with the original noise-macros patch
that was later committed to master by Alan.

My config command is

../emacs/configure --without-toolkit-scroll-bars --with-x-toolkit=lucid

which is optimized, AFAIK.

I have GNU Emacs 25.1.50.1 (i686-w64-mingw32) of 2016-04-21 on a VM
machine and isearching for IF_LINT on xdisp.c on that build is also
instantaneous. Configured and built with no added options. The same
build on a 7 year old netbook also isearches IF_LINT with no perceptible
delay. Moreover, I have installed the `anzu' package, which shows on the
modeline a (M/N) count where N is the total of matches on the buffer and
M is the current match on the series. This possibly adds quite a bit of
work to the bare isearch.

There is no significant change on the time taken for displaying the
buffer when the file is visited too. Quickly pressing the Page/Down key
saturates the CPU on the netbook, but IIRC that also happened before the
noise-macros change.

bug#23476: Slowdown in C Mode fontification

[Alan Mackenzie]

Hello, Eli.

On Tue, May 10, 2016 at 07:04:28PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 10 May 2016 07:51:32 +0000
> > Cc: 23476@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> > From: Alan Mackenzie <acm@muc.de>

> > > Btw, I noticed that CC Mode is quite a bit slower on master than it is
> > > on emacs-25 (try searching for "IF_LINT" in xdisp.c), is that related
> > > to these changes in any way?

> > Whoops!  No, this slowdown is caused by commit
> > 89d1776b81ab552192ee41f13ce84ff86bda4556 on 2016-04-25, a fix for bug
> > #7918.  The bug was the spurious fontification of something like "for (;
> > a * b;)".

> > I'll see if I can find a better fix; if not, it would probably be best to
> > remove the commit and leave the bug unfixed.

> Since this is only on master (right?), there's no rush to revert the
> commit, perhaps you or someone else will come up with a solution that
> doesn't bring back bug #7918.

I've reverted it.  I'm thinking of Martin, who doesn't have a fast
machine, and it's annoyingly slow even for me on my machine.  In fact
the slowdown in fontification is approximately a factor of 3.

I've now got some idea how to fix this, and it will be radically
different from the reverted commit, not a variation on it.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).