Re: Question about display engine

[Ergus <spacibba@aol.com>]

On Wed, Aug 07, 2019 at 07:41:25PM +0300, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>> Date: Wed, 7 Aug 2019 18:25:37 +0200
>>
>>  > And, of course, this leaves the more general problem I described in my
>>  > message: what is the right behavior for extending the face that
>>  > crosses a newline.  (Note that the display engine in general doesn't
>>  > know whether a face that doesn't end before a newline will or won't
>>  > continue on the next screen line.)
>>
>> Recalling your proposal
>>
>> (defcustom face-extend-to-window-edge t
>>     "Non-nil means extend face of last character on line to window edge.
>
>Thanks for the reminder.
>
>> Certain face attributes, if present in the face of the last character
>> of a line and different from those of the default face, cause the
>> empty space following the end of text on the line to be drawn with
>> those attributes, to give the empty space appearance similar to that
>> of the preceding text.  These attributes are those which affect the
>> background of a face: `:background', `:stipple', `:box', `:underline',
>> `:overline', and `:strike-through'.  By default, if the face of a
>> line's last character has any of these attributes, and the value is
>> different from that of the default face, the empty space following the
>> line's text will be drawn in the face of the last character.
>
>This is inaccurate, I think: on GUI frames only :background and :box
>are extended all the way, the rest only "infect" the glyph we add for
>displaying the newline.
>
>> This variable allows fine-tuning which attributes trigger the face
>> extension.  The default value of t means any of the mentioned
>> attributes will cause face extension.  The value of nil means face
>> extension is turned off.  A value that is a list of attributes will
>> extend the face only if any of the attributes from the list are
>> present in the last character's face.  Note that only attributes from
>> the above list are meaningful in list values of this variable.")
>>
>> in the discussion of Bug#23574.
>
>And I think we need to consider the case of the region using one of
>the attributes that are not in the list.
>
In gui our actual behavior seems to be very reasonable and simple (And
we haven't too many complains about this.). It extends the region
colors, but not the underline (and similes). For me this makes sense
because underline empty spaces after \n, until the page border, does not
really means anything as conceptually there is nothing that should be
underlined there.

The "surprise" is that there is no code for this effect in the display
engine and it has to do with some X||gtk feature in use. (That's why I
needed to ad an extra glyph after the indicator.)

Comparing around:

VIM, when toggle to visual mode it only highlights the real
text. The rest of the line stays unchanged. This is useful to detect
trailing whitespaces when no set by default (I am not telling that we
should adopt that approach, but it looks very reasonable and simple and
it is the default in most gui libraries; so also for the users)

Geany, QtCreator, Sublime, Web Browsers (Firefox, chromium), MS Word, all of
them do the same.

Eclipse, on the other hand, extends the color to the end of the line as
we do, but it only allows to set background and foreground to what we
call region. So no underlined region to worry about.

I think that these are the most extended approaches around (so we don't
need to reinvent the wheel) and Eli should make the design choice so
we/he can start implementing that; otherwise it will be forgotten after
hours and hours of arguments and at the end there will be always
somebody unhappy.