GNU bug report logs -
#43148
27.1; Widget text seems to disappear when building with Cairo and Xaw
Previous Next
Reported by: Pouar Dragon <pouar <at> pouar.net>
Date: Tue, 1 Sep 2020 04:32:01 UTC
Severity: normal
Merged with 43147,
43149
Found in version 27.1
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
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 43148 in the body.
You can then email your comments to 43148 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#43148; Package
emacs.
(Tue, 01 Sep 2020 04:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pouar Dragon <pouar <at> pouar.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 01 Sep 2020 04:32:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
widgets when building with Xaw and Cairo seem to have missing text,
looking like this
[ss.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
is reverted
In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.3, Xaw3d scroll bars)
of 2020-08-31 built on PouarArch
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: makepkg
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Arch Linux
Recent messages:
Checking 87 files in /usr/share/emacs/27.1/lisp/calc...
Checking 113 files in /usr/share/emacs/27.1/lisp/obsolete...
Checking for load-path shadows...done
You can run the command ‘report-emacs-bug’ with M-x r-em RET
Checking for load-path shadows...done
Mark set
Beginning of buffer
Undo [3 times]
C-? is undefined [3 times]
Redo [2 times]
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=lucid --with-xft --with-modules
--with-imagemagick --with-mailutils --with-cairo --with-rsvg'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS
GSETTINGS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ
M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES
THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP
Important settings:
value of $LC_COLLATE: C
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(help-mode pp shadow sort mail-extr emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search seq byte-opt gv bytecomp byte-compile cconv
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date subr-x cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 50575 12154)
(symbols 48 6210 1)
(strings 32 16997 2285)
(string-bytes 1 537126)
(vectors 16 11058)
(vector-slots 8 141008 18188)
(floats 8 25 34)
(intervals 56 309 88)
(buffers 1000 14))
Merged 43147 43148.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Tue, 01 Sep 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Merged 43147 43148 43149.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Tue, 01 Sep 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Sep 2020 14:10:01 GMT)
Full text and
rfc822 format available.
Message #12 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Pouar Dragon <pouar <at> pouar.net>
> Date: Mon, 31 Aug 2020 21:34:46 -0500
>
> widgets when building with Xaw and Cairo seem to have missing text,
> looking like this
>
> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
> is reverted
Thanks. I hope Yamamoto-san will be able to take a look at this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Sep 2020 15:07:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Pouar Dragon <pouar <at> pouar.net>
>> Date: Mon, 31 Aug 2020 21:34:46 -0500
>>
>> widgets when building with Xaw and Cairo seem to have missing text,
>> looking like this
>>
>> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
>> is reverted
Eli> Thanks. I hope Yamamoto-san will be able to take a look at this.
Putting on my 'let's simplify' hat, is this really a combination we
want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
(Iʼm surprised it even builds).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Sep 2020 15:53:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Pouar Dragon <pouar <at> pouar.net>, YAMAMOTO Mitsuharu
> <mituharu <at> math.s.chiba-u.ac.jp>, 43148 <at> debbugs.gnu.org
> Date: Tue, 01 Sep 2020 17:05:55 +0200
>
> >>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Pouar Dragon <pouar <at> pouar.net>
> >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> >>
> >> widgets when building with Xaw and Cairo seem to have missing text,
> >> looking like this
> >>
> >> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
> >> is reverted
>
> Eli> Thanks. I hope Yamamoto-san will be able to take a look at this.
>
> Putting on my 'let's simplify' hat, is this really a combination we
> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
> (Iʼm surprised it even builds).
I wasn't aware that it's a rare configuration. We definitely support
Lucid, right? If so, is Xaw the problem? and if it is, what are the
alternatives that are less "non-mainstream"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Sep 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 01 Sep 2020 18:51:47 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Pouar Dragon <pouar <at> pouar.net>, YAMAMOTO Mitsuharu
>> <mituharu <at> math.s.chiba-u.ac.jp>, 43148 <at> debbugs.gnu.org
>> Date: Tue, 01 Sep 2020 17:05:55 +0200
>>
>> >>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>
>> >> From: Pouar Dragon <pouar <at> pouar.net>
>> >> Date: Mon, 31 Aug 2020 21:34:46 -0500
>> >>
>> >> widgets when building with Xaw and Cairo seem to have missing text,
>> >> looking like this
>> >>
>> >> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
>> >> is reverted
>>
Eli> Thanks. I hope Yamamoto-san will be able to take a look at this.
>>
>> Putting on my 'let's simplify' hat, is this really a combination we
>> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
>> (Iʼm surprised it even builds).
Eli> I wasn't aware that it's a rare configuration. We definitely support
Eli> Lucid, right? If so, is Xaw the problem? and if it is, what are the
Eli> alternatives that are less "non-mainstream"?
Lucid + Xaw is common enough, itʼs mixing in Cairo thatʼs uncommon. To
me, Cairo pretty much implies GTK.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Sep 2020 16:50:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
> Date: Tue, 01 Sep 2020 18:13:10 +0200
>
> >> Putting on my 'let's simplify' hat, is this really a combination we
> >> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
> >> (Iʼm surprised it even builds).
>
> Eli> I wasn't aware that it's a rare configuration. We definitely support
> Eli> Lucid, right? If so, is Xaw the problem? and if it is, what are the
> Eli> alternatives that are less "non-mainstream"?
>
> Lucid + Xaw is common enough, itʼs mixing in Cairo thatʼs uncommon. To
> me, Cairo pretty much implies GTK.
Surely, given our troubled experiences with GTK, we don't want to have
it as a single toolkit supported in the Cairo build?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 02:16:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On Tue, 01 Sep 2020 11:34:46 +0900,
Pouar Dragon wrote:
>
>
> widgets when building with Xaw and Cairo seem to have missing text,
> looking like this
>
Does it also happen with the following invocations?
$ emacs -Q &
$ emacs -xrm 'Emacs.pane.menubar.font: Courier-12' &
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 07:01:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 01 Sep 2020 19:48:41 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
>> Date: Tue, 01 Sep 2020 18:13:10 +0200
>>
>> >> Putting on my 'let's simplify' hat, is this really a combination we
>> >> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
>> >> (Iʼm surprised it even builds).
>>
Eli> I wasn't aware that it's a rare configuration. We definitely support
Eli> Lucid, right? If so, is Xaw the problem? and if it is, what are the
Eli> alternatives that are less "non-mainstream"?
>>
>> Lucid + Xaw is common enough, itʼs mixing in Cairo thatʼs uncommon. To
>> me, Cairo pretty much implies GTK.
Eli> Surely, given our troubled experiences with GTK, we don't want to have
Eli> it as a single toolkit supported in the Cairo build?
I can understand that, but nobody is stepping up to e.g. make Lucid
work well on HiDPI screens, so it will become increasingly
irrelevant. Plus I donʼt see any prospect of Qt being added as a
toolkit under GNU/Linux, so GTK appears to be the only thing we've
got.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 10:25:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
RP> I can understand that, but nobody is stepping up to e.g. make Lucid
RP> work well on HiDPI screens, so it will become increasingly
RP> irrelevant.
why?
for emacs, higher dpi mostly just means larger fonts.
if images ever need scaling, that should not be hard to do in emacs
itself.
gtk is horrid. (1 was ok; it only went downhill when novel got
involved, and that trend has continued.)
and the push for hb+cxr over m17n+xft means xaw(3d) w/ cairo should
become more and more common.
(i don't use menus, but a quick test of yesyerday's master with -Q has
working menus.)
(gentoo with USE='X Xaw3d cairo harfbuzz' plus some others.)
-JimC
--
James Cloos <cloos <at> jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 10:46:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 02 Sep 2020 06:24:12 -0400, James Cloos <cloos <at> jhcloos.com> said:
>>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
RP> I can understand that, but nobody is stepping up to e.g. make Lucid
RP> work well on HiDPI screens, so it will become increasingly
RP> irrelevant.
James> why?
James> for emacs, higher dpi mostly just means larger fonts.
No it means "why canʼt I read the text in Emacs on my new HiDPI
monitor, everything else adapts automatically. What do you mean I have
to reconfigure Emacs to use larger fonts?"
James> if images ever need scaling, that should not be hard to do in emacs
James> itself.
James> gtk is horrid. (1 was ok; it only went downhill when novel got
James> involved, and that trend has continued.)
What alternative is there?
James> and the push for hb+cxr over m17n+xft means xaw(3d) w/ cairo should
James> become more and more common.
Iʼm not sure I see the connection there.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 11:39:02 GMT)
Full text and
rfc822 format available.
Message #39 received at submit <at> debbugs.gnu.org (full text, mbox):
On ti., 2020-09-01 kl. 17.05 +0200 +0200, Robert Pluim wrote:
> Putting on my 'let's simplify' hat, is this really a combination we
> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
> (Iʼm surprised it even builds).
I'm running configure on master like this:
./configure --with-x-toolkit=lucid --prefix=/not/relevant
and that gives me
What toolkit should Emacs use? LUCID
Does Emacs use -lXaw3d? yes
Does Emacs use cairo? yes
So Cairo seems to be default (and thus probably most common) when
configuring to build with Lucid?
(GTK simply doesn't work for me because I depend on daemon mode and Emacs not
crashing when a display goes away.)
...Peder...
--
Sløv uten dop
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 13:58:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
> Date: Wed, 02 Sep 2020 08:59:56 +0200
>
> >> Lucid + Xaw is common enough, itʼs mixing in Cairo thatʼs uncommon. To
> >> me, Cairo pretty much implies GTK.
>
> Eli> Surely, given our troubled experiences with GTK, we don't want to have
> Eli> it as a single toolkit supported in the Cairo build?
>
> I can understand that, but nobody is stepping up to e.g. make Lucid
> work well on HiDPI screens, so it will become increasingly
> irrelevant.
It's one thing to have a configuration bitrot because no one is
motivated and/or capable enough to maintain it. It's quite another to
decide we don't want to even try keeping that configuration alive.
I'd rather we didn't do the latter for reasons of making our lives
simpler, because it will make someone else's life less simple.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 14:06:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: James Cloos <cloos <at> jhcloos.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
> Date: Wed, 02 Sep 2020 06:24:12 -0400
>
> (i don't use menus, but a quick test of yesyerday's master with -Q has
> working menus.)
So you are saying that the OP's problem started happening only
yesterday?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 14:29:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
EZ> So you are saying that the OP's problem started happening only
EZ> yesterday?
no.
i'm saying that my current compile of master is twenty some hour old,
uses xaw3d and cairo, and that, with -Q at least, menus display.
-JimC
--
James Cloos <cloos <at> jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 14:52:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: James Cloos <cloos <at> jhcloos.com>
> Cc: rpluim <at> gmail.com, pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
> Date: Wed, 02 Sep 2020 10:28:24 -0400
>
> >>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>
> EZ> So you are saying that the OP's problem started happening only
> EZ> yesterday?
>
> no.
>
> i'm saying that my current compile of master is twenty some hour old,
> uses xaw3d and cairo, and that, with -Q at least, menus display.
Are you also using Lucid?
If so, then maybe this problem cannot be easily reproduced on every
platform in this build?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 02 Sep 2020 17:50:41 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: James Cloos <cloos <at> jhcloos.com>
>> Cc: rpluim <at> gmail.com, pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
>> Date: Wed, 02 Sep 2020 10:28:24 -0400
>>
>> >>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>>
EZ> So you are saying that the OP's problem started happening only
EZ> yesterday?
>>
>> no.
>>
>> i'm saying that my current compile of master is twenty some hour old,
>> uses xaw3d and cairo, and that, with -Q at least, menus display.
Eli> Are you also using Lucid?
I donʼt think !Lucid + xaw3d is possible, but I haven't checked.
Eli> If so, then maybe this problem cannot be easily reproduced on every
Eli> platform in this build?
Iʼve just built emacs-27 with Lucid and xaw3d, and the menus display
fine. Iʼve tried YAMAMOTO-san's suggestion about
Emacs.pane.menubar.font, but with a non-existent font, and that also
works fine.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 02 Sep 2020 15:27:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: James Cloos <cloos <at> jhcloos.com>, pouar <at> pouar.net, 43148 <at> debbugs.gnu.org
> Date: Wed, 02 Sep 2020 17:19:05 +0200
>
> Eli> Are you also using Lucid?
>
> I donʼt think !Lucid + xaw3d is possible, but I haven't checked.
That was what I knew, but I wanted to be sure I wasn't missing
anything.
> Eli> If so, then maybe this problem cannot be easily reproduced on every
> Eli> platform in this build?
>
> Iʼve just built emacs-27 with Lucid and xaw3d, and the menus display
> fine. Iʼve tried YAMAMOTO-san's suggestion about
> Emacs.pane.menubar.font, but with a non-existent font, and that also
> works fine.
So I guess the question becomes what's different with OP's system that
it doesn't work there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Thu, 03 Sep 2020 09:10:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 02 Sep 2020 13:38:12 +0200, "Peder O. Klingenberg" <peder <at> news.klingenberg.no> said:
Peder> On ti., 2020-09-01 kl. 17.05 +0200 +0200, Robert Pluim wrote:
>> Putting on my 'let's simplify' hat, is this really a combination we
>> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
>> (Iʼm surprised it even builds).
Peder> I'm running configure on master like this:
Peder> ./configure --with-x-toolkit=lucid --prefix=/not/relevant
Peder> and that gives me
Peder> What toolkit should Emacs use? LUCID
Peder> Does Emacs use -lXaw3d? yes
Peder> Does Emacs use cairo? yes
Peder> So Cairo seems to be default (and thus probably most common) when
Peder> configuring to build with Lucid?
Cairo is the default on master, whether you use GTK or Lucid, you'd
have to configure --without-cairo to not use it.
Peder> (GTK simply doesn't work for me because I depend on daemon mode and Emacs not
Peder> crashing when a display goes away.)
Hmm, thereʼs a feature/one-true-gtk
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Thu, 03 Sep 2020 09:20:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 43148 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 03 Sep 2020 11:09:29 +0200, Robert Pluim <rpluim <at> gmail.com> said:
>>>>> On Wed, 02 Sep 2020 13:38:12 +0200, "Peder O. Klingenberg" <peder <at> news.klingenberg.no> said:
Peder> On ti., 2020-09-01 kl. 17.05 +0200 +0200, Robert Pluim wrote:
>>> Putting on my 'let's simplify' hat, is this really a combination we
>>> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
>>> (Iʼm surprised it even builds).
Peder> (GTK simply doesn't work for me because I depend on daemon mode and Emacs not
Peder> crashing when a display goes away.)
What I meant to say before I rudely interrupted myself: thereʼs an
effort to have emacs use 'pure' GTK that might solve this, although
the solution could end up at 'use Wayland', which as far as I know
doesnʼt have the equivalent of X display forwarding yet, so that still
wouldnʼt solve your issue (assuming youʼre doing ssh -X or similar).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Mon, 28 Sep 2020 10:47:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 43148 <at> debbugs.gnu.org (full text, mbox):
Still invisible
YAMAMOTO Mitsuharu writes:
> On Tue, 01 Sep 2020 11:34:46 +0900,
> Pouar Dragon wrote:
>>
>>
>> widgets when building with Xaw and Cairo seem to have missing text,
>> looking like this
>>
>
> Does it also happen with the following invocations?
>
> $ emacs -Q &
> $ emacs -xrm 'Emacs.pane.menubar.font: Courier-12' &
>
> YAMAMOTO Mitsuharu
> mituharu <at> math.s.chiba-u.ac.jp
--
Pouar Dragon
My GPG Keys: https://keybase.io/pouar
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Mon, 23 Nov 2020 17:39:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> From: Pouar Dragon <pouar <at> pouar.net>
> Date: Mon, 28 Sep 2020 05:46:09 -0500
> Cc: 43148 <at> debbugs.gnu.org
>
> Still invisible
> YAMAMOTO Mitsuharu writes:
>
> > On Tue, 01 Sep 2020 11:34:46 +0900,
> > Pouar Dragon wrote:
> >>
> >>
> >> widgets when building with Xaw and Cairo seem to have missing text,
> >> looking like this
> >>
> >
> > Does it also happen with the following invocations?
> >
> > $ emacs -Q &
> > $ emacs -xrm 'Emacs.pane.menubar.font: Courier-12' &
Ping! Could we try fixing this for Emacs 27.2, please? Any proposals
for changes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Wed, 25 Nov 2020 02:31:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 43148 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Pouar Dragon <pouar <at> pouar.net>
> >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> >>
> >> widgets when building with Xaw and Cairo seem to have missing text,
> >> looking like this
> >>
> >> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
> >> is reverted
>
> Eli> Thanks. I hope Yamamoto-san will be able to take a look at this.
>
> Putting on my 'let's simplify' hat, is this really a combination we
> want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
> (Iʼm surprised it even builds).
FWIW, I've been happily using Lucid + Xaw3D for several years, and Cairo
ever since it became stable in Emacs 27 and the default configuration in
Emacs 28.
I usually have menu-bar-mode off, but like other reports in this thread,
the menus look fine when I do open them, e.g. after 'emacs -Q'.
Could the issue depend on e.g. the version of Cairo? (I seem to have an
older version than the OP.)
--
Basil
In GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2020-11-24 built on thunk
Repository revision: dea3d6aa18e54f0d8d75cd219b511bac5b3c87b1
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4'
--config-cache --prefix=/home/blc/.local --program-suffix=27
--enable-checking=yes,glyphs --enable-check-lisp-object-type
--with-x-toolkit=lucid --with-file-notification=yes --with-x
--with-cairo'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 44295 7865)
(symbols 48 6001 1)
(strings 32 16087 1428)
(string-bytes 1 510797)
(vectors 16 9271)
(vector-slots 8 125328 6416)
(floats 8 21 43)
(intervals 56 227 0)
(buffers 1000 11))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Sat, 28 Nov 2020 08:23:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On Wed, 25 Nov 2020 11:30:07 +0900,
Basil L. Contovounesios wrote:
>
> Robert Pluim <rpluim <at> gmail.com> writes:
>
> >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> >
> > >> From: Pouar Dragon <pouar <at> pouar.net>
> > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > >>
> > >> widgets when building with Xaw and Cairo seem to have missing text,
> > >> looking like this
> > >>
> > >> problem seems to go away when 5f4e8e2e088de9fb76cb631077c6eddd3219f594
> > >> is reverted
> >
> > Eli> Thanks. I hope Yamamoto-san will be able to take a look at this.
> >
> > Putting on my 'let's simplify' hat, is this really a combination we
> > want to spend time on? Lucid + Xaw + Cairo is decidedly non-mainstream
> > (Iʼm surprised it even builds).
>
> FWIW, I've been happily using Lucid + Xaw3D for several years, and Cairo
> ever since it became stable in Emacs 27 and the default configuration in
> Emacs 28.
>
> I usually have menu-bar-mode off, but like other reports in this thread,
> the menus look fine when I do open them, e.g. after 'emacs -Q'.
>
> Could the issue depend on e.g. the version of Cairo? (I seem to have an
> older version than the OP.)
Possibly. The OP seems to use cairo 1.17.3, which is not a release
version (the latest is 1.16.0) and even not the snapshot one (the
latest is 1.17.2 according to https://cairographics.org).
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Tue, 01 Dec 2020 13:11:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
> On Wed, 25 Nov 2020 11:30:07 +0900,
> Basil L. Contovounesios wrote:
> >
> > Robert Pluim <rpluim <at> gmail.com> writes:
> >
> > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > >>>>>> <eliz <at> gnu.org> said:
> > >
> > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > >>
> > > >> widgets when building with Xaw and Cairo seem to have
> > > >> missing text, looking like this
> > > >>
> > > >> problem seems to go away when
> > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is reverted
> > >
> > > Eli> Thanks. I hope Yamamoto-san will be able to take a look
> > > Eli> at this.
> > >
> > > Putting on my 'let's simplify' hat, is this really a combination
> > > we want to spend time on? Lucid + Xaw + Cairo is decidedly
> > > non-mainstream (Iʼm surprised it even builds).
> >
> > FWIW, I've been happily using Lucid + Xaw3D for several years, and
> > Cairo ever since it became stable in Emacs 27 and the default
> > configuration in Emacs 28.
> >
> > I usually have menu-bar-mode off, but like other reports in this
> > thread, the menus look fine when I do open them, e.g. after 'emacs
> > -Q'.
> >
> > Could the issue depend on e.g. the version of Cairo? (I seem to
> > have an older version than the OP.)
>
> Possibly. The OP seems to use cairo 1.17.3, which is not a release
> version (the latest is 1.16.0) and even not the snapshot one (the
> latest is 1.17.2 according to https://cairographics.org).
I experience the same issue as the OP with lucid and cairo 1.16.0,
with and without xaw3d, on Gentoo Linux. The problem goes away if I
disable cairo.
The same happens with 28.0.50, commit
1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
Configured using:
./configure […] --without-compress-install --without-hesiod
--without-pop --with-dumping=pdumper --with-file-notification=inotify
--enable-acl --with-dbus --with-modules --without-gameuser
--with-libgmp --with-gpm --with-json --without-kerberos
--without-kerberos5 --with-lcms2 --with-xml2 --without-mailutils
--without-selinux --with-gnutls --without-libsystemd --with-threads
--without-wide-int --with-zlib --with-sound=no --with-x --without-ns
--without-gconf --without-gsettings --without-toolkit-scroll-bars
--with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
--without-imagemagick --with-xft --with-cairo --with-harfbuzz
--without-libotf --without-m17n-flt --with-x-toolkit=lucid --with-xaw3d
cairo is configured using:
./configure […] --with-x --enable-tee --enable-xlib
--enable-xlib-xrender --enable-xcb --enable-xcb-shm --disable-quartz
--disable-quartz-image --disable-test-surfaces --disable-glesv2
--enable-gobject --enable-gl --disable-static --enable-svg
--disable-trace --disable-valgrind --enable-ft --enable-interpreter
--enable-pdf --enable-png --enable-ps --enable-script --disable-drm
--disable-directfb --disable-gallium --disable-qt --disable-vg
--disable-xlib-xcb
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Thu, 03 Dec 2020 02:14:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On Tue, 01 Dec 2020 22:10:32 +0900,
tastytea wrote:
>
> On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> <mituharu <at> math.s.chiba-u.ac.jp> wrote:
>
> > On Wed, 25 Nov 2020 11:30:07 +0900,
> > Basil L. Contovounesios wrote:
> > >
> > > Robert Pluim <rpluim <at> gmail.com> writes:
> > >
> > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > >>>>>> <eliz <at> gnu.org> said:
> > > >
> > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > >>
> > > > >> widgets when building with Xaw and Cairo seem to have
> > > > >> missing text, looking like this
> > > > >>
> > > > >> problem seems to go away when
> > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is reverted
> > > >
> > > > Eli> Thanks. I hope Yamamoto-san will be able to take a look
> > > > Eli> at this.
> > > >
> > > > Putting on my 'let's simplify' hat, is this really a combination
> > > > we want to spend time on? Lucid + Xaw + Cairo is decidedly
> > > > non-mainstream (Iʼm surprised it even builds).
> > >
> > > FWIW, I've been happily using Lucid + Xaw3D for several years, and
> > > Cairo ever since it became stable in Emacs 27 and the default
> > > configuration in Emacs 28.
> > >
> > > I usually have menu-bar-mode off, but like other reports in this
> > > thread, the menus look fine when I do open them, e.g. after 'emacs
> > > -Q'.
> > >
> > > Could the issue depend on e.g. the version of Cairo? (I seem to
> > > have an older version than the OP.)
> >
> > Possibly. The OP seems to use cairo 1.17.3, which is not a release
> > version (the latest is 1.16.0) and even not the snapshot one (the
> > latest is 1.17.2 according to https://cairographics.org).
>
> I experience the same issue as the OP with lucid and cairo 1.16.0,
> with and without xaw3d, on Gentoo Linux. The problem goes away if I
> disable cairo.
> The same happens with 28.0.50, commit
> 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
So, only digits are shown with "$ emacs -Q" ?
Could you show us the output of "$ fc-match -s sans" ?
I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS, and I don't
see any problems. On my side, "$ fc-match -s sans" reports Arial
Unicode.ttf at the first line.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Thu, 03 Dec 2020 08:19:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
> On Tue, 01 Dec 2020 22:10:32 +0900,
> tastytea wrote:
> >
> > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> >
> > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > Basil L. Contovounesios wrote:
> > > >
> > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > >
> > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > >>>>>> <eliz <at> gnu.org> said:
> > > > >
> > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > >>
> > > > > >> widgets when building with Xaw and Cairo seem to have
> > > > > >> missing text, looking like this
> > > > > >>
> > > > > >> problem seems to go away when
> > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is reverted
> > > > > >>
> > > > >
> > > > > Eli> Thanks. I hope Yamamoto-san will be able to take a
> > > > > Eli> look at this.
> > > > >
> > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > combination we want to spend time on? Lucid + Xaw + Cairo is
> > > > > decidedly non-mainstream (Iʼm surprised it even builds).
> > > >
> > > > FWIW, I've been happily using Lucid + Xaw3D for several years,
> > > > and Cairo ever since it became stable in Emacs 27 and the
> > > > default configuration in Emacs 28.
> > > >
> > > > I usually have menu-bar-mode off, but like other reports in this
> > > > thread, the menus look fine when I do open them, e.g. after
> > > > 'emacs -Q'.
> > > >
> > > > Could the issue depend on e.g. the version of Cairo? (I seem to
> > > > have an older version than the OP.)
> > >
> > > Possibly. The OP seems to use cairo 1.17.3, which is not a
> > > release version (the latest is 1.16.0) and even not the snapshot
> > > one (the latest is 1.17.2 according to
> > > https://cairographics.org).
> >
> > I experience the same issue as the OP with lucid and cairo 1.16.0,
> > with and without xaw3d, on Gentoo Linux. The problem goes away if I
> > disable cairo.
> > The same happens with 28.0.50, commit
> > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
>
> So, only digits are shown with "$ emacs -Q" ?
Yes, exactly like the screenshot in the first message.
> Could you show us the output of "$ fc-match -s sans" ?
>
> I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS, and I don't
> see any problems. On my side, "$ fc-match -s sans" reports Arial
> Unicode.ttf at the first line.
The list is huge, are the first 10 lines enough?
SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
luxisr.ttf: "Luxi Sans" "Regular"
l048013t.pfa: "Luxi Sans" "Regular"
n019003l.pfb: "Nimbus Sans L" "Regular"
When I saw that the first entry is an OTF font I remembered that I
configured Emacs --without-libotf, so I enabled the m17n-lib useflag
which enables --with-libotf --with-m17n-flt, but that didn't change
anything.
I also set
Emacs*font: DejaVu Sans Regular-12
in ~/.Xresources, but that didn't help either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 08:42:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On Thu, 03 Dec 2020 17:18:15 +0900,
tastytea wrote:
>
> On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
> <mituharu <at> math.s.chiba-u.ac.jp> wrote:
>
> > On Tue, 01 Dec 2020 22:10:32 +0900,
> > tastytea wrote:
> > >
> > > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > >
> > > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > > Basil L. Contovounesios wrote:
> > > > >
> > > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > > >
> > > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > > >>>>>> <eliz <at> gnu.org> said:
> > > > > >
> > > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > > >>
> > > > > > >> widgets when building with Xaw and Cairo seem to have
> > > > > > >> missing text, looking like this
> > > > > > >>
> > > > > > >> problem seems to go away when
> > > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is reverted
> > > > > > >>
> > > > > >
> > > > > > Eli> Thanks. I hope Yamamoto-san will be able to take a
> > > > > > Eli> look at this.
> > > > > >
> > > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > > combination we want to spend time on? Lucid + Xaw + Cairo is
> > > > > > decidedly non-mainstream (Iʼm surprised it even builds).
> > > > >
> > > > > FWIW, I've been happily using Lucid + Xaw3D for several years,
> > > > > and Cairo ever since it became stable in Emacs 27 and the
> > > > > default configuration in Emacs 28.
> > > > >
> > > > > I usually have menu-bar-mode off, but like other reports in this
> > > > > thread, the menus look fine when I do open them, e.g. after
> > > > > 'emacs -Q'.
> > > > >
> > > > > Could the issue depend on e.g. the version of Cairo? (I seem to
> > > > > have an older version than the OP.)
> > > >
> > > > Possibly. The OP seems to use cairo 1.17.3, which is not a
> > > > release version (the latest is 1.16.0) and even not the snapshot
> > > > one (the latest is 1.17.2 according to
> > > > https://cairographics.org).
> > >
> > > I experience the same issue as the OP with lucid and cairo 1.16.0,
> > > with and without xaw3d, on Gentoo Linux. The problem goes away if I
> > > disable cairo.
> > > The same happens with 28.0.50, commit
> > > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
> >
> > So, only digits are shown with "$ emacs -Q" ?
>
> Yes, exactly like the screenshot in the first message.
>
> > Could you show us the output of "$ fc-match -s sans" ?
> >
> > I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS, and I don't
> > see any problems. On my side, "$ fc-match -s sans" reports Arial
> > Unicode.ttf at the first line.
>
> The list is huge, are the first 10 lines enough?
>
> SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
> NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
> LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> DejaVuSans.ttf: "DejaVu Sans" "Book"
> DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
> DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
> DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
> luxisr.ttf: "Luxi Sans" "Regular"
> l048013t.pfa: "Luxi Sans" "Regular"
> n019003l.pfb: "Nimbus Sans L" "Regular"
Thanks. I conjectured Noto Color Emoji, which contains digit glyphs
but not for letter ones, would come first. But that is not the case.
I don't know why Source Sans Pro is not used then (libotf is for
handling OTF features and not necessary just for displaying).
Anyway, could you try if the following patch works?
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
diff --git a/lwlib/lwlib-utils.c b/lwlib/lwlib-utils.c
index f15cb603a8..f938b55b5a 100644
--- a/lwlib/lwlib-utils.c
+++ b/lwlib/lwlib-utils.c
@@ -161,6 +161,11 @@ crxft_font_open_name (Display *dpy, int screen, const char *name)
/ DisplayHeightMM (dpy, screen));
FcPatternAddDouble (pattern, FC_DPI, dpi);
}
+#ifdef FC_COLOR
+ FcBool color_p;
+ if (FcPatternGetBool (pattern, FC_COLOR, 0, &color_p) == FcResultNoMatch)
+ FcPatternAddBool (pattern, FC_COLOR, FcFalse);
+#endif
FcDefaultSubstitute (pattern);
cairo_font_face_t *font_face
= cairo_ft_font_face_create_for_pattern (pattern);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 43148 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2020-12-04 17:41+0900 YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
> On Thu, 03 Dec 2020 17:18:15 +0900,
> tastytea wrote:
> >
> > On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
> > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> >
> > > On Tue, 01 Dec 2020 22:10:32 +0900,
> > > tastytea wrote:
> > > >
> > > > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > >
> > > > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > > > Basil L. Contovounesios wrote:
> > > > > >
> > > > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > > > >
> > > > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > > > >>>>>> <eliz <at> gnu.org> said:
> > > > > > >
> > > > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > > > >>
> > > > > > > >> widgets when building with Xaw and Cairo seem to
> > > > > > > >> have missing text, looking like this
> > > > > > > >>
> > > > > > > >> problem seems to go away when
> > > > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is
> > > > > > > >> reverted
> > > > > > >
> > > > > > > Eli> Thanks. I hope Yamamoto-san will be able to
> > > > > > > Eli> take a look at this.
> > > > > > >
> > > > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > > > combination we want to spend time on? Lucid + Xaw + Cairo
> > > > > > > is decidedly non-mainstream (Iʼm surprised it even
> > > > > > > builds).
> > > > > >
> > > > > > FWIW, I've been happily using Lucid + Xaw3D for several
> > > > > > years, and Cairo ever since it became stable in Emacs 27
> > > > > > and the default configuration in Emacs 28.
> > > > > >
> > > > > > I usually have menu-bar-mode off, but like other reports in
> > > > > > this thread, the menus look fine when I do open them, e.g.
> > > > > > after 'emacs -Q'.
> > > > > >
> > > > > > Could the issue depend on e.g. the version of Cairo? (I
> > > > > > seem to have an older version than the OP.)
> > > > >
> > > > > Possibly. The OP seems to use cairo 1.17.3, which is not a
> > > > > release version (the latest is 1.16.0) and even not the
> > > > > snapshot one (the latest is 1.17.2 according to
> > > > > https://cairographics.org).
> > > >
> > > > I experience the same issue as the OP with lucid and cairo
> > > > 1.16.0, with and without xaw3d, on Gentoo Linux. The problem
> > > > goes away if I disable cairo.
> > > > The same happens with 28.0.50, commit
> > > > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
> > >
> > > So, only digits are shown with "$ emacs -Q" ?
> >
> > Yes, exactly like the screenshot in the first message.
> >
> > > Could you show us the output of "$ fc-match -s sans" ?
> > >
> > > I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS, and I
> > > don't see any problems. On my side, "$ fc-match -s sans" reports
> > > Arial Unicode.ttf at the first line.
> >
> > The list is huge, are the first 10 lines enough?
> >
> > SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
> > NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
> > LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> > DejaVuSans.ttf: "DejaVu Sans" "Book"
> > DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
> > DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
> > DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
> > luxisr.ttf: "Luxi Sans" "Regular"
> > l048013t.pfa: "Luxi Sans" "Regular"
> > n019003l.pfb: "Nimbus Sans L" "Regular"
>
> Thanks. I conjectured Noto Color Emoji, which contains digit glyphs
> but not for letter ones, would come first. But that is not the case.
> I don't know why Source Sans Pro is not used then (libotf is for
> handling OTF features and not necessary just for displaying).
>
> Anyway, could you try if the following patch works?
With the patch I get rectangles instead of letters.
I removed Noto Color Emoji from my font configuration in
~/.config/fontconfig/fonts.conf and that did the trick. The menus are
showing text now with and without the patch. But I have no idea why,
all other programs work fine with that configuration:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!-- Prefer Noto's Color Emoji Font -->
<alias>
<family>serif</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
<alias>
<family>sans-serif</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
<!-- Set default fonts -->
<alias>
<family>monospace</family>
<prefer>
<family>Source Code Pro</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>Source Serif Pro</family>
</prefer>
</alias>
<alias>
<family>sans-serif</family>
<prefer>
<family>Source Sans Pro</family>
</prefer>
</alias>
</fontconfig>
[emacs_screenshot_lucid_rectangles.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 09:49:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 43148 <at> debbugs.gnu.org (full text, mbox):
tastytea via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> With the patch I get rectangles instead of letters.
>
> I removed Noto Color Emoji from my font configuration in
> ~/.config/fontconfig/fonts.conf and that did the trick. The menus are
> showing text now with and without the patch. But I have no idea why,
> all other programs work fine with that configuration:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
> <!-- Prefer Noto's Color Emoji Font -->
> <alias>
> <family>serif</family>
> <prefer>
> <family>Noto Color Emoji</family>
> </prefer>
> </alias>
If youʼre trying to say "I want to use Noto Color Emoji for emojis",
then I think you should write
<family>emoji</family>
not "serif" and "sans-serif", as Noto Color Emoji doesnʼt cover the
usual codepoints that are used for text.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 10:10:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-12-04 10:48+0100 Robert Pluim <rpluim <at> gmail.com> wrote:
> tastytea via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > With the patch I get rectangles instead of letters.
> >
> > I removed Noto Color Emoji from my font configuration in
> > ~/.config/fontconfig/fonts.conf and that did the trick. The menus
> > are showing text now with and without the patch. But I have no idea
> > why, all other programs work fine with that configuration:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> > <fontconfig>
> > <!-- Prefer Noto's Color Emoji Font -->
> > <alias>
> > <family>serif</family>
> > <prefer>
> > <family>Noto Color Emoji</family>
> > </prefer>
> > </alias>
>
> If youʼre trying to say "I want to use Noto Color Emoji for emojis",
> then I think you should write
>
> <family>emoji</family>
That doesn't work, at least not in my terminal emulator.
> not "serif" and "sans-serif", as Noto Color Emoji doesnʼt cover the
> usual codepoints that are used for text.
All the tutorials on the internet say to write it in "serif",
"sans-serif" and "monospace". If the first font (Source Sans Pro in my
case) doesn't cover the codepoint, the next font is used (Noto Color
Emoji).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 10:34:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 43148 <at> debbugs.gnu.org (full text, mbox):
tastytea <tastytea <at> tastytea.de> writes:
>> If youʼre trying to say "I want to use Noto Color Emoji for emojis",
>> then I think you should write
>>
>> <family>emoji</family>
>
> That doesn't work, at least not in my terminal emulator.
>
You want emojis in your terminal emulator? I guess thereʼs no
accounting for taste :-)
>> not "serif" and "sans-serif", as Noto Color Emoji doesnʼt cover the
>> usual codepoints that are used for text.
>
> All the tutorials on the internet say to write it in "serif",
> "sans-serif" and "monospace". If the first font (Source Sans Pro in my
> case) doesn't cover the codepoint, the next font is used (Noto Color
> Emoji).
That surprises me, but then again this is fontconfig. Last time I
checked, Noto Color Emoji was already in the default fontconfig
settings, at least on Debian, so I wonder why you needed to have your
local settings.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 10:59:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-12-04 11:33+0100 Robert Pluim <rpluim <at> gmail.com> wrote:
> tastytea <tastytea <at> tastytea.de> writes:
>
> >> If youʼre trying to say "I want to use Noto Color Emoji for
> >> emojis", then I think you should write
> >>
> >> <family>emoji</family>
> >
> > That doesn't work, at least not in my terminal emulator.
> >
>
> You want emojis in your terminal emulator? I guess thereʼs no
> accounting for taste :-)
It's not just the terminal emulator, that was just the quickest to
check. Qt programs require these settings too. Gtk programs work
without it for some reason.
> >> not "serif" and "sans-serif", as Noto Color Emoji doesnʼt cover the
> >> usual codepoints that are used for text.
> >
> > All the tutorials on the internet say to write it in "serif",
> > "sans-serif" and "monospace". If the first font (Source Sans Pro in
> > my case) doesn't cover the codepoint, the next font is used (Noto
> > Color Emoji).
>
> That surprises me, but then again this is fontconfig. Last time I
> checked, Noto Color Emoji was already in the default fontconfig
> settings, at least on Debian, so I wonder why you needed to have your
> local settings.
It is in the settings, just not high enough in the list.
My point is that my approach seems to be the recommended way to reorder
the font list, and all other programs work fine with it.
Emacs uses the font with the highest priority in the preferred list, as
expected, unless “Noto Color Emoji” or “Noto Emoji” is in that list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 11:47:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 43148 <at> debbugs.gnu.org (full text, mbox):
tastytea via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> My point is that my approach seems to be the recommended way to reorder
> the font list, and all other programs work fine with it.
> Emacs uses the font with the highest priority in the preferred list, as
> expected, unless “Noto Color Emoji” or “Noto Emoji” is in that list.
And emacs compiled with Gtk rather than Lucid behaves how?
Robbert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Fri, 04 Dec 2020 12:16:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-12-04 12:46+0100 Robert Pluim <rpluim <at> gmail.com> wrote:
> tastytea via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > My point is that my approach seems to be the recommended way to
> > reorder the font list, and all other programs work fine with it.
> > Emacs uses the font with the highest priority in the preferred
> > list, as expected, unless “Noto Color Emoji” or “Noto Emoji” is in
> > that list.
>
> And emacs compiled with Gtk rather than Lucid behaves how?
It uses the right font with Gtk.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Sat, 05 Dec 2020 06:52:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On Fri, 04 Dec 2020 18:28:24 +0900,
tastytea wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> On 2020-12-04 17:41+0900 YAMAMOTO Mitsuharu
> <mituharu <at> math.s.chiba-u.ac.jp> wrote:
>
> > On Thu, 03 Dec 2020 17:18:15 +0900,
> > tastytea wrote:
> > >
> > > On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
> > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > >
> > > > On Tue, 01 Dec 2020 22:10:32 +0900,
> > > > tastytea wrote:
> > > > >
> > > > > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > > >
> > > > > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > > > > Basil L. Contovounesios wrote:
> > > > > > >
> > > > > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > > > > >
> > > > > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > > > > >>>>>> <eliz <at> gnu.org> said:
> > > > > > > >
> > > > > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > > > > >>
> > > > > > > > >> widgets when building with Xaw and Cairo seem to
> > > > > > > > >> have missing text, looking like this
> > > > > > > > >>
> > > > > > > > >> problem seems to go away when
> > > > > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is
> > > > > > > > >> reverted
> > > > > > > >
> > > > > > > > Eli> Thanks. I hope Yamamoto-san will be able to
> > > > > > > > Eli> take a look at this.
> > > > > > > >
> > > > > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > > > > combination we want to spend time on? Lucid + Xaw + Cairo
> > > > > > > > is decidedly non-mainstream (Iʼm surprised it even
> > > > > > > > builds).
> > > > > > >
> > > > > > > FWIW, I've been happily using Lucid + Xaw3D for several
> > > > > > > years, and Cairo ever since it became stable in Emacs 27
> > > > > > > and the default configuration in Emacs 28.
> > > > > > >
> > > > > > > I usually have menu-bar-mode off, but like other reports in
> > > > > > > this thread, the menus look fine when I do open them, e.g.
> > > > > > > after 'emacs -Q'.
> > > > > > >
> > > > > > > Could the issue depend on e.g. the version of Cairo? (I
> > > > > > > seem to have an older version than the OP.)
> > > > > >
> > > > > > Possibly. The OP seems to use cairo 1.17.3, which is not a
> > > > > > release version (the latest is 1.16.0) and even not the
> > > > > > snapshot one (the latest is 1.17.2 according to
> > > > > > https://cairographics.org).
> > > > >
> > > > > I experience the same issue as the OP with lucid and cairo
> > > > > 1.16.0, with and without xaw3d, on Gentoo Linux. The problem
> > > > > goes away if I disable cairo.
> > > > > The same happens with 28.0.50, commit
> > > > > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
> > > >
> > > > So, only digits are shown with "$ emacs -Q" ?
> > >
> > > Yes, exactly like the screenshot in the first message.
> > >
> > > > Could you show us the output of "$ fc-match -s sans" ?
> > > >
> > > > I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS, and I
> > > > don't see any problems. On my side, "$ fc-match -s sans" reports
> > > > Arial Unicode.ttf at the first line.
> > >
> > > The list is huge, are the first 10 lines enough?
> > >
> > > SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
> > > NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
> > > LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> > > DejaVuSans.ttf: "DejaVu Sans" "Book"
> > > DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
> > > DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
> > > DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
> > > luxisr.ttf: "Luxi Sans" "Regular"
> > > l048013t.pfa: "Luxi Sans" "Regular"
> > > n019003l.pfb: "Nimbus Sans L" "Regular"
> >
> > Thanks. I conjectured Noto Color Emoji, which contains digit glyphs
> > but not for letter ones, would come first. But that is not the case.
> > I don't know why Source Sans Pro is not used then (libotf is for
> > handling OTF features and not necessary just for displaying).
> >
> > Anyway, could you try if the following patch works?
>
> With the patch I get rectangles instead of letters.
>
> I removed Noto Color Emoji from my font configuration in
> ~/.config/fontconfig/fonts.conf and that did the trick. The menus are
> showing text now with and without the patch. But I have no idea why,
> all other programs work fine with that configuration:
I could reproduce the problem with your configuration.
Could you try the patch below?
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
diff --git a/lwlib/lwlib-utils.c b/lwlib/lwlib-utils.c
index f15cb603a8..2b3aa55c3e 100644
--- a/lwlib/lwlib-utils.c
+++ b/lwlib/lwlib-utils.c
@@ -148,6 +148,7 @@ XtWidgetBeingDestroyedP (Widget widget)
crxft_font_open_name (Display *dpy, int screen, const char *name)
{
XftFont *pub = NULL;
+ FcPattern *match = NULL;
FcPattern *pattern = FcNameParse ((FcChar8 *) name);
if (pattern)
{
@@ -162,12 +163,18 @@ crxft_font_open_name (Display *dpy, int screen, const char *name)
FcPatternAddDouble (pattern, FC_DPI, dpi);
}
FcDefaultSubstitute (pattern);
+ FcResult result;
+ match = FcFontMatch (NULL, pattern, &result);
+ FcPatternDestroy (pattern);
+ }
+ if (match)
+ {
cairo_font_face_t *font_face
- = cairo_ft_font_face_create_for_pattern (pattern);
+ = cairo_ft_font_face_create_for_pattern (match);
if (font_face)
{
double pixel_size;
- if ((FcPatternGetDouble (pattern, FC_PIXEL_SIZE, 0, &pixel_size)
+ if ((FcPatternGetDouble (match, FC_PIXEL_SIZE, 0, &pixel_size)
!= FcResultMatch)
|| pixel_size < 1)
pixel_size = 10;
@@ -177,7 +184,7 @@ crxft_font_open_name (Display *dpy, int screen, const char *name)
cairo_matrix_init_scale (&font_matrix, pixel_size, pixel_size);
cairo_matrix_init_identity (&ctm);
cairo_font_options_t *options = cairo_font_options_create ();
- cairo_ft_font_options_substitute (options, pattern);
+ cairo_ft_font_options_substitute (options, match);
pub->scaled_font = cairo_scaled_font_create (font_face, &font_matrix,
&ctm, options);
cairo_font_face_destroy (font_face);
@@ -190,7 +197,7 @@ crxft_font_open_name (Display *dpy, int screen, const char *name)
pub->height = lround (extents.height);
pub->max_advance_width = lround (extents.max_x_advance);
}
- FcPatternDestroy (pattern);
+ FcPatternDestroy (match);
}
if (pub && pub->height <= 0)
{
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Sat, 05 Dec 2020 07:15:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 43148 <at> debbugs.gnu.org (full text, mbox):
On 2020-12-05 15:51+0900 YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
> On Fri, 04 Dec 2020 18:28:24 +0900,
> tastytea wrote:
> >
> > [1 <text/plain; UTF-8 (quoted-printable)>]
> > On 2020-12-04 17:41+0900 YAMAMOTO Mitsuharu
> > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> >
> > > On Thu, 03 Dec 2020 17:18:15 +0900,
> > > tastytea wrote:
> > > >
> > > > On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
> > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > >
> > > > > On Tue, 01 Dec 2020 22:10:32 +0900,
> > > > > tastytea wrote:
> > > > > >
> > > > > > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > > > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > > > >
> > > > > > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > > > > > Basil L. Contovounesios wrote:
> > > > > > > >
> > > > > > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > > > > > >
> > > > > > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > > > > > >>>>>> <eliz <at> gnu.org> said:
> > > > > > > > >
> > > > > > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > > > > > >>
> > > > > > > > > >> widgets when building with Xaw and Cairo seem
> > > > > > > > > >> to have missing text, looking like this
> > > > > > > > > >>
> > > > > > > > > >> problem seems to go away when
> > > > > > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is
> > > > > > > > > >> reverted
> > > > > > > > >
> > > > > > > > > Eli> Thanks. I hope Yamamoto-san will be able to
> > > > > > > > > Eli> take a look at this.
> > > > > > > > >
> > > > > > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > > > > > combination we want to spend time on? Lucid + Xaw +
> > > > > > > > > Cairo is decidedly non-mainstream (Iʼm surprised it
> > > > > > > > > even builds).
> > > > > > > >
> > > > > > > > FWIW, I've been happily using Lucid + Xaw3D for several
> > > > > > > > years, and Cairo ever since it became stable in Emacs 27
> > > > > > > > and the default configuration in Emacs 28.
> > > > > > > >
> > > > > > > > I usually have menu-bar-mode off, but like other
> > > > > > > > reports in this thread, the menus look fine when I do
> > > > > > > > open them, e.g. after 'emacs -Q'.
> > > > > > > >
> > > > > > > > Could the issue depend on e.g. the version of Cairo? (I
> > > > > > > > seem to have an older version than the OP.)
> > > > > > >
> > > > > > > Possibly. The OP seems to use cairo 1.17.3, which is not
> > > > > > > a release version (the latest is 1.16.0) and even not the
> > > > > > > snapshot one (the latest is 1.17.2 according to
> > > > > > > https://cairographics.org).
> > > > > >
> > > > > > I experience the same issue as the OP with lucid and cairo
> > > > > > 1.16.0, with and without xaw3d, on Gentoo Linux. The problem
> > > > > > goes away if I disable cairo.
> > > > > > The same happens with 28.0.50, commit
> > > > > > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
> > > > >
> > > > > So, only digits are shown with "$ emacs -Q" ?
> > > >
> > > > Yes, exactly like the screenshot in the first message.
> > > >
> > > > > Could you show us the output of "$ fc-match -s sans" ?
> > > > >
> > > > > I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS,
> > > > > and I don't see any problems. On my side, "$ fc-match -s
> > > > > sans" reports Arial Unicode.ttf at the first line.
> > > >
> > > > The list is huge, are the first 10 lines enough?
> > > >
> > > > SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
> > > > NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
> > > > LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> > > > DejaVuSans.ttf: "DejaVu Sans" "Book"
> > > > DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
> > > > DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
> > > > DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
> > > > luxisr.ttf: "Luxi Sans" "Regular"
> > > > l048013t.pfa: "Luxi Sans" "Regular"
> > > > n019003l.pfb: "Nimbus Sans L" "Regular"
> > >
> > > Thanks. I conjectured Noto Color Emoji, which contains digit
> > > glyphs but not for letter ones, would come first. But that is
> > > not the case. I don't know why Source Sans Pro is not used then
> > > (libotf is for handling OTF features and not necessary just for
> > > displaying).
> > >
> > > Anyway, could you try if the following patch works?
> >
> > With the patch I get rectangles instead of letters.
> >
> > I removed Noto Color Emoji from my font configuration in
> > ~/.config/fontconfig/fonts.conf and that did the trick. The menus
> > are showing text now with and without the patch. But I have no idea
> > why, all other programs work fine with that configuration:
>
> I could reproduce the problem with your configuration.
> Could you try the patch below?
Yes! Thanks, that worked. :-)
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
You have taken responsibility.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pouar Dragon <pouar <at> pouar.net>:
bug acknowledged by developer.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 43148-done <at> debbugs.gnu.org (full text, mbox):
On Sat, 05 Dec 2020 16:14:21 +0900,
tastytea wrote:
>
> On 2020-12-05 15:51+0900 YAMAMOTO Mitsuharu
> <mituharu <at> math.s.chiba-u.ac.jp> wrote:
>
> > On Fri, 04 Dec 2020 18:28:24 +0900,
> > tastytea wrote:
> > >
> > > [1 <text/plain; UTF-8 (quoted-printable)>]
> > > On 2020-12-04 17:41+0900 YAMAMOTO Mitsuharu
> > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > >
> > > > On Thu, 03 Dec 2020 17:18:15 +0900,
> > > > tastytea wrote:
> > > > >
> > > > > On 2020-12-03 11:13+0900 YAMAMOTO Mitsuharu
> > > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > > >
> > > > > > On Tue, 01 Dec 2020 22:10:32 +0900,
> > > > > > tastytea wrote:
> > > > > > >
> > > > > > > On 2020-11-28 17:22+0900 YAMAMOTO Mitsuharu
> > > > > > > <mituharu <at> math.s.chiba-u.ac.jp> wrote:
> > > > > > >
> > > > > > > > On Wed, 25 Nov 2020 11:30:07 +0900,
> > > > > > > > Basil L. Contovounesios wrote:
> > > > > > > > >
> > > > > > > > > Robert Pluim <rpluim <at> gmail.com> writes:
> > > > > > > > >
> > > > > > > > > >>>>>> On Tue, 01 Sep 2020 17:09:18 +0300, Eli Zaretskii
> > > > > > > > > >>>>>> <eliz <at> gnu.org> said:
> > > > > > > > > >
> > > > > > > > > > >> From: Pouar Dragon <pouar <at> pouar.net>
> > > > > > > > > > >> Date: Mon, 31 Aug 2020 21:34:46 -0500
> > > > > > > > > > >>
> > > > > > > > > > >> widgets when building with Xaw and Cairo seem
> > > > > > > > > > >> to have missing text, looking like this
> > > > > > > > > > >>
> > > > > > > > > > >> problem seems to go away when
> > > > > > > > > > >> 5f4e8e2e088de9fb76cb631077c6eddd3219f594 is
> > > > > > > > > > >> reverted
> > > > > > > > > >
> > > > > > > > > > Eli> Thanks. I hope Yamamoto-san will be able to
> > > > > > > > > > Eli> take a look at this.
> > > > > > > > > >
> > > > > > > > > > Putting on my 'let's simplify' hat, is this really a
> > > > > > > > > > combination we want to spend time on? Lucid + Xaw +
> > > > > > > > > > Cairo is decidedly non-mainstream (Iʼm surprised it
> > > > > > > > > > even builds).
> > > > > > > > >
> > > > > > > > > FWIW, I've been happily using Lucid + Xaw3D for several
> > > > > > > > > years, and Cairo ever since it became stable in Emacs 27
> > > > > > > > > and the default configuration in Emacs 28.
> > > > > > > > >
> > > > > > > > > I usually have menu-bar-mode off, but like other
> > > > > > > > > reports in this thread, the menus look fine when I do
> > > > > > > > > open them, e.g. after 'emacs -Q'.
> > > > > > > > >
> > > > > > > > > Could the issue depend on e.g. the version of Cairo? (I
> > > > > > > > > seem to have an older version than the OP.)
> > > > > > > >
> > > > > > > > Possibly. The OP seems to use cairo 1.17.3, which is not
> > > > > > > > a release version (the latest is 1.16.0) and even not the
> > > > > > > > snapshot one (the latest is 1.17.2 according to
> > > > > > > > https://cairographics.org).
> > > > > > >
> > > > > > > I experience the same issue as the OP with lucid and cairo
> > > > > > > 1.16.0, with and without xaw3d, on Gentoo Linux. The problem
> > > > > > > goes away if I disable cairo.
> > > > > > > The same happens with 28.0.50, commit
> > > > > > > 1a3aa6043a51e5bb4007889dd7dcabb55dc44132.
> > > > > >
> > > > > > So, only digits are shown with "$ emacs -Q" ?
> > > > >
> > > > > Yes, exactly like the screenshot in the first message.
> > > > >
> > > > > > Could you show us the output of "$ fc-match -s sans" ?
> > > > > >
> > > > > > I tried the latest snapshot cairo 1.17.4 on XQuartz/macOS,
> > > > > > and I don't see any problems. On my side, "$ fc-match -s
> > > > > > sans" reports Arial Unicode.ttf at the first line.
> > > > >
> > > > > The list is huge, are the first 10 lines enough?
> > > > >
> > > > > SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
> > > > > NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
> > > > > LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> > > > > DejaVuSans.ttf: "DejaVu Sans" "Book"
> > > > > DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
> > > > > DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
> > > > > DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
> > > > > luxisr.ttf: "Luxi Sans" "Regular"
> > > > > l048013t.pfa: "Luxi Sans" "Regular"
> > > > > n019003l.pfb: "Nimbus Sans L" "Regular"
> > > >
> > > > Thanks. I conjectured Noto Color Emoji, which contains digit
> > > > glyphs but not for letter ones, would come first. But that is
> > > > not the case. I don't know why Source Sans Pro is not used then
> > > > (libotf is for handling OTF features and not necessary just for
> > > > displaying).
> > > >
> > > > Anyway, could you try if the following patch works?
> > >
> > > With the patch I get rectangles instead of letters.
> > >
> > > I removed Noto Color Emoji from my font configuration in
> > > ~/.config/fontconfig/fonts.conf and that did the trick. The menus
> > > are showing text now with and without the patch. But I have no idea
> > > why, all other programs work fine with that configuration:
> >
> > I could reproduce the problem with your configuration.
> > Could you try the patch below?
>
> Yes! Thanks, that worked. :-)
Thanks for testing. I've pushed it to the emacs-27 branch. Closing
the bug.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
You have taken responsibility.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pouar Dragon <pouar <at> pouar.net>:
bug acknowledged by developer.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
You have taken responsibility.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pouar Dragon <pouar <at> pouar.net>:
bug acknowledged by developer.
(Sun, 06 Dec 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43148; Package
emacs.
(Sun, 06 Dec 2020 05:59:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 43148 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 06 Dec 2020 14:26:17 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 43148-done <at> debbugs.gnu.org,
> Robert Pluim <rpluim <at> gmail.com>, Pouar Dragon <pouar <at> pouar.net>
>
> Thanks for testing. I've pushed it to the emacs-27 branch. Closing
> the bug.
Thanks for fixing this regression.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 03 Jan 2021 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.