Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics]

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

Turning the tables, I don't consider inaccurate editing (like inserting
an unbalanced paren or delimiter) one of the worst things a user can do
to its editor.  For me, an open paren in column zero is some sort of an
agreement between me and the editor we both would heed as accurately as
we can.  People like you who don't care would not even pay attention to
it.  People like me who do care might profit from it.  It certainly
isn't a cure of all problems and might not even help with scrolling
buffers.  But it would provide one knob a user could press to find out.

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

Why bother?  The comment would appear highlighted as comment down to
that parenthesis or to the end of the window, whatever comes first.

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

I certainly would.  In my last commit I did insert such a paren on line
8022 of xfns.c and didn't notice it.  OTOH, the average user who never
customized 'open-paren-in-column-0-is-defun-start' would not be aware of
it.

martin