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: Stefan Monnier
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 03 Apr 2020 12:56:01 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>> The basic slowness of Emacs over the past years is a direct consequence
>>> of that policy.
>> Do you have some kind of (concrete, statistical, circumstantial, ...)
>> evidence for that?
> I'd gladly provide such evidence to prove or disprove my claim.

I understand proving/disproving it is hard.

I'm really asking what are the signs that make you think it's
due to the lack of use of `open-paren-in-column-0-is-defun-start`.

> But customizing 'open-paren-in-column-0-is-defun-start' has no effect
> here any more and reconstructing its earlier semantics would consume
> more resources than I can afford.

Yes, I don't think there's much interested in going back to that.
OTOH if we could find specific cases where the old code was faster
(supposedly due to its use of `open-paren-in-column-0-is-defun-start`),
we could think about how to recover that performance.

E.g. `open-paren-in-column-0-is-defun-start` was used in
`forward-comment` was scanning comments backward to avoid having to use
`parse-partial-sexp` all the way from `point-min` in the worst case.
We replaced that with a parse cache (`syntax-ppss`) which seems to be
just as good in my experience (and significantly better in those
languages where open parens in column 0 are virtually non-existent).
If we can show that this replacement is not "just as good", there are
various options to improve it or replace it, but we'd need to know which
case(s) matter in order to design it.


        Stefan





reply via email to

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