GNU bug report logs -
#26
Consistent underline face end of line to edge extension on X
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26 in the body.
You can then email your comments to 26 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#26
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
David De La Harpe Golden <david <at> harpegolden.net>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Your message specified a Severity: in the pseudo-header, but
the severity value minor was not recognised.
The default severity normal is being used instead.
The recognised values are: critical, grave, normal, minor, wishlist.
Full text and rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Package: emacs
Version: 23.0.60
Severity: minor
Tags: patch
As per emacs-devel post [1]
On X displays, when an overlay's face has underline (or overstrike
or strikethrough) set, when it crosses line end, it is only extended
to window edge when a background different to the frame background is
also set in the face. This is different behaviour to terminal displays.
It really only matters for "unconventional" uses of
underline/overline/strikethrough through, such as use in a "show old
window position" hack [2][3]
Easily "fixed", patch attached.
[1] http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00071.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg03044.html
[3] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg03045.html
[xdisp_extend_underline_to_edge.diff (text/x-patch, inline)]
Index: src/xdisp.c
===================================================================
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1198
diff -u -r1.1198 xdisp.c
--- src/xdisp.c 29 Feb 2008 03:12:27 -0000 1.1198
+++ src/xdisp.c 2 Mar 2008 04:42:46 -0000
@@ -15968,6 +15968,9 @@
if (FRAME_WINDOW_P (f)
&& it->glyph_row->displays_text_p
&& face->box == FACE_NO_BOX
+ && !face->underline_p
+ && !face->overline_p
+ && !face->strike_through_p
&& face->background == FRAME_BACKGROUND_PIXEL (f)
&& !face->stipple)
return;
Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.980
diff -u -r1.980 xterm.c
--- src/xterm.c 1 Mar 2008 14:59:06 -0000 1.980
+++ src/xterm.c 2 Mar 2008 04:42:56 -0000
@@ -3024,7 +3024,7 @@
XGetGCValues (s->display, s->gc, GCForeground, &xgcv);
XSetForeground (s->display, s->gc, s->face->strike_through_color);
XFillRectangle (s->display, s->window, s->gc, s->x, s->y + dy,
- s->width, h);
+ s->background_width, h);
XSetForeground (s->display, s->gc, xgcv.foreground);
}
}
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#26
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
> On X displays, when an overlay's face has underline (or overstrike
> or strikethrough) set, when it crosses line end, it is only extended
> to window edge when a background different to the frame background is
> also set in the face. This is different behaviour to terminal displays.
I understand that in your case you use underline as a way to "draw
a line" so you want the line to extend to the window-edge, but when the
underline is really meant as "this text should be underlined", extending
the underline to the window-edge is truly ugly.
Stefan
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#26
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#26
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
David De La Harpe Golden <david <at> harpegolden.net>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #20 received at 26 <at> emacsbugs.donarmstrong.com (full text, mbox):
Stefan Monnier wrote:
> I understand that in your case you use underline as a way to "draw
> a line" so you want the line to extend to the window-edge, but when the
> underline is really meant as "this text should be underlined", extending
> the underline to the window-edge is truly ugly.
>
Well, as I can certainly see that side too. However, still a few things:
(i) N.B. Extension happens anyway, if the background happens to be
different to the frame background (and it always happens on terminals).
I suppose you could flip the issue and consider it a bug that that
extension happens, but:
(ii) In my typical uses of underline face it doesn't arise much, since
the newline itself has to be in underline face for the extension to
happen, whereas underlining tends to be word-by-word, and if it's not
word-by-word, it tends to be across word-space-word not across
word-newline-word. (even for M-o u underlining whole paragraphs, but
that depends on whether you're doing text+longlines (newline ending
paragraph like a wordprocessor) or text+auto-fill (newline ending line),
the former will be okay but the latter ugly).
i.e. in
hello
goodbye
hello\n would have to be underlined for extension to happen, not just
the hello and goodbye being underlined separately.
(iii) Perhaps what is really needed is an face attribute to say whether
extension should take place - similar could be useful for
region-highlighting too - that currently extends too, which some people
might also find ugly (I know it conveys useful information as to whether
the newline is included or not, but still, a kind of "truncated
extension" would also be possible, where a vertical bar in a different
color is drawn).
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#26
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
David De La Harpe Golden <david <at> harpegolden.net>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #25 received at 26 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
David De La Harpe Golden wrote:
> (i) N.B. Extension happens anyway, if the background happens to be
> different to the frame background
Anyway, if you do consider it a bug that that extension happens, then
just making underline and overline drawing use width rather than
background_width (like overstrike) in src/xterm.c probably resolves
that? (at least on bitmapped displays)
Illustrative screenshots included - note how a nonmatching background
causes the ugly (in this context) extension.
[xdisp_no_underline_extension.diff (text/x-patch, inline)]
Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.981
diff -u -r1.981 xterm.c
--- src/xterm.c 3 Mar 2008 06:32:12 -0000 1.981
+++ src/xterm.c 4 Mar 2008 02:12:58 -0000
@@ -2978,14 +2978,14 @@
if (s->face->underline_defaulted_p)
XFillRectangle (s->display, s->window, s->gc,
- s->x, y, s->background_width, h);
+ s->x, y, s->width, h);
else
{
XGCValues xgcv;
XGetGCValues (s->display, s->gc, GCForeground, &xgcv);
XSetForeground (s->display, s->gc, s->face->underline_color);
XFillRectangle (s->display, s->window, s->gc,
- s->x, y, s->background_width, h);
+ s->x, y, s->width, h);
XSetForeground (s->display, s->gc, xgcv.foreground);
}
}
@@ -2997,14 +2997,14 @@
if (s->face->overline_color_defaulted_p)
XFillRectangle (s->display, s->window, s->gc, s->x, s->y + dy,
- s->background_width, h);
+ s->width, h);
else
{
XGCValues xgcv;
XGetGCValues (s->display, s->gc, GCForeground, &xgcv);
XSetForeground (s->display, s->gc, s->face->overline_color);
XFillRectangle (s->display, s->window, s->gc, s->x, s->y + dy,
- s->background_width, h);
+ s->width, h);
XSetForeground (s->display, s->gc, xgcv.foreground);
}
}
[emacs_xdisp_no_underline_extension.png (image/png, inline)]
[emacs_xdisp_underline_extension_with_bg.png (image/png, inline)]
Reply sent
to
Chong Yidong <cyd <at> stupidchicken.com>
:
You have taken responsibility.
(Sat, 27 Jun 2009 23:10:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
David De La Harpe Golden <david <at> harpegolden.net>
:
bug acknowledged by developer.
(Sat, 27 Jun 2009 23:10:05 GMT)
Full text and
rfc822 format available.
Message #30 received at 26-done <at> emacsbugs.donarmstrong.com (full text, mbox):
> Anyway, if you do consider it a bug that that extension happens, then
> just making underline and overline drawing use width rather than
> background_width (like overstrike) in src/xterm.c probably resolves
> that? (at least on bitmapped displays)
I've checked in this fix into the CVS trunk (independently arrived at
for Bug#489).
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Sun, 30 Aug 2009 14:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 15 years and 185 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.