[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs rendering comparisson between emacs23 and emacs26.3
From: |
Richard Stallman |
Subject: |
Re: emacs rendering comparisson between emacs23 and emacs26.3 |
Date: |
Tue, 07 Apr 2020 22:29:21 -0400 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> > > 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.
> >
> > Does anyone disagree with this specific factual claim?
> I'm not sure what is "the claim" here,
The factual statements in the paragraph I quoted, above.
but I want to point out a small
> inaccuracy: redisplay doesn't "continuously rescan the entire rest of
> the buffer", it only rescans the part(s) shown in windows. (It might
> happen that some major mode's font-lock definitions end up rescanning
> much more, but that's a separate issue.)
Isn't that separate issue the issue we are talking about.
And frankly, what would we
> like Emacs to do instead?
It would scan only from the last open-paren-in-column-zero, as it did
in the past.
A change in a buffer can potentially affect
> the fontification of the rest of the buffer, and I don't think we
> would like Emacs to fail to update other windows showing the same
> buffer
I have a feeling there has been a change of topic here, but I can't be
sure.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
- Re: emacs rendering comparisson between emacs23 and emacs26.3, (continued)
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Richard Stallman, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/08
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/08
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Noam Postavsky, 2020/04/11
- Re: emacs rendering comparisson between emacs23 and emacs26.3,
Richard Stallman <=
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/08
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Richard Stallman, 2020/04/08
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/02