[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs rendering comparisson between emacs23 and emacs26.3
From: |
Alan Mackenzie |
Subject: |
Re: emacs rendering comparisson between emacs23 and emacs26.3 |
Date: |
Sat, 4 Apr 2020 19:20:27 +0000 |
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).
- Re: emacs rendering comparisson between emacs23 and emacs26.3, (continued)
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/06
- 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/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/04
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Ravine Var, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3,
Alan Mackenzie <=
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/04
- Re: emacs rendering comparisson between emacs23 and emacs26.3, martin rudalics, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Richard Stallman, 2020/04/04
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 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, Stefan Monnier, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Richard Stallman, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/06