Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

Hello again, Martin.

On Sat, Apr 04, 2020 at 10:56:27 +0200, martin rudalics wrote:
>  > 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.

My impression was that this was the single place in the syntax routines
it was ever used, though back_comment is called from several places in
syntax.c.

[ .... ]

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

That sounds like a shame.

>  > 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?

Because we'd need somehow to detect when the cell boundaries change,
possibly coalescing two cells, possibly creating a new one.  This would
involve delicate coding in an after-change-function, possibly in a
before-c-f too.

We'd need to avoid prematurely coalescing two functions (for example,
when typing in an open paren in emacs-lisp-mode).

Also, new data structures would be needed in font-lock.

I'm not saying it couldn't be done, but it would take some effort, and
might be politically difficult, too.

[ .... ]

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

Maybe the following would do it: on every open paren at column 0 within a
string or comment, apply a text property called `syntax-not-defun-start'.
back_comment would skip past any such paren with that property.  It would
be the responsibility of the major mode code to add and remove the
property.  Again, this would mean a moderately intricate
after-change-function, possibly paired with a before-change-function.

This would perhaps remove the trouble from o-p-i-c-0-i-d-s and allow us
to put it back, but I'm not sure Stefan M. would like it.

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

I think you might well be right, there.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).