bug#22884: 25.0.92; C/l mode editing takes waaaayy too long

[Alan Mackenzie]

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