CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[Alan Mackenzie]

Hello, Martin, hello, Emacs.

By popular request, CC Mode no longer binds
open-paren-in-column-0-is-defun-start to nil internally.

As a consequence, CC Mode should run slightly faster, but at a slightly
higher risk of mis-indenting and mis-fontifying.  Those bug bears, open
parens in column 0 in strings and comments, will again cause things which
look like errors.

Let the user beware!

If anybody notices anything untoward that this causes, please let me
know.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[martin rudalics]

 > By popular request, CC Mode no longer binds
 > open-paren-in-column-0-is-defun-start to nil internally.

Thanks.

 > As a consequence, CC Mode should run slightly faster,

So far, the performance didn't improve significantly.  Either there are
other changes that did make editing C deteriorate considerably over the
past two years or I still have to tweak some internal settings.  I'll
get back to you as soon as I know more.

 > but at a slightly
 > higher risk of mis-indenting and mis-fontifying.  Those bug bears, open
 > parens in column 0 in strings and comments, will again cause things which
 > look like errors.

Funnily, a few minutes ago I read that for performance reasons an
implementation of "parinfer-mode"
(https://github.com/oakmac/atom-parinfer) relies on a similar feature.

We still also should fix the font-lock issue you reported elsewhere.  I
have no idea yet why it doesn't work any more.

martin

Re: CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[Alan Mackenzie]

Hello, Martin.

On Thu, Nov 12, 2015 at 09:22:19AM +0100, martin rudalics wrote:
>  > By popular request, CC Mode no longer binds
>  > open-paren-in-column-0-is-defun-start to nil internally.

> Thanks.

>  > As a consequence, CC Mode should run slightly faster,

> So far, the performance didn't improve significantly.  Either there are
> other changes that did make editing C deteriorate considerably over the
> past two years or I still have to tweak some internal settings.  I'll
> get back to you as soon as I know more.

I noticed a large degradation in speed, too.  I timed the complete
fontification of xdisp.c, and Emacs 24.5 was taking ~40s (with
o-p-i-c-0-i-defun-start t).  The same on Emacs 25.1 is taking ~77s.  The
difference seems to be between standalone CC Mode and the version
included with Emacs 25.1.  There's some bug on savannah CC Mode which
hasn't been fixed, or some optimisation which hasn't been made.

(Somewhat later).  The standalone CC Mode doesn't (in the default
branch) contain certain C++11 enhancements.  These seem to be what is
slowing things down.  This should be easily fixable for C Mode, but it
would be nice to fix it for C++ Mode, too.

>  > but at a slightly
>  > higher risk of mis-indenting and mis-fontifying.  Those bug bears, open
>  > parens in column 0 in strings and comments, will again cause things which
>  > look like errors.

> Funnily, a few minutes ago I read that for performance reasons an
> implementation of "parinfer-mode"
> (https://github.com/oakmac/atom-parinfer) relies on a similar feature.

> We still also should fix the font-lock issue you reported elsewhere.  I
> have no idea yet why it doesn't work any more.

You mean the open paren in column 0 not getting bold red?  I'm looking
at that at the moment, with thanks to Glenn for pointing out it used to
work very recently.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[Alan Mackenzie]

Hello, Martin.

On Thu, Nov 12, 2015 at 06:09:39PM +0000, Alan Mackenzie wrote:

> > So far, the performance didn't improve significantly.  Either there are
> > other changes that did make editing C deteriorate considerably over the
> > past two years or I still have to tweak some internal settings.  I'll
> > get back to you as soon as I know more.

> I noticed a large degradation in speed, too.  I timed the complete
> fontification of xdisp.c, and Emacs 24.5 was taking ~40s (with
> o-p-i-c-0-i-defun-start t).  The same on Emacs 25.1 is taking ~77s.  The
> difference seems to be between standalone CC Mode and the version
> included with Emacs 25.1.  There's some bug on savannah CC Mode which
> hasn't been fixed, or some optimisation which hasn't been made.

> (Somewhat later).  The standalone CC Mode doesn't (in the default
> branch) contain certain C++11 enhancements.  These seem to be what is
> slowing things down.  This should be easily fixable for C Mode, but it
> would be nice to fix it for C++ Mode, too.

I've just committed a fix (to the emacs-25 branch), mainly for C++ Mode,
but also for C Mode, too.

When I time the scrolling through xdisp.c, with the fix it now takes
~42s.  Without the fix, it's around 77s.  Here's the program I used to
time with (you need to initialise C Mode each time you rerun the test,
of course, to reinitialise Font Lock Mode):

  (defmacro time-it (&rest forms)
    "Time the running of a sequence of forms using `float-time'.
  Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
    `(let ((start (float-time)))
      ,@forms
      (- (float-time) start)))

  (defun time-scroll ()
    (interactive)
    (message "%s"
             (time-it
              (condition-case nil
                  (while t
                    (scroll-up)
                    (sit-for 0))
                (error nil)))))

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[martin rudalics]

 > I've just committed a fix (to the emacs-25 branch), mainly for C++ Mode,
 > but also for C Mode, too.

Looks good, almost back to normal.  What was the idea of the change?  I
don't understand from looking at the diffs (or reading the ChangeLog).

Thanks a lot, martin

Re: CC Mode now respects users' settings of open-paren-in-column-0-is-defun-start.

[Alan Mackenzie]

Hello, Martin.

On Mon, Nov 16, 2015 at 07:55:13PM +0100, martin rudalics wrote:
>  > I've just committed a fix (to the emacs-25 branch), mainly for C++ Mode,
>  > but also for C Mode, too.

> Looks good, almost back to normal.  What was the idea of the change?  I
> don't understand from looking at the diffs (or reading the ChangeLog).

There were two elements to the change.  One was preventing the slow
function (c-back-over-member-initializers) from being called from
anything but C++ Mode, since it is relevant only to C++.

But before that, I fixed that actual function.  It's problem was that it
was doing a lot of, in effect:

    (and (c-at-toplevel-p)
         (stuff-appears-to-be-a-member-initializer-list))

.  c-at-toplevel-p is a ruinously expensive function, and it was being
called continually.  So, in effect, I reversed the order of these two
things, so that only in the rare case where we have a member initializer
list, do we then check for being at the top level.

I think I was having a bad coding day when I originally wrote that
function.

> Thanks a lot, martin

-- 
Alan Mackenzie (Nuremberg, Germany).