Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

On Fri, Apr 03, 2020 at 08:59:54 +0200, martin rudalics wrote:
>  > Can you pleese explain what you mean?

>  > What exactly was "removed"?  The variable
>  > 'open-paren-in-column-0-is-defun-start' seems to still exist, and
>  > its default value seems to be t (my .emacs does not set it and it
>  > is t).


>  >    > With the argument that people want to comment out larger
>  >    > regions of code by simply putting comment delimiters at the
>  >    > beginning and end of that code.

>  > You have not said concretely which practice this refers to, but the
>  > feature of special meaning for open-paren in column zero affects Emacs
>  > editing commands, not the meaning of the program when executed.

> 'open-paren-in-column-0-is-defun-start', if non-nil, conceptually allows
> progmodes to avoid scanning an entire buffer in order to get things like
> syntax highlighting and code indenting right.  Rather, progmodes are
> allowed to find the first or next paren in column zero wrt a given
> position and base further decisions on the assumption that such a paren
> is on the "top level" of its buffer.

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.

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

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

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

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.

> This has the consequence that that entire part has to be continuously
> rescanned when some of it is shown in another window.

> The basic slowness of Emacs over the past years is a direct consequence
> of that policy.  Most people don't care because they are using fast
> processors that easily compensate the resulting overhead.  People with
> old and slow hardware suffer from it.

How bad is this on your machine, really?

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

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).