GNU bug report logs - #63271
29.0.90; broken mouse-face

Previous Next

Full log

Message #98 received at 63271 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#63271: 29.0.90; broken mouse-face
Date: Tue, 09 May 2023 16:35:50 +0300

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.