unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23574@debbugs.gnu.org, john.b.mastro@gmail.com,
	cwoodbury@azavea.com, npostavs@users.sourceforge.net
Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox
Date: Wed, 08 Jun 2016 08:33:30 +0200	[thread overview]
Message-ID: <5757BC3A.5070402@gmx.at> (raw)
In-Reply-To: <83eg89roam.fsf@gnu.org>

 > Talk about over-specification ;-)
 >
 > I hope you realize how some of that will make redisplay much more
 > expensive?

Yes.  But the only value I really care about is nil ;-)

 > How about the following more modest alternative?
 >
 > (defcustom face-extend-to-window-edge t
 >     "Non-nil means extend face of last character on line to window edge.
 >
 > 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 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.")

This has the advantage of a much better doc-string.  The only details
missing are whether the last character of a line is the newline
character, whether a non-printable character's attributes count, how
invisible characters are treated and whether the :display attribute has
any impact.  Since I have no good idea about all of these I deliberately
did not try to cover them.

I'm not sure whether your proposal (it obviously was my first idea as
well) is less expensive, though.  If the value of our variable is a
list, the display engine has to go through the properties of the last
character and compare them against the members of this list.  Or go
through all members of the list and compare them against the character's
properties - neither of these approaches is cheap even if optimizations
are applied.

And then I thought about the - possibly silly idea - that a user might
want to put a property like :background on all lines displayed,
regardless of the last character's attributes.  Such a user would have
to, before displaying the relevant buffer parts, go through all these
lines and add that property to the newline (?) character of each line.
Now I bet that the greater part of such users would put the property on
all newline characters of the buffer instead of using something like
‘pre-redisplay-functions’ where even I couldn't tell whether it gets the
window's start and end positions always right.

martin






  reply	other threads:[~2016-06-08  6:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18 17:03 bug#23574: 24.5; Overzealous underlining in emacs-nox Colin Woodbury
2016-05-30 15:04 ` Colin Woodbury
2016-06-04  7:48   ` Eli Zaretskii
     [not found]     ` <CAHuwsfihHJ8WHwmHvMDF7Ynns4YOJSKEEbjhpbYrw0V=5aYXEQ@mail.gmail.com>
2016-06-04 16:20       ` Eli Zaretskii
2016-06-04 21:37         ` John Mastro
2016-06-05 15:54           ` Eli Zaretskii
2016-06-05 17:05             ` Noam Postavsky
2016-06-05 17:56               ` Eli Zaretskii
2016-06-05 18:20                 ` Colin Woodbury
2016-06-05 18:36                   ` Eli Zaretskii
2016-06-05 19:13                 ` Noam Postavsky
2016-06-06  2:27                   ` Eli Zaretskii
2016-06-06 11:42                     ` Noam Postavsky
2016-06-06 15:04                       ` Eli Zaretskii
2016-06-06 16:54                         ` martin rudalics
2016-06-06 18:25                           ` Colin Woodbury
2016-06-06 19:18                             ` Eli Zaretskii
2016-06-07  0:18                               ` Noam Postavsky
2016-06-07 15:55                                 ` Eli Zaretskii
2016-06-08  2:52                                   ` Noam Postavsky
2016-06-06 18:55                           ` Eli Zaretskii
2016-06-07  9:10                             ` martin rudalics
2016-06-07 15:50                               ` Eli Zaretskii
2016-06-08  6:33                                 ` martin rudalics [this message]
2016-06-08 17:05                                   ` Eli Zaretskii
2016-06-09  8:38                                     ` martin rudalics
2016-06-09 12:26                                       ` Eli Zaretskii
2016-06-10  7:16                                         ` martin rudalics
2016-06-10  8:10                                           ` Eli Zaretskii
2016-06-10  8:24                                             ` martin rudalics
2016-06-10  9:50                                               ` Eli Zaretskii
2016-06-10 13:59                                                 ` martin rudalics
2016-06-10 14:24                                                   ` Eli Zaretskii
2019-10-21 11:49 ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-08  5:32   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5757BC3A.5070402@gmx.at \
    --to=rudalics@gmx.at \
    --cc=23574@debbugs.gnu.org \
    --cc=cwoodbury@azavea.com \
    --cc=eliz@gnu.org \
    --cc=john.b.mastro@gmail.com \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).