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: Eli Zaretskii
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Tue, 07 Apr 2020 17:03:54 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Tue, 7 Apr 2020 10:32:07 +0200
> 
>  > (It might
>  > happen that some major mode's font-lock definitions end up rescanning
>  > much more, but that's a separate issue.)  And frankly, what would we
>  > like Emacs to do instead?  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 -- that would be against Emacs's description as "real-time"
>  > editor.
> 
> It depends on what we consider a failure: I do not think that inserting
> a "/*" in my window showing the top of my C buffer should cause the
> window showing the bottom of my buffer consider everything part of a
> comment starting at that "/*".

If that is what the language syntax rules say, then yes, we should
paint everything in comment face.  If you disagree, then let's agree
to disagree: I consider "inaccurate" display one of the worst things
an editor can do to its users.

> So what I would vote for in this case is that font-lock would specially
> highlight the open paren that "stops seeing the comment as comment" so
> the user is aware of the fact.

How would that help if that parentheses is not shown in any window?
And even if it is shown, do we really expect users to pay attention to
that, and immediately understand that this parentheses with an unusual
face explains the wrong display?



reply via email to

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