GNU bug report logs -
#21500
24.5; Graphical glitch with display property lines in GUI Emacs
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 21500 in the body.
You can then email your comments to 21500 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Wed, 16 Sep 2015 19:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vasilij Schneidermann <v.schneidermann <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 16 Sep 2015 19:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
(defface my-line
'((((type graphic)) :inherit font-lock-comment-face :strike-through t)
(((type tty)) :inherit font-lock-comment-face :underline t))
"Line face")
(defun my-line-glitch-repro ()
(interactive)
(with-current-buffer (get-buffer-create "*foobar*")
(insert "\n"
(propertize " "
'face 'my-line
'display '(space :width 80))
"\n")
(goto-char (point-min)))
(pop-to-buffer-same-window "*foobar*"))
Try M-x my-line-glitch-repro in both a textual and graphical session,
then put point on the space displayed as a 80 characters wide line. In
the graphical instance the line will be hidden (with the beginning being
displayed *in* the cursor's rectangle in reverse video), in textual
instances it's still visible (assuming your terminal supports
underlining).
In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2)
of 2015-04-20 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description: Arch Linux
Configured using:
`configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=gtk3 --with-xft
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
--param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 70992 6921)
(symbols 48 17559 0)
(miscs 40 35 138)
(strings 32 9053 4649)
(string-bytes 1 248607)
(vectors 16 8908)
(vector-slots 8 383094 18351)
(floats 8 63 260)
(intervals 56 177 6)
(buffers 960 11)
(heap 1024 32037 932))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Wed, 16 Sep 2015 20:14:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Sep 2015 21:37:06 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
>
> (defface my-line
> '((((type graphic)) :inherit font-lock-comment-face :strike-through t)
> (((type tty)) :inherit font-lock-comment-face :underline t))
> "Line face")
>
> (defun my-line-glitch-repro ()
> (interactive)
> (with-current-buffer (get-buffer-create "*foobar*")
> (insert "\n"
> (propertize " "
> 'face 'my-line
> 'display '(space :width 80))
> "\n")
> (goto-char (point-min)))
> (pop-to-buffer-same-window "*foobar*"))
>
> Try M-x my-line-glitch-repro in both a textual and graphical session,
> then put point on the space displayed as a 80 characters wide line. In
> the graphical instance the line will be hidden (with the beginning being
> displayed *in* the cursor's rectangle in reverse video), in textual
> instances it's still visible (assuming your terminal supports
> underlining).
What did you expect to see instead, and why?
If you set x-stretch-cursor to a non-nil value in the GUI session,
does the result explain what happens?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Thu, 17 Sep 2015 04:58:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 21500 <at> debbugs.gnu.org (full text, mbox):
[Please don't remove the bug address from the CC list. We want this
discussion to be recorded by the bug tracker.]
> Date: Wed, 16 Sep 2015 22:34:02 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
>
> > What did you expect to see instead, and why?
> I did expect to always see a visible line, even with point on that space
> character. What happens instead is that by putting point on it its face
> is used in reverse-video, but only for the actual width of the space
> character, not its declared one.
That's the default Emacs implementation of cursor display on GUI
frames: we erase the character at point, then draw that character
again with cursor colors (normally, in reverse video). For
"white-space" characters, such as TAB and the stretch of white space
created by the 'space' display property, Emacs by default draws the
cursor using the width of the font's SPC character. And that's
exactly what you saw.
> > If you set x-stretch-cursor to a non-nil value in the GUI session,
> > does the result explain what happens?
> Sort of, with it turned on the reverse-video effect goes over the
> declared width of the space character.
Isn't that what you originally expected to see?
> I was wondering whether one could ensure Emacs always renders a face in
> a readable way if it is turned practically invisible.
I don't understand: how does "invisible" come into play here? Are you
talking about faces whose foreground and background are the same color?
> In fact, isn't the `:distant-foreground` property there for a
> similiar reason?
Yes. But the face needs to have that as part of its definition.
Anyway, I see no relation between what you were wondering about and
the effect of cursor display that I believe was the trigger for this
bug report. If you have questions about face rendering, I suggest to
ask them on emacs-devel.
Can we now close the bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Thu, 17 Sep 2015 06:35:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> That's the default Emacs implementation of cursor display on GUI
> frames: we erase the character at point, then draw that character
> again with cursor colors (normally, in reverse video). For
> "white-space" characters, such as TAB and the stretch of white space
> created by the 'space' display property, Emacs by default draws the
> cursor using the width of the font's SPC character. And that's
> exactly what you saw.
Interesting. Now that I've checked again, it's indeed that a terminal
frame does not show any reverse video effects at all with the cursor, so
that explains this display oddity.
> Isn't that what you originally expected to see?
I didn't expect anything specific, just that in any case the entire line
is legible. The difference between the terminal and GUI frame did stump
me.
> I don't understand: how does "invisible" come into play here? Are you
> talking about faces whose foreground and background are the same color?
Yes, if a face has the same color for fore- and background, it's
practically invisible. If you've got any more specific term for this
that is different from invisible as in the special property, I'd be
interested in knowing it.
> Yes. But the face needs to have that as part of its definition.
OK, which face would it be in this case, the cursor or the line face?
> Anyway, I see no relation between what you were wondering about and
> the effect of cursor display that I believe was the trigger for this
> bug report. If you have questions about face rendering, I suggest to
> ask them on emacs-devel.
Well, I do. If putting the cursor on a special space has a different
effect in GUI than in textual frames, I'd like to know what's causing it
and whether there is any way of fixing it.
> Can we now close the bug?
I still don't have a tangible solution at hand for fixing this display
glitch. Altering `x-stretch-cursor` is a workaround, but not as good as
altering, say, the line face to be displayed under every condition by
altering its definition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Thu, 17 Sep 2015 07:06:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 17 Sep 2015 08:34:16 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
> Cc: 21500 <at> debbugs.gnu.org
>
> > That's the default Emacs implementation of cursor display on GUI
> > frames: we erase the character at point, then draw that character
> > again with cursor colors (normally, in reverse video). For
> > "white-space" characters, such as TAB and the stretch of white space
> > created by the 'space' display property, Emacs by default draws the
> > cursor using the width of the font's SPC character. And that's
> > exactly what you saw.
>
> Interesting. Now that I've checked again, it's indeed that a terminal
> frame does not show any reverse video effects at all with the cursor, so
> that explains this display oddity.
Emacs doesn't draw the cursor on text-mode frames. It only moves it
to the proper place, and can turn it off if needed. But the cursor
drawing and blinking is something done by the terminal itself. By
contrast, on GUI frames, it's Emacs that draws the cursor, in the way
I described.
> > Yes. But the face needs to have that as part of its definition.
>
> OK, which face would it be in this case, the cursor or the line face?
The line, of course. That's the face you want to see, even when its
foreground and background colors are identical.
> > Anyway, I see no relation between what you were wondering about and
> > the effect of cursor display that I believe was the trigger for this
> > bug report. If you have questions about face rendering, I suggest to
> > ask them on emacs-devel.
>
> Well, I do. If putting the cursor on a special space has a different
> effect in GUI than in textual frames, I'd like to know what's causing it
> and whether there is any way of fixing it.
See above: what's causing it is the fact that Emacs doesn't draw the
cursor on text-mode frames. And I see no way of "fixing" it. Nor do
I think there's a problem here: this surprising effect happens only
when you have a stretch of white space wider than a single SPC
character, and then only when the cursor is at that buffer position.
E.g., in your scenario add some character, say 'x', before the
whitespace, and move point to that character -- you will see the rest
of the line displayed constantly with no "glitches".
> > Can we now close the bug?
>
> I still don't have a tangible solution at hand for fixing this display
> glitch. Altering `x-stretch-cursor` is a workaround, but not as good as
> altering, say, the line face to be displayed under every condition by
> altering its definition.
I don't think there's a glitch here, and I see no way of "fixing" that
without losing the important indication of the cursor position.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 08:15:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 17 Sep 2015 10:05:37 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 21500 <at> debbugs.gnu.org
>
> > > Can we now close the bug?
> >
> > I still don't have a tangible solution at hand for fixing this display
> > glitch. Altering `x-stretch-cursor` is a workaround, but not as good as
> > altering, say, the line face to be displayed under every condition by
> > altering its definition.
>
> I don't think there's a glitch here, and I see no way of "fixing" that
> without losing the important indication of the cursor position.
Any further information about this, or can we close the bug?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 09:36:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Any further information about this, or can we close the bug?
Is it possible to use the :distant-foreground property to display the
line protruding beyond the cursor shape in a color different from the
background? If yes, what color would it need to have for this to work?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 10:05:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2015 11:35:36 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
> Cc: 21500 <at> debbugs.gnu.org
>
> Is it possible to use the :distant-foreground property to display the
> line protruding beyond the cursor shape in a color different from the
> background? If yes, what color would it need to have for this to work?
I'm not sure why would you need to use :distant-foreground, but maybe
your actual situation is more complicated than the test case you
presented in this bug report. With that test case, if I modify the
face definition like this:
(defface my-line
'((((type graphic)) :background "yellow")
(((type tty)) :inherit font-lock-comment-face :underline t))
"Line face")
I see the line in question all the time. Is this what you want?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 10:57:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure why would you need to use :distant-foreground, but maybe
> your actual situation is more complicated than the test case you
> presented in this bug report. With that test case, if I modify the
> face definition like this:
>
> (defface my-line
> '((((type graphic)) :background "yellow")
> (((type tty)) :inherit font-lock-comment-face :underline t))
> "Line face")
>
> I see the line in question all the time. Is this what you want?
Well, that works, but it does get rid of the line alltogether, so that's
hardly a solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 11:03:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2015 12:56:43 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
> Cc: 21500 <at> debbugs.gnu.org
>
> > I'm not sure why would you need to use :distant-foreground, but maybe
> > your actual situation is more complicated than the test case you
> > presented in this bug report. With that test case, if I modify the
> > face definition like this:
> >
> > (defface my-line
> > '((((type graphic)) :background "yellow")
> > (((type tty)) :inherit font-lock-comment-face :underline t))
> > "Line face")
> >
> > I see the line in question all the time. Is this what you want?
>
> Well, that works, but it does get rid of the line alltogether, so that's
> hardly a solution.
Is the below better?
(defface my-line
'((((type graphic))
:inherit font-lock-comment-face
:strike-through t
:background "yellow")
(((type tty)) :inherit font-lock-comment-face :underline t))
"Line face")
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 12:15:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 21500 <at> debbugs.gnu.org (full text, mbox):
Vasilij Schneidermann <v.schneidermann <at> gmail.com> writes:
> Well, that works, but it does get rid of the line alltogether, so that's
> hardly a solution.
Put the color on the line itself,
:strike-through "red"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 12:18:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Is the below better?
>
> (defface my-line
> '((((type graphic))
> :inherit font-lock-comment-face
> :strike-through t
> :background "yellow")
> (((type tty)) :inherit font-lock-comment-face :underline t))
> "Line face")
Somewhat, but it changes the way the line looks entirely. I'm pretty
happy having found a hack for displaying a continuous line in Emacs in
both graphical and textual frames. Going from a line to a stripe with a
background color is a setback.
Anyway, I assume that if the workarounds consist of changing the display
of the line and this display is no bug, the best I could do would be
either living with this peculiarity or turning this issue into a feature
request. Feel free to close this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21500
; Package
emacs
.
(Sat, 26 Sep 2015 12:23:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 21500 <at> debbugs.gnu.org (full text, mbox):
> Put the color on the line itself,
>
> :strike-through "red"
Thanks! This does work for me. It would be perfect if it could be made
to pick up the foreground of font-lock-comment-face, but eh, it won't
kill me to customize the face instead.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 26 Sep 2015 13:34:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Vasilij Schneidermann <v.schneidermann <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 26 Sep 2015 13:34:05 GMT)
Full text and
rfc822 format available.
Message #46 received at 21500-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Sep 2015 14:22:55 +0200
> From: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 21500 <at> debbugs.gnu.org
>
> > Put the color on the line itself,
> >
> > :strike-through "red"
>
> Thanks! This does work for me. It would be perfect if it could be made
> to pick up the foreground of font-lock-comment-face, but eh, it won't
> kill me to customize the face instead.
OK, closing the bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 25 Oct 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 318 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.