GNU bug report logs -
#63271
29.0.90; broken mouse-face
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Thu, 4 May 2023 15:16:02 UTC
Severity: normal
Found in version 29.0.90
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63271 in the body.
You can then email your comments to 63271 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#63271; Package
emacs.
(Thu, 04 May 2023 15:16:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 04 May 2023 15:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is a regression introduced between 28 and 29.
1. M-x global-tab-line-mode RET
2. C-h C-n ;; (view-emacs-news)
3. C-h C-t ;; (view-emacs-todo)
4. C-x b *scratch* RET
Hover the mouse pointer over the tabs.
Over all tabs mouse-face is 'tab-line-highlight'
that is light grey color. But over the "TODO" tab
the main text is not highlighted with mouse-face.
There is no difference between "NEWS" and "TODO"
with regard to their text properties.
Customizing 'tab-line-highlight' to a more noticeable
background color like red helps the observe the effect.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Thu, 04 May 2023 16:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 04 May 2023 18:11:18 +0300
>
> This is a regression introduced between 28 and 29.
>
> 1. M-x global-tab-line-mode RET
> 2. C-h C-n ;; (view-emacs-news)
> 3. C-h C-t ;; (view-emacs-todo)
> 4. C-x b *scratch* RET
>
> Hover the mouse pointer over the tabs.
> Over all tabs mouse-face is 'tab-line-highlight'
> that is light grey color. But over the "TODO" tab
> the main text is not highlighted with mouse-face.
> There is no difference between "NEWS" and "TODO"
> with regard to their text properties.
> Customizing 'tab-line-highlight' to a more noticeable
> background color like red helps the observe the effect.
I cannot reproduce this with the current emacs-29 branch. All tabs
behave the same as far as mouse-highlight is concerned.
Maybe this is specific to X or GTK? (Why don't you post the details
of your build and configuration, as collected by report-emacs-bug?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 05 May 2023 17:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> 1. M-x global-tab-line-mode RET
>> 2. C-h C-n ;; (view-emacs-news)
>> 3. C-h C-t ;; (view-emacs-todo)
>> 4. C-x b *scratch* RET
>>
>> Hover the mouse pointer over the tabs.
>> Over all tabs mouse-face is 'tab-line-highlight'
>> that is light grey color. But over the "TODO" tab
>> the main text is not highlighted with mouse-face.
>
> I cannot reproduce this with the current emacs-29 branch. All tabs
> behave the same as far as mouse-highlight is concerned.
>
> Maybe this is specific to X or GTK? (Why don't you post the details
> of your build and configuration, as collected by report-emacs-bug?)
Sorry, I didn't expect that details are needed because the bug is 100%
reproducible on GTK, Lucid and no toolkit. But here are the details:
1.
In GNU Emacs 29.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2023-05-05
Repository revision: b1bda8228e5788391cefbb4721af24f5713a0e37
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Linux Mint 20
Configured using:
'configure --with-native-compilation --with-mailutils --without-dbus CC=gcc-10'
Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Minor modes in effect:
global-tab-line-mode: t
tab-line-mode: t
2.
In GNU Emacs 29.0.90 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw3d scroll bars) of 2023-05-05
Repository revision: b1bda8228e5788391cefbb4721af24f5713a0e37
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Linux Mint 20
Configured using:
'configure --with-native-compilation --with-mailutils --without-dbus
--with-x-toolkit=lucid'
Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM
LUCID ZLIB
Minor modes in effect:
global-tab-line-mode: t
tab-line-mode: t
3.
In GNU Emacs 29.0.90 (build 3, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2023-05-05
Repository revision: b1bda8228e5788391cefbb4721af24f5713a0e37
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Linux Mint 20
Configured using:
'configure --with-native-compilation --with-mailutils --without-dbus
--with-x-toolkit=no'
Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS
TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB
Minor modes in effect:
global-tab-line-mode: t
tab-line-mode: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 05 May 2023 18:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 63271 <at> debbugs.gnu.org
> Date: Fri, 05 May 2023 20:38:21 +0300
>
> >> 1. M-x global-tab-line-mode RET
> >> 2. C-h C-n ;; (view-emacs-news)
> >> 3. C-h C-t ;; (view-emacs-todo)
> >> 4. C-x b *scratch* RET
> >>
> >> Hover the mouse pointer over the tabs.
> >> Over all tabs mouse-face is 'tab-line-highlight'
> >> that is light grey color. But over the "TODO" tab
> >> the main text is not highlighted with mouse-face.
> >
> > I cannot reproduce this with the current emacs-29 branch. All tabs
> > behave the same as far as mouse-highlight is concerned.
> >
> > Maybe this is specific to X or GTK? (Why don't you post the details
> > of your build and configuration, as collected by report-emacs-bug?)
>
> Sorry, I didn't expect that details are needed because the bug is 100%
> reproducible on GTK, Lucid and no toolkit. But here are the details:
Very strange. Are you sure the recipe above is all that is needed,
starting from "emacs -Q", to reproduce the problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Sat, 06 May 2023 11:20:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: 63271 <at> debbugs.gnu.org
>> Date: Fri, 05 May 2023 20:38:21 +0300
>>
>> >> 1. M-x global-tab-line-mode RET
>> >> 2. C-h C-n ;; (view-emacs-news)
>> >> 3. C-h C-t ;; (view-emacs-todo)
>> >> 4. C-x b *scratch* RET
>> >>
>> >> Hover the mouse pointer over the tabs.
>> >> Over all tabs mouse-face is 'tab-line-highlight'
>> >> that is light grey color. But over the "TODO" tab
>> >> the main text is not highlighted with mouse-face.
>> >
>> > I cannot reproduce this with the current emacs-29 branch. All tabs
>> > behave the same as far as mouse-highlight is concerned.
>> >
>> > Maybe this is specific to X or GTK? (Why don't you post the details
>> > of your build and configuration, as collected by report-emacs-bug?)
>>
>> Sorry, I didn't expect that details are needed because the bug is 100%
>> reproducible on GTK, Lucid and no toolkit. But here are the details:
>
> Very strange. Are you sure the recipe above is all that is needed,
> starting from "emacs -Q", to reproduce the problem?
I don't see this on any X build.
Would you please post details of the font that is displaying the tab
line?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Sun, 07 May 2023 18:03:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> Very strange. Are you sure the recipe above is all that is needed,
>> starting from "emacs -Q", to reproduce the problem?
>
> I don't see this on any X build.
> Would you please post details of the font that is displaying the tab
> line?
Here is the output of describe-char on the first char of the broken tab:
position: 2 of 35 (3%), column: 1
character: T (displayed as T) (codepoint 84, #o124, #x54)
charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x54
script: latin
syntax: w which means: word
category: .:Base, L:Strong L2R, a:ASCII, l:Latin, r:Roman
to input: type "C-x 8 RET 54" or "C-x 8 RET LATIN CAPITAL LETTER T"
buffer code: #x54
file code: #x54 (encoded by coding system utf-8-unix)
display: by this font (glyph code):
ftcrhb:-PfEd-DejaVu Sans-regular-normal-normal-*-10-*-*-*-*-0-iso10646-1 (#x37)
I think your guess about fonts involved is right
because the problem disappears when the tab-line face
doesn't inherit from the 'variable-pitch' face.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Sun, 07 May 2023 18:35:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 63271 <at> debbugs.gnu.org
> Date: Sun, 07 May 2023 21:00:02 +0300
>
> I think your guess about fonts involved is right
> because the problem disappears when the tab-line face
> doesn't inherit from the 'variable-pitch' face.
How can a face affect mouse-highlight?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 15:58:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 63271 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> I think your guess about fonts involved is right
>> because the problem disappears when the tab-line face
>> doesn't inherit from the 'variable-pitch' face.
>
> How can a face affect mouse-highlight?
Here is the minimal test case:
(insert " " (propertize "TODO"
'face '(:inherit variable-pitch)
'mouse-face 'highlight))
that causes such effect after moving point over highlighted text
in fundamental-mode:
[mouse-face-variable-pitch.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 16:14:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Mon, 08 May 2023 18:56:05 +0300
>
> >> I think your guess about fonts involved is right
> >> because the problem disappears when the tab-line face
> >> doesn't inherit from the 'variable-pitch' face.
> >
> > How can a face affect mouse-highlight?
>
> Here is the minimal test case:
>
> (insert " " (propertize "TODO"
> 'face '(:inherit variable-pitch)
> 'mouse-face 'highlight))
>
> that causes such effect after moving point over highlighted text
> in fundamental-mode:
Not reproducible here. I guess it isn't enough to use a face, you
need a specific font for that?
And what exactly is the manifestation of the problem in the image you
posted? that wide black part that hides the letters "ODO"? or
something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 18:21:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Mon, 08 May 2023 19:14:46 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Mon, 08 May 2023 18:56:05 +0300
>>
>> >> I think your guess about fonts involved is right
>> >> because the problem disappears when the tab-line face
>> >> doesn't inherit from the 'variable-pitch' face.
>> >
>> > How can a face affect mouse-highlight?
>>
>> Here is the minimal test case:
>>
>> (insert " " (propertize "TODO"
>> 'face '(:inherit variable-pitch)
>> 'mouse-face 'highlight))
>>
>> that causes such effect after moving point over highlighted text
>> in fundamental-mode:
>
> Not reproducible here. I guess it isn't enough to use a face, you
> need a specific font for that?
I see the problem here (GNU/Linux, Gtk3), and indeed, it depends on the
font: here the default Variable Pitch face, where the Font Family
attribute has the value Sans Serif, is realized with DejaVu Sans, and
strings that begin not just with "T", but also with "Y", "J" or "j", do
not show mouse-face highlighting; but when I set the Font Family
attribute of Variable Pitch face to Luxi Sans, I see the problem only
with strings beginning with "j". I haven't tested other fonts yet.
> And what exactly is the manifestation of the problem in the image you
> posted? that wide black part that hides the letters "ODO"? or
> something else?
The image that Juri posted (which appears to be from a no-toolkit build)
differs from what I see (under Gtk3), which is simply that the
problematic strings show no mouse-face highlighting when the mouse
pointer moves over them.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 18:27:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Mon, 08 May 2023 20:20:31 +0200
>
> The image that Juri posted (which appears to be from a no-toolkit build)
> differs from what I see (under Gtk3), which is simply that the
> problematic strings show no mouse-face highlighting when the mouse
> pointer moves over them.
mouse-face specifies only the background color, so I'm at a loss how
could a font affect that. There's something I'm missing here. Like
some corruption of the realized faces or something.
Do you see the same in Emacs 28 and 27? If some older version doesn't
show this, any chance of bisecting it?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 18:48:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Mon, 08 May 2023 21:27:49 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Mon, 08 May 2023 20:20:31 +0200
>>
>> The image that Juri posted (which appears to be from a no-toolkit build)
>> differs from what I see (under Gtk3), which is simply that the
>> problematic strings show no mouse-face highlighting when the mouse
>> pointer moves over them.
>
> mouse-face specifies only the background color, so I'm at a loss how
> could a font affect that. There's something I'm missing here. Like
> some corruption of the realized faces or something.
>
> Do you see the same in Emacs 28 and 27? If some older version doesn't
> show this, any chance of bisecting it?
I cannot reproduce the problematic display in Emacs 28. I'll see if I
can bisect, but it may take a while.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 19:11:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> mouse-face specifies only the background color, so I'm at a loss how
>> could a font affect that. There's something I'm missing here. Like
>> some corruption of the realized faces or something.
>>
>> Do you see the same in Emacs 28 and 27? If some older version doesn't
>> show this, any chance of bisecting it?
>
> I cannot reproduce the problematic display in Emacs 28. I'll see if I
> can bisect, but it may take a while.
I tried to bisect and see the problem in
61b9f2c3179..: 2022-11-17 * lisp/emacs-lisp/shortdoc.el (sequence): Don't use cl-lib (bug#59319)
but not in
0636e1066bb..: 2022-11-16 ; Don't unnecessarily use non-ASCII characters in Texinfo
probably because 61b9f2c3179 is the last commit of a big merge at that time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Mon, 08 May 2023 20:48:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Mon, 08 May 2023 22:09:16 +0300 Juri Linkov <juri <at> linkov.net> wrote:
>>> mouse-face specifies only the background color, so I'm at a loss how
>>> could a font affect that. There's something I'm missing here. Like
>>> some corruption of the realized faces or something.
>>>
>>> Do you see the same in Emacs 28 and 27? If some older version doesn't
>>> show this, any chance of bisecting it?
>>
>> I cannot reproduce the problematic display in Emacs 28. I'll see if I
>> can bisect, but it may take a while.
>
> I tried to bisect and see the problem in
>
> 61b9f2c3179..: 2022-11-17 * lisp/emacs-lisp/shortdoc.el (sequence): Don't use
> cl-lib (bug#59319)
>
> but not in
>
> 0636e1066bb..: 2022-11-16 ; Don't unnecessarily use non-ASCII characters in Texinfo
I checked out those commits and rebuilt emacs and can confirm that the
build from 61b9f2c3179 has the problem and the build from 0636e1066bb
does not.
> probably because 61b9f2c3179 is the last commit of a big merge at that time.
If I'm not misreading the vc-change-log, it looks like that commit is
from Stefan's merge of the noverlay branch, and it seems not implausible
that some change in that branch is the source of the problem. (But my
git skills are elementary, so I may well be misreading it.) Is it
possible to confine bisection to the commits from a merge, and if so,
how?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 01:09:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> I think your guess about fonts involved is right
>>> because the problem disappears when the tab-line face
>>> doesn't inherit from the 'variable-pitch' face.
>>
>> How can a face affect mouse-highlight?
>
> Here is the minimal test case:
>
> (insert " " (propertize "TODO"
> 'face '(:inherit variable-pitch)
> 'mouse-face 'highlight))
>
> that causes such effect after moving point over highlighted text
> in fundamental-mode:
>
> x
I don't see this in an Xft build, if it helps. If you place the
following instrumentation in ftcrfont.c:
diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index c9a4de8137b..1e711152ba6 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -593,6 +593,10 @@ ftcrfont_draw (struct glyph_string *s,
s->background_filled_p = 1;
cairo_rectangle (cr, x, y - FONT_BASE (s->font),
s->width, FONT_HEIGHT (s->font));
+ fprintf (stderr, "ftcrfont_draw: %d, %d, %d, %d, %d\n",
+ x, y - FONT_BASE (s->font),
+ s->width, FONT_HEIGHT (s->font),
+ s->hl);
cairo_fill (cr);
}
then move point over the text under mouse face, what is printed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 07:11:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> (insert " " (propertize "TODO"
>> 'face '(:inherit variable-pitch)
>> 'mouse-face 'highlight))
>
> I don't see this in an Xft build, if it helps. If you place the
> following instrumentation in ftcrfont.c:
>
> diff --git a/src/ftcrfont.c b/src/ftcrfont.c
> index c9a4de8137b..1e711152ba6 100644
> --- a/src/ftcrfont.c
> +++ b/src/ftcrfont.c
> @@ -593,6 +593,10 @@ ftcrfont_draw (struct glyph_string *s,
> s->background_filled_p = 1;
> cairo_rectangle (cr, x, y - FONT_BASE (s->font),
> s->width, FONT_HEIGHT (s->font));
> + fprintf (stderr, "ftcrfont_draw: %d, %d, %d, %d, %d\n",
> + x, y - FONT_BASE (s->font),
> + s->width, FONT_HEIGHT (s->font),
> + s->hl);
> cairo_fill (cr);
> }
>
> then move point over the text under mouse face, what is printed?
This is after moving point backward from last "O" to first "T" in "TODO"
while mouse is over the text:
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 58, 56, 12, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 58, 56, 12, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 45, 56, 13, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 45, 56, 13, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 10, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 10, 19, 2
and forward from "T" to "O":
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 45, 56, 13, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 45, 56, 13, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 58, 56, 12, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 58, 56, 12, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 70, 56, 13, 19, 2
ftcrfont_draw: 25, 56, 10, 19, 0
ftcrfont_draw: 35, 56, 48, 19, 0
ftcrfont_draw: 70, 56, 13, 19, 2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 07:11:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> And what exactly is the manifestation of the problem in the image you
> posted? that wide black part that hides the letters "ODO"? or
> something else?
The letters turn into black boxes while moving the cursor over them
when the mouse pointer is over the text.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 07:11:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>>> I cannot reproduce the problematic display in Emacs 28. I'll see if I
>>> can bisect, but it may take a while.
>>
>> I tried to bisect and see the problem in
>>
>> 61b9f2c3179..: 2022-11-17 * lisp/emacs-lisp/shortdoc.el (sequence): Don't use
>> cl-lib (bug#59319)
>>
>> but not in
>>
>> 0636e1066bb..: 2022-11-16 ; Don't unnecessarily use non-ASCII characters in Texinfo
>
> I checked out those commits and rebuilt emacs and can confirm that the
> build from 61b9f2c3179 has the problem and the build from 0636e1066bb
> does not.
Actually, 0636e1066bb was one of the latest commits on emacs-28.
So we need to continue bisecting on emacs-29 down from the commit
be42fdc6dc6..: 2022-04-13 where the test case still fails.
This is one of the last commits before huge merges,
so the history below from it is quite flat and shallow,
and thus easier to bisect.
>> probably because 61b9f2c3179 is the last commit of a big merge at that time.
>
> If I'm not misreading the vc-change-log, it looks like that commit is
> from Stefan's merge of the noverlay branch, and it seems not implausible
> that some change in that branch is the source of the problem. (But my
> git skills are elementary, so I may well be misreading it.) Is it
> possible to confine bisection to the commits from a merge, and if so,
> how?
The git history is a mess, it's really hard to read vc-change-log
interspersed with very deep merges.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 08:36:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 09:45:16 +0300
>
> > And what exactly is the manifestation of the problem in the image you
> > posted? that wide black part that hides the letters "ODO"? or
> > something else?
>
> The letters turn into black boxes while moving the cursor over them
> when the mouse pointer is over the text.
Could you or Stephen please perform the following experiment, using
the latest emacs-29 branch, and report the results:
$ gdb ./emacs
...
(gdb) break xdisp.c:33519
(gdb) run -Q
The breakpoint is here:
if (end_hpos > start_hpos)
{
draw_row_with_mouse_face (w, start_x, row,
start_hpos, end_hpos, draw);
row->mouse_face_p <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
= draw == DRAW_MOUSE_FACE || draw == DRAW_IMAGE_RAISED;
}
Once inside Emacs after "run -Q", first turn off blink-cursor-mode and
global-eldoc-mode, then evaluate the recipe:
M-: (insert " " (propertize "TODO" 'face '(:inherit variable-pitch) 'mouse-face 'highlight)) RET
Then move the mouse pointer over the "TODO" text. The breakpoint will
break, and GDB will kick in. Then type:
(gdb) pgrow
(gdb) continue
The breakpoint will break again, and the display of Emacs you are
debugging will show the mouse highlight. Then type again:
(gdb) pgrow
And show everything that GDB displays as result of the two "pgrow"
commands.
Some notes:
. the breakpoint might break before you evaluate the recipe, if you
happen to move the mouse pointer above some mouse-sensitive
portion of the display, like the tool bar or the mode line -- in
that case just type "continue" at the GDB prompt until it no
longer shows the prompt (meaning Emacs is running again);
. the "pgrow" command is defined in src/.gdbinit file in the Emacs
tree, so you need to start Emacs from the src directory for GDB to
pick up that definition; alternatively, you could tell GDB to read
that file explicitly by typing "source /path/to/emacs/src/.gdbinit"
once inside GDB, before "run -Q";
. if your Emacs is built with optimizations, the breakpoint might
not break, or break not under the expected conditions; in that
case, rebuild with CFLAGS='-O0 -g3' and repeat the above
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 08:43:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 09:43:29 +0300
>
> > --- a/src/ftcrfont.c
> > +++ b/src/ftcrfont.c
> > @@ -593,6 +593,10 @@ ftcrfont_draw (struct glyph_string *s,
> > s->background_filled_p = 1;
> > cairo_rectangle (cr, x, y - FONT_BASE (s->font),
> > s->width, FONT_HEIGHT (s->font));
> > + fprintf (stderr, "ftcrfont_draw: %d, %d, %d, %d, %d\n",
> > + x, y - FONT_BASE (s->font),
> > + s->width, FONT_HEIGHT (s->font),
> > + s->hl);
> > cairo_fill (cr);
> > }
> >
> > then move point over the text under mouse face, what is printed?
>
> This is after moving point backward from last "O" to first "T" in "TODO"
> while mouse is over the text:
>
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 58, 56, 12, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 58, 56, 12, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 45, 56, 13, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 45, 56, 13, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 10, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 10, 19, 2
>
> and forward from "T" to "O":
>
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 45, 56, 13, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 45, 56, 13, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 58, 56, 12, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 58, 56, 12, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 70, 56, 13, 19, 2
> ftcrfont_draw: 25, 56, 10, 19, 0
> ftcrfont_draw: 35, 56, 48, 19, 0
> ftcrfont_draw: 70, 56, 13, 19, 2
s->hl == 2 means DRAW_CURSOR. Why does Emacs draw cursor -- did you
s->move point or did you move the mouse pointer? I thought Po Lu
s->meant the latter, not the former.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 09:50:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 11:36:01 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 09:45:16 +0300
>>
>> > And what exactly is the manifestation of the problem in the image you
>> > posted? that wide black part that hides the letters "ODO"? or
>> > something else?
>>
>> The letters turn into black boxes while moving the cursor over them
>> when the mouse pointer is over the text.
>
> Could you or Stephen please perform the following experiment, using
> the latest emacs-29 branch, and report the results:
>
> $ gdb ./emacs
> ...
> (gdb) break xdisp.c:33519
> (gdb) run -Q
>
> The breakpoint is here:
>
> if (end_hpos > start_hpos)
> {
> draw_row_with_mouse_face (w, start_x, row,
> start_hpos, end_hpos, draw);
>
> row->mouse_face_p <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> = draw == DRAW_MOUSE_FACE || draw == DRAW_IMAGE_RAISED;
> }
>
> Once inside Emacs after "run -Q", first turn off blink-cursor-mode and
> global-eldoc-mode, then evaluate the recipe:
>
> M-: (insert " " (propertize "TODO" 'face '(:inherit variable-pitch) 'mouse-face 'highlight)) RET
>
> Then move the mouse pointer over the "TODO" text. The breakpoint will
> break, and GDB will kick in. Then type:
>
> (gdb) pgrow
> (gdb) continue
>
> The breakpoint will break again, and the display of Emacs you are
> debugging will show the mouse highlight. Then type again:
>
> (gdb) pgrow
>
> And show everything that GDB displays as result of the two "pgrow"
> commands.
Here's what I get:
Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
hlinfo=hlinfo <at> entry=0x555556145870, draw=draw <at> entry=DRAW_MOUSE_FACE)
at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
33519 row->mouse_face_p
(gdb) pgrow
TEXT: 6 glyphs
0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145870,
draw=draw <at> entry=DRAW_MOUSE_FACE)
at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
33519 row->mouse_face_p
(gdb) pgrow
TEXT: 6 glyphs
0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 10:08:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 11:49:00 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Tue, 09 May 2023 11:36:01 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Juri Linkov <juri <at> linkov.net>
>>> Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>>> Date: Tue, 09 May 2023 09:45:16 +0300
>>>
>>> > And what exactly is the manifestation of the problem in the image you
>>> > posted? that wide black part that hides the letters "ODO"? or
>>> > something else?
>>>
>>> The letters turn into black boxes while moving the cursor over them
>>> when the mouse pointer is over the text.
>>
>> Could you or Stephen please perform the following experiment, using
>> the latest emacs-29 branch, and report the results:
>>
>> $ gdb ./emacs
>> ...
>> (gdb) break xdisp.c:33519
>> (gdb) run -Q
>>
>> The breakpoint is here:
>>
>> if (end_hpos > start_hpos)
>> {
>> draw_row_with_mouse_face (w, start_x, row,
>> start_hpos, end_hpos, draw);
>>
>> row->mouse_face_p <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> = draw == DRAW_MOUSE_FACE || draw == DRAW_IMAGE_RAISED;
>> }
>>
>> Once inside Emacs after "run -Q", first turn off blink-cursor-mode and
>> global-eldoc-mode, then evaluate the recipe:
>>
>> M-: (insert " " (propertize "TODO" 'face '(:inherit variable-pitch) 'mouse-face 'highlight)) RET
>>
>> Then move the mouse pointer over the "TODO" text. The breakpoint will
>> break, and GDB will kick in. Then type:
>>
>> (gdb) pgrow
>> (gdb) continue
>>
>> The breakpoint will break again, and the display of Emacs you are
>> debugging will show the mouse highlight. Then type again:
>>
>> (gdb) pgrow
>>
>> And show everything that GDB displays as result of the two "pgrow"
>> commands.
>
> Here's what I get:
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
> hlinfo=hlinfo <at> entry=0x555556145870, draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
> 2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
> 3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
> 4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
> 5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145870,
> draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
> 2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
> 3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
> 4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
> 5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
When I carried out your instructions exactly, I was surprised to see
that "TODO" showed mouse-face highlighting after typing `continue'.
Then I ran my test outside of gdb and indeed, in *scratch* the
problematic characters do show mouse-face highlighting, i.e. in
lisp-interaction mode, but not in fundamental-mode. Then I returned to
gdb and redid your instructions but switched to a buffer in
fundamental-mode before inserting the propertized string. Here are the
results:
Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
hlinfo=hlinfo <at> entry=0x555556145540, draw=draw <at> entry=DRAW_MOUSE_FACE)
at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
33519 row->mouse_face_p
(gdb) pgrow
TEXT: 6 glyphs
0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145540,
draw=draw <at> entry=DRAW_MOUSE_FACE)
at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
33519 row->mouse_face_p
(gdb) pgrow
TEXT: 6 glyphs
0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 10:14:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 11:49:00 +0200
>
> Here's what I get:
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
> hlinfo=hlinfo <at> entry=0x555556145870, draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
> 2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
> 3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
> 4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
> 5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145870,
> draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=146 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=147 blev=0,btyp=L w=8 a+d=13+4 MB
> 2 16: CHAR[O] pos=148 blev=0,btyp=L w=8 a+d=13+4 MB
> 3 24: CHAR[D] pos=149 blev=0,btyp=L w=8 a+d=13+4 MB
> 4 32: CHAR[O] pos=150 blev=0,btyp=L w=8 a+d=13+4 MB
> 5 40: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
Thanks, so far so good.
Next experiment:
$ gdb ./emacs
[...]
(gdb) break xterm.c:8119
(gdb) run -Q
The breakpoint is here:
else if (s->hl == DRAW_MOUSE_FACE)
{
x_set_mouse_face_gc (s); <<<<<<<<<<<<<<<<<<<<<<<<<<<
s->stippled_p = s->face->stipple != 0;
}
Once again, inside Emacs disable blink-cursor-mode and
global-eldoc-mode, then evaluate the recipe:
M-: (insert " " (propertize "TODO" 'face '(:inherit variable-pitch) 'mouse-face 'highlight)) RET
and move the mouse pointer to "TODO". Each time it breaks, please
type:
(gdb) print *s
(gdb) print s->first_glyph - s->row->glyphs[1]
and show the results. On my system the glyph_string s includes 5
glyphs (s->nchars = 5), and the last command above prints "1", which
means the first glyph of the glyph_string is the second glyph on its
screen line (since the line starts with a SPC character that doesn't
have the mouse-highlight face).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 10:21:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 12:07:25 +0200
>
> When I carried out your instructions exactly, I was surprised to see
> that "TODO" showed mouse-face highlighting after typing `continue'.
> Then I ran my test outside of gdb and indeed, in *scratch* the
> problematic characters do show mouse-face highlighting, i.e. in
> lisp-interaction mode, but not in fundamental-mode. Then I returned to
> gdb and redid your instructions but switched to a buffer in
> fundamental-mode before inserting the propertized string. Here are the
> results:
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
> hlinfo=hlinfo <at> entry=0x555556145540, draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
> 2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145540,
> draw=draw <at> entry=DRAW_MOUSE_FACE)
> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
> 33519 row->mouse_face_p
> (gdb) pgrow
> TEXT: 6 glyphs
> 0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
> 1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
> 2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
> 5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
OK, thanks. This is still OK, so please do this with the new
breakpoint as described in my other email. It would be interesting to
see the difference between fundamental-mode and lisp-interaction-mode
with that second breakpoint.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 10:37:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 13:21:36 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 12:07:25 +0200
>>
>> When I carried out your instructions exactly, I was surprised to see
>> that "TODO" showed mouse-face highlighting after typing `continue'.
>> Then I ran my test outside of gdb and indeed, in *scratch* the
>> problematic characters do show mouse-face highlighting, i.e. in
>> lisp-interaction mode, but not in fundamental-mode. Then I returned to
>> gdb and redid your instructions but switched to a buffer in
>> fundamental-mode before inserting the propertized string. Here are the
>> results:
>>
>> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (
>> hlinfo=hlinfo <at> entry=0x555556145540, draw=draw <at> entry=DRAW_MOUSE_FACE)
>> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
>> 33519 row->mouse_face_p
>> (gdb) pgrow
>> TEXT: 6 glyphs
>> 0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
>> 1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
>> 2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
>> (gdb) continue
>> Continuing.
>>
>> Thread 1 "emacs" hit Breakpoint 3, show_mouse_face (hlinfo=0x555556145540,
>> draw=draw <at> entry=DRAW_MOUSE_FACE)
>> at /home/steve/src/emacs/emacs-29/src/xdisp.c:33519
>> 33519 row->mouse_face_p
>> (gdb) pgrow
>> TEXT: 6 glyphs
>> 0 0: CHAR[ ] pos=1 blev=0,btyp=L w=8 a+d=13+4 MB
>> 1 8: CHAR[T] pos=2 blev=0,btyp=L w=8 a+d=13+4 face=24 MB
>> 2 16: CHAR[O] pos=3 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 3 26: CHAR[D] pos=4 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 4 36: CHAR[O] pos=5 blev=0,btyp=L w=10 a+d=13+4 face=24 MB
>> 5 46: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB
>
> OK, thanks. This is still OK, so please do this with the new
> breakpoint as described in my other email. It would be interesting to
> see the difference between fundamental-mode and lisp-interaction-mode
> with that second breakpoint.
lisp-interaction-mode:
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc610)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$1 = {
x = 16,
y = 51,
ybase = 64,
width = 40,
background_width = 633,
height = 17,
left_overhang = 0,
right_overhang = 0,
f = 0x55555611ef10,
w = 0x55555611f160,
row = 0x5555566bac90,
area = TEXT_AREA,
char2b = 0x7fffffffc5f0,
nchars = 5,
hl = DRAW_MOUSE_FACE,
face = 0x5555568e1310,
font = 0x55555603c258,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = true,
background_filled_p = false,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x0,
first_glyph = 0x55555626a030,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x0,
clip_tail = 0x0,
clip = {{
x = 0,
y = 0,
width = 0,
height = 0
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x0,
prev = 0x0
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$2 = 1
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc610)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$3 = {
x = 16,
y = 51,
ybase = 64,
width = 40,
background_width = 633,
height = 17,
left_overhang = 0,
right_overhang = 0,
f = 0x55555611ef10,
w = 0x55555611f160,
row = 0x5555566bac90,
area = TEXT_AREA,
char2b = 0x7fffffffc5f0,
nchars = 5,
hl = DRAW_MOUSE_FACE,
face = 0x5555568e1310,
font = 0x55555603c258,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = true,
background_filled_p = false,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x0,
first_glyph = 0x55555626a030,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x0,
clip_tail = 0x0,
clip = {{
x = 0,
y = 0,
width = 0,
height = 0
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x0,
prev = 0x0
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$4 = 1
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc740)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$5 = {
x = 16,
y = 51,
ybase = 64,
width = 40,
background_width = 633,
height = 17,
left_overhang = 0,
right_overhang = 0,
f = 0x55555611ef10,
w = 0x55555611f160,
row = 0x5555566bac90,
area = TEXT_AREA,
char2b = 0x7fffffffc720,
nchars = 5,
hl = DRAW_MOUSE_FACE,
face = 0x5555568e1310,
font = 0x55555603c258,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = true,
background_filled_p = false,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x0,
first_glyph = 0x55555626a030,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x0,
clip_tail = 0x0,
clip = {{
x = 0,
y = 0,
width = 0,
height = 0
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x0,
prev = 0x0
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$6 = 1
============================================
fundamental-mode:
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc610)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$1 = {
x = 16,
y = 0,
ybase = 13,
width = 38,
background_width = 38,
height = 17,
left_overhang = 1,
right_overhang = 0,
f = 0x5555560f8190,
w = 0x5555560f83e0,
row = 0x5555566c4920,
area = TEXT_AREA,
char2b = 0x7fffffffc5f0,
nchars = 4,
hl = DRAW_MOUSE_FACE,
face = 0x5555561e69d0,
font = 0x5555565ece88,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = false,
background_filled_p = true,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x55555681ba10,
first_glyph = 0x5555565c17e0,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x7fffffffc610,
clip_tail = 0x0,
clip = {{
x = 8,
y = 0,
width = 8,
height = 17
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x7fffffffc500,
prev = 0x7fffffffc400
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$2 = 1
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc500)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$3 = {
x = 54,
y = 0,
ybase = 13,
width = 8,
background_width = 595,
height = 17,
left_overhang = 0,
right_overhang = 0,
f = 0x5555560f8190,
w = 0x5555560f83e0,
row = 0x5555566c4920,
area = TEXT_AREA,
char2b = 0x7fffffffc4f0,
nchars = 1,
hl = DRAW_MOUSE_FACE,
face = 0x5555561e69d0,
font = 0x55555615b778,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = true,
background_filled_p = false,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x0,
first_glyph = 0x5555565c18a0,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x7fffffffc610,
clip_tail = 0x0,
clip = {{
x = 0,
y = 0,
width = 0,
height = 0
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x0,
prev = 0x7fffffffc610
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$4 = 5
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc740)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$5 = {
x = 16,
y = 0,
ybase = 13,
width = 38,
background_width = 38,
height = 17,
left_overhang = 1,
right_overhang = 0,
f = 0x5555560f8190,
w = 0x5555560f83e0,
row = 0x5555566c4920,
area = TEXT_AREA,
char2b = 0x7fffffffc720,
nchars = 4,
hl = DRAW_MOUSE_FACE,
face = 0x5555561e69d0,
font = 0x5555565ece88,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = false,
background_filled_p = true,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x55555681ba10,
first_glyph = 0x5555565c17e0,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x7fffffffc740,
clip_tail = 0x0,
clip = {{
x = 8,
y = 0,
width = 8,
height = 17
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x7fffffffc630,
prev = 0x7fffffffc530
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$6 = 1
(gdb) continue
Continuing.
Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
s=s <at> entry=0x7fffffffc630)
at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
8119 x_set_mouse_face_gc (s);
(gdb) print *s
$7 = {
x = 54,
y = 0,
ybase = 13,
width = 8,
background_width = 595,
height = 17,
left_overhang = 0,
right_overhang = 0,
f = 0x5555560f8190,
w = 0x5555560f83e0,
row = 0x5555566c4920,
area = TEXT_AREA,
char2b = 0x7fffffffc620,
nchars = 1,
hl = DRAW_MOUSE_FACE,
face = 0x5555561e69d0,
font = 0x55555615b778,
cmp = 0x0,
cmp_id = 0,
cmp_from = 0,
cmp_to = 0,
extends_to_end_of_line_p = true,
background_filled_p = false,
font_not_found_p = false,
stippled_p = false,
for_overlaps = 0,
padding_p = false,
gc = 0x0,
first_glyph = 0x5555565c18a0,
img = 0x0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
clip_head = 0x7fffffffc740,
clip_tail = 0x0,
clip = {{
x = 0,
y = 0,
width = 0,
height = 0
}, {
x = 0,
y = 0,
width = 0,
height = 0
}},
num_clips = 0,
underline_position = 0,
underline_thickness = 0,
next = 0x0,
prev = 0x7fffffffc740
}
(gdb) print s->first_glyph - s->row->glyphs[1]
$8 = 5
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 11:46:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> s->hl == 2 means DRAW_CURSOR. Why does Emacs draw cursor -- did you
> move point or did you move the mouse pointer? I thought Po Lu meant
> the latter, not the former.
I meant moving point with the entirety of the text under the mouse
pointer.
I don't see anything obviously wrong here though, sadly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 11:50:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: juri <at> linkov.net, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 12:35:35 +0200
>
> > OK, thanks. This is still OK, so please do this with the new
> > breakpoint as described in my other email. It would be interesting to
> > see the difference between fundamental-mode and lisp-interaction-mode
> > with that second breakpoint.
>
> lisp-interaction-mode:
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc610)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $1 = {
> x = 16,
> y = 51,
> ybase = 64,
> width = 40,
> background_width = 633,
> height = 17,
> left_overhang = 0,
> right_overhang = 0,
> f = 0x55555611ef10,
> w = 0x55555611f160,
> row = 0x5555566bac90,
> area = TEXT_AREA,
> char2b = 0x7fffffffc5f0,
> nchars = 5,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555568e1310,
> font = 0x55555603c258,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = true,
> background_filled_p = false,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x0,
> first_glyph = 0x55555626a030,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x0,
> clip_tail = 0x0,
> clip = {{
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x0,
> prev = 0x0
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $2 = 1
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc610)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $3 = {
> x = 16,
> y = 51,
> ybase = 64,
> width = 40,
> background_width = 633,
> height = 17,
> left_overhang = 0,
> right_overhang = 0,
> f = 0x55555611ef10,
> w = 0x55555611f160,
> row = 0x5555566bac90,
> area = TEXT_AREA,
> char2b = 0x7fffffffc5f0,
> nchars = 5,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555568e1310,
> font = 0x55555603c258,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = true,
> background_filled_p = false,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x0,
> first_glyph = 0x55555626a030,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x0,
> clip_tail = 0x0,
> clip = {{
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x0,
> prev = 0x0
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $4 = 1
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc740)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $5 = {
> x = 16,
> y = 51,
> ybase = 64,
> width = 40,
> background_width = 633,
> height = 17,
> left_overhang = 0,
> right_overhang = 0,
> f = 0x55555611ef10,
> w = 0x55555611f160,
> row = 0x5555566bac90,
> area = TEXT_AREA,
> char2b = 0x7fffffffc720,
> nchars = 5,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555568e1310,
> font = 0x55555603c258,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = true,
> background_filled_p = false,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x0,
> first_glyph = 0x55555626a030,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x0,
> clip_tail = 0x0,
> clip = {{
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x0,
> prev = 0x0
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $6 = 1
>
> ============================================
> fundamental-mode:
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc610)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $1 = {
> x = 16,
> y = 0,
> ybase = 13,
> width = 38,
> background_width = 38,
> height = 17,
> left_overhang = 1,
> right_overhang = 0,
> f = 0x5555560f8190,
> w = 0x5555560f83e0,
> row = 0x5555566c4920,
> area = TEXT_AREA,
> char2b = 0x7fffffffc5f0,
> nchars = 4,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555561e69d0,
> font = 0x5555565ece88,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = false,
> background_filled_p = true,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x55555681ba10,
> first_glyph = 0x5555565c17e0,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x7fffffffc610,
> clip_tail = 0x0,
> clip = {{
> x = 8,
> y = 0,
> width = 8,
> height = 17
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x7fffffffc500,
> prev = 0x7fffffffc400
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $2 = 1
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc500)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $3 = {
> x = 54,
> y = 0,
> ybase = 13,
> width = 8,
> background_width = 595,
> height = 17,
> left_overhang = 0,
> right_overhang = 0,
> f = 0x5555560f8190,
> w = 0x5555560f83e0,
> row = 0x5555566c4920,
> area = TEXT_AREA,
> char2b = 0x7fffffffc4f0,
> nchars = 1,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555561e69d0,
> font = 0x55555615b778,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = true,
> background_filled_p = false,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x0,
> first_glyph = 0x5555565c18a0,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x7fffffffc610,
> clip_tail = 0x0,
> clip = {{
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x0,
> prev = 0x7fffffffc610
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $4 = 5
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc740)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $5 = {
> x = 16,
> y = 0,
> ybase = 13,
> width = 38,
> background_width = 38,
> height = 17,
> left_overhang = 1,
> right_overhang = 0,
> f = 0x5555560f8190,
> w = 0x5555560f83e0,
> row = 0x5555566c4920,
> area = TEXT_AREA,
> char2b = 0x7fffffffc720,
> nchars = 4,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555561e69d0,
> font = 0x5555565ece88,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = false,
> background_filled_p = true,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x55555681ba10,
> first_glyph = 0x5555565c17e0,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x7fffffffc740,
> clip_tail = 0x0,
> clip = {{
> x = 8,
> y = 0,
> width = 8,
> height = 17
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x7fffffffc630,
> prev = 0x7fffffffc530
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $6 = 1
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 3, x_set_glyph_string_gc (
> s=s <at> entry=0x7fffffffc630)
> at /home/steve/src/emacs/emacs-29/src/xterm.c:8119
> 8119 x_set_mouse_face_gc (s);
> (gdb) print *s
> $7 = {
> x = 54,
> y = 0,
> ybase = 13,
> width = 8,
> background_width = 595,
> height = 17,
> left_overhang = 0,
> right_overhang = 0,
> f = 0x5555560f8190,
> w = 0x5555560f83e0,
> row = 0x5555566c4920,
> area = TEXT_AREA,
> char2b = 0x7fffffffc620,
> nchars = 1,
> hl = DRAW_MOUSE_FACE,
> face = 0x5555561e69d0,
> font = 0x55555615b778,
> cmp = 0x0,
> cmp_id = 0,
> cmp_from = 0,
> cmp_to = 0,
> extends_to_end_of_line_p = true,
> background_filled_p = false,
> font_not_found_p = false,
> stippled_p = false,
> for_overlaps = 0,
> padding_p = false,
> gc = 0x0,
> first_glyph = 0x5555565c18a0,
> img = 0x0,
> xwidget = 0x0,
> slice = {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> },
> clip_head = 0x7fffffffc740,
> clip_tail = 0x0,
> clip = {{
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }, {
> x = 0,
> y = 0,
> width = 0,
> height = 0
> }},
> num_clips = 0,
> underline_position = 0,
> underline_thickness = 0,
> next = 0x0,
> prev = 0x7fffffffc740
> }
> (gdb) print s->first_glyph - s->row->glyphs[1]
> $8 = 5
This looks OK to me: it says we display 4 characters in one face and 1
more in another. Which agrees with pgrow and with what I understand
should happen here: the 4 characters T O D O are displayed using the
font of the variable-pitch face, and the blank space after it is
displayed using the default face.
What do you see on the screen in this case? Please describe the
visual appearance of each character in the case of fundamental-mode,
and perhaps also show a screenshot of the window as it is displayed
when the mouse-highlight becomes visible during this scenario.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 12:44:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 63271 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 09 May 2023 14:50:30 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: juri <at> linkov.net, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 12:35:35 +0200
>>
>> > OK, thanks. This is still OK, so please do this with the new
>> > breakpoint as described in my other email. It would be interesting to
>> > see the difference between fundamental-mode and lisp-interaction-mode
>> > with that second breakpoint.
[...]
> This looks OK to me: it says we display 4 characters in one face and 1
> more in another. Which agrees with pgrow and with what I understand
> should happen here: the 4 characters T O D O are displayed using the
> font of the variable-pitch face, and the blank space after it is
> displayed using the default face.
>
> What do you see on the screen in this case? Please describe the
> visual appearance of each character in the case of fundamental-mode,
> and perhaps also show a screenshot of the window as it is displayed
> when the mouse-highlight becomes visible during this scenario.
Here's a screenshot of lisp-interaction-mode when the mouse-highlight
appears:
[Screenshot_2023-05-09_14-10-03.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
And here's one of fundamental-mode:
[Screenshot_2023-05-09_14-20-12.png (image/png, attachment)]
[Message part 5 (text/plain, inline)]
Aside from the difference in highlighting, another difference I failed
to notice before is that in fundamental-mode the string "TODO" is
displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
Mono, although I used the same Lisp code with the face property
(:inherit variable-pitch) to enter the string in both buffers. I guess
lisp-interaction-mode inhibits variable-pitch face and that's the reason
the mouse-highlighting appears on the problematic characters in that
mode, in contrast to fundamental-mode.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 12:53:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Tue, 09 May 2023 14:50:30 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Cc: juri <at> linkov.net, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>>> Date: Tue, 09 May 2023 12:35:35 +0200
>>>
>>> > OK, thanks. This is still OK, so please do this with the new
>>> > breakpoint as described in my other email. It would be interesting to
>>> > see the difference between fundamental-mode and lisp-interaction-mode
>>> > with that second breakpoint.
> [...]
>> This looks OK to me: it says we display 4 characters in one face and 1
>> more in another. Which agrees with pgrow and with what I understand
>> should happen here: the 4 characters T O D O are displayed using the
>> font of the variable-pitch face, and the blank space after it is
>> displayed using the default face.
>>
>> What do you see on the screen in this case? Please describe the
>> visual appearance of each character in the case of fundamental-mode,
>> and perhaps also show a screenshot of the window as it is displayed
>> when the mouse-highlight becomes visible during this scenario.
>
> Here's a screenshot of lisp-interaction-mode when the mouse-highlight
> appears:
>
> x
>
>
> And here's one of fundamental-mode:
>
> x
>
>
> Aside from the difference in highlighting, another difference I failed
> to notice before is that in fundamental-mode the string "TODO" is
> displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
> Mono, although I used the same Lisp code with the face property
> (:inherit variable-pitch) to enter the string in both buffers. I guess
> lisp-interaction-mode inhibits variable-pitch face and that's the reason
> the mouse-highlighting appears on the problematic characters in that
> mode, in contrast to fundamental-mode.
>
> Steve Berman
What if you change the font driver in use to something else, like X?
i.e.
(set-frame-parameter (selected-frame) 'font-backend "x")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 13:13:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 20:52:24 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
[...]
>> Aside from the difference in highlighting, another difference I failed
>> to notice before is that in fundamental-mode the string "TODO" is
>> displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
>> Mono, although I used the same Lisp code with the face property
>> (:inherit variable-pitch) to enter the string in both buffers. I guess
>> lisp-interaction-mode inhibits variable-pitch face and that's the reason
>> the mouse-highlighting appears on the problematic characters in that
>> mode, in contrast to fundamental-mode.
>>
>> Steve Berman
>
> What if you change the font driver in use to something else, like X?
> i.e.
>
> (set-frame-parameter (selected-frame) 'font-backend "x")
With that the highlighting problem in fundamental-mode vanishes: all
problematic strings show mouse-highlighting. (FTR, with the "x"
font-backend, the default face here is displayed with adobe-courier and
variable-pitch face is displayed with adobe-helvetica.)
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 13:32:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: juri <at> linkov.net, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 14:43:02 +0200
>
> > What do you see on the screen in this case? Please describe the
> > visual appearance of each character in the case of fundamental-mode,
> > and perhaps also show a screenshot of the window as it is displayed
> > when the mouse-highlight becomes visible during this scenario.
>
> Here's a screenshot of lisp-interaction-mode when the mouse-highlight
> appears:
Thanks. This is strange. Can you try one more thing, please? With
the same breakpoint in xterm.c, when the breakpoint breaks, please
type
(gdb) print/x s->face->background
Please do this every time the breakpoint breaks, and let's see if
Emacs thinks both the "TODO" text and the blank after it should be
displayed with the same background color (which should be the
background of the 'highlight' face). That's what I see on my system.
If the colors of the two glyph_string's indeed match, I'm led to
believe that the problem is elsewhere, in the low levels of drawing
the stuff on screen. Perhaps some library (Cairo?) has a bug or
something. Because the data structures prepared by the Emacs display
engine are correct, and explicitly specify the mouse-highlight
background to be drawn. So somehow using this particular font erases
the background, or something to that effect. This is also consistent
with the fact that other font backends don't show the problem.
Po Lu, any ideas how to look into this further?
> Aside from the difference in highlighting, another difference I failed
> to notice before is that in fundamental-mode the string "TODO" is
> displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
> Mono, although I used the same Lisp code with the face property
> (:inherit variable-pitch) to enter the string in both buffers. I guess
> lisp-interaction-mode inhibits variable-pitch face and that's the reason
> the mouse-highlighting appears on the problematic characters in that
> mode, in contrast to fundamental-mode.
This is actually easy to understand, and is expected:
lisp-interaction-mode has font-lock-mode turned on, and thus the
recipe you evaluate doesn't change the face (thus the font), only adds
mouse-highlight.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 13:35:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, juri <at> linkov.net, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 15:12:06 +0200
>
> On Tue, 09 May 2023 20:52:24 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>
> > What if you change the font driver in use to something else, like X?
> > i.e.
> >
> > (set-frame-parameter (selected-frame) 'font-backend "x")
>
> With that the highlighting problem in fundamental-mode vanishes: all
> problematic strings show mouse-highlighting. (FTR, with the "x"
> font-backend, the default face here is displayed with adobe-courier and
> variable-pitch face is displayed with adobe-helvetica.)
Does changing the font backend also changes the font used for the
variable-pitch face? If it does, then perhaps you could force Emacs
to use the same font by customizing the variable-pitch face? Since we
already know that the font somehow affects this issue, we need to try
to use the same font with different backends, to be sure it's the
backend that counts, not the font.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 14:35:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 16:32:07 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: juri <at> linkov.net, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 14:43:02 +0200
>>
>> > What do you see on the screen in this case? Please describe the
>> > visual appearance of each character in the case of fundamental-mode,
>> > and perhaps also show a screenshot of the window as it is displayed
>> > when the mouse-highlight becomes visible during this scenario.
>>
>> Here's a screenshot of lisp-interaction-mode when the mouse-highlight
>> appears:
>
> Thanks. This is strange. Can you try one more thing, please? With
> the same breakpoint in xterm.c, when the breakpoint breaks, please
> type
>
> (gdb) print/x s->face->background
>
> Please do this every time the breakpoint breaks, and let's see if
> Emacs thinks both the "TODO" text and the blank after it should be
> displayed with the same background color (which should be the
> background of the 'highlight' face). That's what I see on my system.
In both fundamental-mode and lisp-interaction-mode the above command
returned the same value at every break: 0xffb4eeb4 (i.e, $1 =
0xffb4eeb4, $2 = 0xffb4eeb4, etc.).
> If the colors of the two glyph_string's indeed match, I'm led to
> believe that the problem is elsewhere, in the low levels of drawing
> the stuff on screen. Perhaps some library (Cairo?) has a bug or
> something. Because the data structures prepared by the Emacs display
> engine are correct, and explicitly specify the mouse-highlight
> background to be drawn. So somehow using this particular font erases
> the background, or something to that effect. This is also consistent
> with the fact that other font backends don't show the problem.
Yes, it looks like a font plus backend problem.
> Po Lu, any ideas how to look into this further?
>
>> Aside from the difference in highlighting, another difference I failed
>> to notice before is that in fundamental-mode the string "TODO" is
>> displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
>> Mono, although I used the same Lisp code with the face property
>> (:inherit variable-pitch) to enter the string in both buffers. I guess
>> lisp-interaction-mode inhibits variable-pitch face and that's the reason
>> the mouse-highlighting appears on the problematic characters in that
>> mode, in contrast to fundamental-mode.
>
> This is actually easy to understand, and is expected:
> lisp-interaction-mode has font-lock-mode turned on, and thus the
> recipe you evaluate doesn't change the face (thus the font), only adds
> mouse-highlight.
Ok, thanks.
BTW, in the screen shot of fundamental-mode I neglected to note that
"TODO" appears to be in bold-face when the mouse pointer moves over it,
and outside of gdb, when I move the mouse pointer over "TODO" and then
away, I can clearly see the thickness of the characters change (but I
cannot verify this with `C-u C-x =', which says "ftcrhb:-PfEd-DejaVu
Sans-regular-normal-normal-*-19-*-*-*-*-0-iso10646-1 (#x37)" both when
the mouse pointer is over the string and when it isn't).
BTW2: In checking the above, I unintentionaly but fortuitously created
the the same image the Juri posted, where "TODO" has a black background,
"ODO" is not visible, and "T" has same foreground color as
mouse-highlight. I did this by keeping the mouse pointer over "T" and
moving the cursor (i.e. point) leftwards from the end of the string: as
point moves over each character, its foreground appears in
mouse-highlight and on moving point to the next character to the left,
the black cursor block remains on the character it just moved off of,
leaving the character invisible.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 14:35:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 16:35:50 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, juri <at> linkov.net, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 15:12:06 +0200
>>
>> On Tue, 09 May 2023 20:52:24 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>
>> > What if you change the font driver in use to something else, like X?
>> > i.e.
>> >
>> > (set-frame-parameter (selected-frame) 'font-backend "x")
>>
>> With that the highlighting problem in fundamental-mode vanishes: all
>> problematic strings show mouse-highlighting. (FTR, with the "x"
>> font-backend, the default face here is displayed with adobe-courier and
>> variable-pitch face is displayed with adobe-helvetica.)
>
> Does changing the font backend also changes the font used for the
> variable-pitch face? If it does, then perhaps you could force Emacs
> to use the same font by customizing the variable-pitch face? Since we
> already know that the font somehow affects this issue, we need to try
> to use the same font with different backends, to be sure it's the
> backend that counts, not the font.
As I noted previously, here with ftcrhb variable-pitch face is displayed
with DejaVu Sans. When I change the font-backend to "x", variable-pitch
face is displayed with adobe-helvetica, as noted, but when I change its
Font Family attribute to DejaVu Sans, the "TODO" string in
fundamental-mode, propertized to inherit variable-pitch, is displayed
with adobe-times. So it seems that DejaVu Sans cannot be used by the x
font-backend.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 19:08:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> I checked out those commits and rebuilt emacs and can confirm that the
>> build from 61b9f2c3179 has the problem and the build from 0636e1066bb
>> does not.
>
> Actually, 0636e1066bb was one of the latest commits on emacs-28.
> So we need to continue bisecting on emacs-29 down from the commit
> be42fdc6dc6..: 2022-04-13 where the test case still fails.
> This is one of the last commits before huge merges,
> so the history below from it is quite flat and shallow,
> and thus easier to bisect.
I finished bisection, and not sure if this helps,
but that commit was 85a078e7853.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 19:22:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 22:06:52 +0300
>
> I finished bisection, and not sure if this helps,
> but that commit was 85a078e7853.
Thanks, but I don't see how this could be true: those changes are all
conditioned by HAIKU-related conditionals, and I don't suppose you run
a Haiku build of Emacs, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Tue, 09 May 2023 23:20:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> I finished bisection, and not sure if this helps, but that commit was
>> 85a078e7853.
>
> Thanks, but I don't see how this could be true: those changes are all
> conditioned by HAIKU-related conditionals, and I don't suppose you run a
> Haiku build of Emacs, right?
>
Git bisect is always right. I confirm that this bug is due to 85a078e785,
which added, in ftcrfont_draw, a
s->background_filled_p = 1;
statement inside a #ifndef USE_BE_CAIRO (note the "n"). A few days later
a1aa9cbf57 moved that statement ouside of the conditional. Removing that
statement fixes the bug. I'm not sure what that statement is supposed to
do however, it might be necessary, but only for Haiku.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 00:36:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Tue, 09 May 2023 16:35:50 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, juri <at> linkov.net, 63271 <at> debbugs.gnu.org
>>> Date: Tue, 09 May 2023 15:12:06 +0200
>>>
>>> On Tue, 09 May 2023 20:52:24 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>>
>>> > What if you change the font driver in use to something else, like X?
>>> > i.e.
>>> >
>>> > (set-frame-parameter (selected-frame) 'font-backend "x")
>>>
>>> With that the highlighting problem in fundamental-mode vanishes: all
>>> problematic strings show mouse-highlighting. (FTR, with the "x"
>>> font-backend, the default face here is displayed with adobe-courier and
>>> variable-pitch face is displayed with adobe-helvetica.)
>>
>> Does changing the font backend also changes the font used for the
>> variable-pitch face? If it does, then perhaps you could force Emacs
>> to use the same font by customizing the variable-pitch face? Since we
>> already know that the font somehow affects this issue, we need to try
>> to use the same font with different backends, to be sure it's the
>> backend that counts, not the font.
>
> As I noted previously, here with ftcrhb variable-pitch face is displayed
> with DejaVu Sans. When I change the font-backend to "x", variable-pitch
> face is displayed with adobe-helvetica, as noted, but when I change its
> Font Family attribute to DejaVu Sans, the "TODO" string in
> fundamental-mode, propertized to inherit variable-pitch, is displayed
> with adobe-times. So it seems that DejaVu Sans cannot be used by the x
> font-backend.
>
> Steve Berman
X doesn't support the same fonts that Cairo does. But does the same
thing happen if you use a build with Xft (i.e. --without-cairo), with
the same font?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 00:48:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 63271 <at> debbugs.gnu.org
>> Date: Tue, 09 May 2023 22:06:52 +0300
>>
>> I finished bisection, and not sure if this helps,
>> but that commit was 85a078e7853.
>
> Thanks, but I don't see how this could be true: those changes are all
> conditioned by HAIKU-related conditionals, and I don't suppose you run
> a Haiku build of Emacs, right?
Does s->for_overlaps happen to be set in the glyph string drawn when the
phys cursor is erased?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 00:49:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks. This is strange. Can you try one more thing, please? With
> the same breakpoint in xterm.c, when the breakpoint breaks, please
> type
>
> (gdb) print/x s->face->background
>
> Please do this every time the breakpoint breaks, and let's see if
> Emacs thinks both the "TODO" text and the blank after it should be
> displayed with the same background color (which should be the
> background of the 'highlight' face). That's what I see on my system.
>
> If the colors of the two glyph_string's indeed match, I'm led to
> believe that the problem is elsewhere, in the low levels of drawing
> the stuff on screen. Perhaps some library (Cairo?) has a bug or
> something. Because the data structures prepared by the Emacs display
> engine are correct, and explicitly specify the mouse-highlight
> background to be drawn. So somehow using this particular font erases
> the background, or something to that effect. This is also consistent
> with the fact that other font backends don't show the problem.
>
> Po Lu, any ideas how to look into this further?
Yes, please, show
(gdb) p s->for_overlaps
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 09:40:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Tue, 09 May 2023 23:19:35 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>> I finished bisection, and not sure if this helps, but that commit was
>>> 85a078e7853.
>>
>> Thanks, but I don't see how this could be true: those changes are all
>> conditioned by HAIKU-related conditionals, and I don't suppose you run a
>> Haiku build of Emacs, right?
>>
>
> Git bisect is always right. I confirm that this bug is due to 85a078e785,
> which added, in ftcrfont_draw, a
>
> s->background_filled_p = 1;
>
> statement inside a #ifndef USE_BE_CAIRO (note the "n"). A few days later
> a1aa9cbf57 moved that statement ouside of the conditional. Removing that
> statement fixes the bug. I'm not sure what that statement is supposed to do
> however, it might be necessary, but only for Haiku.
I confirm that after rebuilding emacs-29 with that line commented out,
the mouse-face highlighting problems no longer occur (here under Gtk3
with Cairo).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 09:40:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Wed, 10 May 2023 08:34:56 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Tue, 09 May 2023 16:35:50 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, juri <at> linkov.net, 63271 <at> debbugs.gnu.org
>>>> Date: Tue, 09 May 2023 15:12:06 +0200
>>>>
>>>> On Tue, 09 May 2023 20:52:24 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>>>
>>>> > What if you change the font driver in use to something else, like X?
>>>> > i.e.
>>>> >
>>>> > (set-frame-parameter (selected-frame) 'font-backend "x")
>>>>
>>>> With that the highlighting problem in fundamental-mode vanishes: all
>>>> problematic strings show mouse-highlighting. (FTR, with the "x"
>>>> font-backend, the default face here is displayed with adobe-courier and
>>>> variable-pitch face is displayed with adobe-helvetica.)
>>>
>>> Does changing the font backend also changes the font used for the
>>> variable-pitch face? If it does, then perhaps you could force Emacs
>>> to use the same font by customizing the variable-pitch face? Since we
>>> already know that the font somehow affects this issue, we need to try
>>> to use the same font with different backends, to be sure it's the
>>> backend that counts, not the font.
>>
>> As I noted previously, here with ftcrhb variable-pitch face is displayed
>> with DejaVu Sans. When I change the font-backend to "x", variable-pitch
>> face is displayed with adobe-helvetica, as noted, but when I change its
>> Font Family attribute to DejaVu Sans, the "TODO" string in
>> fundamental-mode, propertized to inherit variable-pitch, is displayed
>> with adobe-times. So it seems that DejaVu Sans cannot be used by the x
>> font-backend.
>>
>> Steve Berman
>
> X doesn't support the same fonts that Cairo does. But does the same
> thing happen if you use a build with Xft (i.e. --without-cairo), with
> the same font?
After rebuilding --without-cairo (and retaining the change in
a1aa9cbf57, which Gregory Heytings found to be the cause of the problem,
at least in builds with Cairo), the problem no longer occurs,
i.e. mouse-highlighting works with "TODO" and the other test cases, with
DejaVu Sans as the font displaying variable-pitch face.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 10:54:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Tue, 09 May 2023 23:19:35 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>
>>>> I finished bisection, and not sure if this helps, but that commit was
>>>> 85a078e7853.
>>>
>>> Thanks, but I don't see how this could be true: those changes are all
>>> conditioned by HAIKU-related conditionals, and I don't suppose you run a
>>> Haiku build of Emacs, right?
>>>
>>
>> Git bisect is always right. I confirm that this bug is due to 85a078e785,
>> which added, in ftcrfont_draw, a
>>
>> s->background_filled_p = 1;
>>
>> statement inside a #ifndef USE_BE_CAIRO (note the "n"). A few days later
>> a1aa9cbf57 moved that statement ouside of the conditional. Removing that
>> statement fixes the bug. I'm not sure what that statement is supposed to do
>> however, it might be necessary, but only for Haiku.
>
> I confirm that after rebuilding emacs-29 with that line commented out,
> the mouse-face highlighting problems no longer occur (here under Gtk3
> with Cairo).
>
> Steve Berman
Would you please answer my other question? Namely, what is:
(gdb) p s->for_overlaps
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 11:00:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 09 May 2023 23:19:35 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Juri Linkov <juri <at> linkov.net>, luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org,
> stephen.berman <at> gmx.net
>
> I confirm that this bug is due to 85a078e785, which added, in
> ftcrfont_draw, a
>
> s->background_filled_p = 1;
>
> statement inside a #ifndef USE_BE_CAIRO (note the "n"). A few days later
> a1aa9cbf57 moved that statement ouside of the conditional. Removing that
> statement fixes the bug. I'm not sure what that statement is supposed to
> do however, it might be necessary, but only for Haiku.
Thanks.
Po Lu, was that change intentional? If not, let's remove that line or
move it under some conditional that doesn't include all Cairo builds.
If it was intentional, please explain why, and let's take it from
there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 11:02:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 63271 <at> debbugs.gnu.org (full text, mbox):
On Wed, 10 May 2023 18:53:34 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Tue, 09 May 2023 23:19:35 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>
>>>>> I finished bisection, and not sure if this helps, but that commit was
>>>>> 85a078e7853.
>>>>
>>>> Thanks, but I don't see how this could be true: those changes are all
>>>> conditioned by HAIKU-related conditionals, and I don't suppose you run a
>>>> Haiku build of Emacs, right?
>>>>
>>>
>>> Git bisect is always right. I confirm that this bug is due to 85a078e785,
>>> which added, in ftcrfont_draw, a
>>>
>>> s->background_filled_p = 1;
>>>
>>> statement inside a #ifndef USE_BE_CAIRO (note the "n"). A few days later
>>> a1aa9cbf57 moved that statement ouside of the conditional. Removing that
>>> statement fixes the bug. I'm not sure what that statement is supposed to do
>>> however, it might be necessary, but only for Haiku.
>>
>> I confirm that after rebuilding emacs-29 with that line commented out,
>> the mouse-face highlighting problems no longer occur (here under Gtk3
>> with Cairo).
>>
>> Steve Berman
>
> Would you please answer my other question? Namely, what is:
>
> (gdb) p s->for_overlaps
I tried that using Eli's second experiment recipe (with breakpoint
xterm.c:8119) and after hitting the breakpoint and entering that
command, it returned this: $1 = 0
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Wed, 10 May 2023 12:05:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>,
> Juri Linkov <juri <at> linkov.net>, 63271 <at> debbugs.gnu.org
> Date: Wed, 10 May 2023 18:53:34 +0800
>
> Would you please answer my other question? Namely, what is:
>
> (gdb) p s->for_overlaps
It was already reported as part of the investigation, with the full
contents of the glyph_strings: it's zero. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63271#77
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Thu, 11 May 2023 00:52:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Po Lu, was that change intentional? If not, let's remove that line or
> move it under some conditional that doesn't include all Cairo builds.
> If it was intentional, please explain why, and let's take it from
> there.
It was needed to prevent drawing overhangs as part of the cursor from
overwriting surrounding characters with the glyph string background.
Unfortunately, I don't remember why it was needed, though I think the
underlying reason has been fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Thu, 11 May 2023 06:00:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Gregory Heytings <gregory <at> heytings.org>, juri <at> linkov.net,
> 63271 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
> Date: Thu, 11 May 2023 08:51:05 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Po Lu, was that change intentional? If not, let's remove that line or
> > move it under some conditional that doesn't include all Cairo builds.
> > If it was intentional, please explain why, and let's take it from
> > there.
>
> It was needed to prevent drawing overhangs as part of the cursor from
> overwriting surrounding characters with the glyph string background.
>
> Unfortunately, I don't remember why it was needed, though I think the
> underlying reason has been fixed.
So can we undo that now? If there is still a reason for doing
something special there, it will pop up sooner or later, and we can
deal with it at that time. At the very least, the setting of
s->background_filled_p should not be done when s->hl is one of the
last 3 values in enum draw_glyphs_face, I think, and maybe also when
s->for_overlaps is zero.
I'd like to fix this soon, because I want to make another pretest of
29.1.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Thu, 11 May 2023 06:25:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: Gregory Heytings <gregory <at> heytings.org>, juri <at> linkov.net,
>> 63271 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
>> Date: Thu, 11 May 2023 08:51:05 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Po Lu, was that change intentional? If not, let's remove that line or
>> > move it under some conditional that doesn't include all Cairo builds.
>> > If it was intentional, please explain why, and let's take it from
>> > there.
>>
>> It was needed to prevent drawing overhangs as part of the cursor from
>> overwriting surrounding characters with the glyph string background.
>>
>> Unfortunately, I don't remember why it was needed, though I think the
>> underlying reason has been fixed.
>
> So can we undo that now? If there is still a reason for doing
> something special there, it will pop up sooner or later, and we can
> deal with it at that time. At the very least, the setting of
> s->background_filled_p should not be done when s->hl is one of the
> last 3 values in enum draw_glyphs_face, I think, and maybe also when
> s->for_overlaps is zero.
>
> I'd like to fix this soon, because I want to make another pretest of
> 29.1.
Yes, but please wait a day or two for me to get to a machine where I can
test this. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 12 May 2023 03:20:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 63271 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: Gregory Heytings <gregory <at> heytings.org>, juri <at> linkov.net,
>> 63271 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
>> Date: Thu, 11 May 2023 08:51:05 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Po Lu, was that change intentional? If not, let's remove that line or
>> > move it under some conditional that doesn't include all Cairo builds.
>> > If it was intentional, please explain why, and let's take it from
>> > there.
>>
>> It was needed to prevent drawing overhangs as part of the cursor from
>> overwriting surrounding characters with the glyph string background.
>>
>> Unfortunately, I don't remember why it was needed, though I think the
>> underlying reason has been fixed.
>
> So can we undo that now? If there is still a reason for doing
> something special there, it will pop up sooner or later, and we can
> deal with it at that time. At the very least, the setting of
> s->background_filled_p should not be done when s->hl is one of the
> last 3 values in enum draw_glyphs_face, I think, and maybe also when
> s->for_overlaps is zero.
>
> I'd like to fix this soon, because I want to make another pretest of
> 29.1.
>
> Thanks.
Please go ahead and remove it from ftcrfont.c. The reason it was added
has already been fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 12 May 2023 10:43:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 63271 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: gregory <at> heytings.org, juri <at> linkov.net, 63271 <at> debbugs.gnu.org,
> stephen.berman <at> gmx.net
> Date: Fri, 12 May 2023 11:19:01 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I'd like to fix this soon, because I want to make another pretest of
> > 29.1.
> >
> > Thanks.
>
> Please go ahead and remove it from ftcrfont.c. The reason it was added
> has already been fixed.
Since I cannot verify the fix on my system, please confirm that the
change you asked me to install is the one below.
diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index c9a4de8..4956469 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -590,7 +590,6 @@ ftcrfont_draw (struct glyph_string *s,
GREEN_FROM_ULONG (col) / 255.0,
BLUE_FROM_ULONG (col) / 255.0);
#endif
- s->background_filled_p = 1;
cairo_rectangle (cr, x, y - FONT_BASE (s->font),
s->width, FONT_HEIGHT (s->font));
cairo_fill (cr);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 12 May 2023 12:50:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>
> Since I cannot verify the fix on my system, please confirm that the
> change you asked me to install is the one below.
>
Yes, that change is correct. Juri could perhaps also confirm that this
fixes the bug for him.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63271; Package
emacs.
(Fri, 12 May 2023 17:29:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 63271 <at> debbugs.gnu.org (full text, mbox):
>> Since I cannot verify the fix on my system, please confirm that the
>> change you asked me to install is the one below.
>>
>
> Yes, that change is correct. Juri could perhaps also confirm that this
> fixes the bug for him.
I confirm that this patch completely fixes the reported problem.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 12 May 2023 19:22:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Juri Linkov <juri <at> linkov.net>:
bug acknowledged by developer.
(Fri, 12 May 2023 19:22:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 63271-done <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>,
> stephen.berman <at> gmx.net, 63271 <at> debbugs.gnu.org
> Date: Fri, 12 May 2023 20:20:47 +0300
>
> >> Since I cannot verify the fix on my system, please confirm that the
> >> change you asked me to install is the one below.
> >>
> >
> > Yes, that change is correct. Juri could perhaps also confirm that this
> > fixes the bug for him.
>
> I confirm that this patch completely fixes the reported problem.
Thanks, installed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 10 Jun 2023 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.