emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs rendering comparisson between emacs23 and emacs26.3


From: martin rudalics
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 3 Apr 2020 08:59:54 +0200

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

Recent Emacsen either ignore that variable or silently reset it to nil
internally so it doesn't get into their way.  Their progmodes either
always scan an entire buffer from its beginning or use some elaborate,
fragile techniques to find such a top level position.  Moreover, our
underlying mechanism for syntax highlighting always marks the entire
rest of a buffer as dirty after every single editing change.  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.

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.

martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]