[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about display engine

From: Ergus
Subject: Re: Question about display engine
Date: Thu, 8 Aug 2019 10:15:53 +0200
User-agent: NeoMutt/20180716

On Wed, Aug 07, 2019 at 07:41:25PM +0300, Eli Zaretskii wrote:
Cc: address@hidden
From: martin rudalics <address@hidden>
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.

reply via email to

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