Re: The current state of the comment-cache branch

[Alan Mackenzie <acm@muc.de>]

Hello, Elias.

On Sat, Dec 24, 2016 at 08:21:32PM +0800, Elias Mårtenson wrote:
> On 24 Dec 2016 7:36 pm, "Alan Mackenzie" <acm@muc.de> wrote:


>> > Could you or someone else explain why an open paren in column 0 can affect
>> > the parsing of syntax in cc-mode at all? After all, such parens have no
>> > special syntactic nor semantic meaning in C nor C++.

>> It is a convention established in Emacs around ?40 years ago, that such
>> an open paren signalled the start of a defun.  This sped Emacs up
>> enormously, since the alternative was searching back to the beginning of
>> the buffer to check whether the paren was at the top level.


> Thank you and Eli for clarifying this. It makes much more sense to me now.

> I'm still wondering how useful this could be for C code though. There are
> many coding conventions where the opening { of a function does not go in
> the left-most column. As far as I understand, such coding conventions would
> lead to slower parsing?

This convention is not useful for C.  It is purely an artifice to speed
up the analysis of comment boundaries when scanning backwards.  It is
actually a hindrance to CC Mode.

> I'm specifically asking this since I have sometimes used such style and at
> least I don't think I've felt any slowness.

For small and smallish buffers, you're not going to notice.  For larger
buffers, compare performance with the convention enabled (i.e. the
variable open-paren-in-column-0-is-defun-start set to t) and disabled
(that variable set to nil).  There is a noticeable difference in
performance towards the end of large buffers.

The idea of the comment-cache branch is to get rigorous analysis of
comments (like having o-p-i-c-0-i-d-s nil) together with the speed which
is currently provided by the convention (with o-p-i-c-0-i-d-s t).

-- 
Alan Mackenzie (Nuremberg, Germany).