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

[Alan Mackenzie]

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