Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics]

> This assumption proved to be very problematic.  The fact is, people put
> parentheses in column zero inside comments, and nothing we can say or do
> will stop them.  Why should it?  these parentheses are perfectly valid
> in so many languages.  Most notoriously was bug #22884, where there were
> such parentheses in Emacs's own C sources.  And there were quite a lot
> of ostensible bugs in CC Mode caused by these parentheses.

All these problems could have been cured easily: People who want such
parentheses would have set 'open-paren-in-column-0-is-defun-start' to
nil (or used a default value of nil) and everybody would have been
happy.  But throwing out the child with the bathwater by eliminating the
effect of that variable completely has left us no clue as to what makes
scrolling so slow in the present situation.

>> Recent Emacsen either ignore that variable or silently reset it to nil
>> internally so it doesn't get into their way.
>
> The one place which matters where o-p-i-c-0-i-d-s used to be used was in
> back_comment() in syntax.c.  This was removed for the above reasons.

IIRC that was just the last nail in the variable's coffin.

>> Their progmodes either always scan an entire buffer from its beginning
>> or use some elaborate, fragile techniques to find such a top level
>> position.
>
> Why do you use the word "fragile" here?  Do you have examples of this
> code failing?  It seems to me the current way is somewhat less fragile
> that the o-p-i-c-0-i-d-s way.

For me it's fragile because it does not allow me to easily hack it.  I
once gave up after trying in vain to implement a very elementary thing:
Make adjusting the first paragraph of the doc-string of an Elisp routine
not add anything to the first line of that doc-string and thus
invalidate our rules for writing doc-strings.  As things stand, I still
manually insert an empty line after the first one, adjust my paragraph,
and remove that empty line afterwards.

>> Moreover, our underlying mechanism for syntax highlighting always
>> marks the entire rest of a buffer as dirty after every single editing
>> change.
>
> I have always been sceptical of the wisdom of this.  Why invalidate the
> entire rest of the buffer, when a typical buffer change will cause at
> most local changes to the fontification?  I think this can only be for
> ease of coding in the font-lock functions.

I recall that more than a decade ago I tried to convince Stefan that a
buffer change that leaves the ppss unchanged should not invalidate the
rest of the buffer.  He initially liked the idea but didn't want to
implement it.

> Another approach would be somehow to divide a buffer into cells,
> something like one cell per function.  A buffer change would then
> invalidate the fontification only to the end of the current cell, not
> EOB.  This would be faster, but somewhat complicated to implement.

Why?

> How bad is this on your machine, really?

I already cited the scrolling example in my other posts.  Scrolling
dispextern.h and xdisp.c each take 10 seconds for one turn of the wheel
and consume 100% of the allotted CPU here.

>> So since you earlier asked for "a switch to turn off the changes" then
>> my answer is that such a switch already exists but has been deactivated.
>
> As already stated, it was deactivated for good reasons.  If we were to
> bring it back, I think we would need to add heuristics around
> paren-in-column-0 detection to the former rather crass 100% quitting of
> back_comment when one is encountered.  I've considered this quite a bit
> in the past, and can't conceive of anything both helpful and fast.

I still don't understand why it had to be eliminated.  Defaulting it to
nil but respecting a non-nil value would have been completely sufficient
IMHO.

martin