GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16526-done <at> debbugs.gnu.org
Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sat, 28 Jun 2014 14:55:09 +0000

Hi, Martin.

On Sat, Jun 28, 2014 at 04:00:40PM +0200, martin rudalics wrote:
>  > AH!!!!!  GOT IT!!!!  What causes the slowdown is binding
>  > open-paren-in-column-0-is-defun-start to nil around the scan-lists.  In
>  > CC Mode's "engine" parts, that variable is bound to nil.  There are good
>  > reasons for this (which I can't precisely recall just at the moment).

>  > In CC Mode, "'" has string syntax.  So any C comment with an odd number
>  > of apostrophes looks, to back_comment, like it has an "unbalanced string",
>  > and the code ends up at label lossage: in back_comment.  Here
>  > find_defun_start is called, and this returns BOB when open-paren-..-0 is
>  > nil.  From here (BOB) the code scans forward to check this putative
>  > "unbalanced string".  It's a long way from BOB to ~900k, hence the
>  > sluggishness.

>  > Where do we go from here?

> In every version of Emacs I'm actually doing some work I have disabled
> CC mode's `open-paren-in-column-0-is-defun-start' bindings.

This is harmless (and thus helpful) in code conforming to GNU standards.
As you note below, it causes confusion and heartache in other
circumstances.

> Otherwise, working on a file like xdisp.c would be virtually impossible
> for me.  As for the release I would simply do what I proposed earlier -
> make these overriding bindings customizable.

I'd far rather the code worked properly (including fast enough).  Making
a choice between two ugly workarounds customisable would be
short-changing users.

> So someone who wants to comment out code with a paren in the first
> column can have the "correct" behavior while people like me can
> continue work with "incorrect" but yet tame behavior.  And obviously I
> could continue to work without having bzr status tell me that I've
> changed CC mode files ;-)

This particular scan-lists which took 0.7s had to traverse 65 comments,
of which 29 had an odd number of apostrophes.  Scanning xdisp.c from BOB
to syms_of_xdisp on my machine takes 0.024s.  28 * 0.024s = 0.67s.  So if
there were simple cacheing in syntax.c, such that the scan from BOB was
done at most once for each scan-lists, the sluggishness would largely
vanish in this case.

If you look at find_defun_start in syntax.c, you'll be struck by just
what an ugly kludge the code for null open_paren_.._start is.
Substantial improvement must surely be possible.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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