GNU bug report logs - #64440
30.0.50; [PATCH] Highlight on non toolkit menu bar items

Previous Next

Package: emacs;

Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>

Date: Mon, 3 Jul 2023 16:00:02 UTC

Severity: wishlist

Tags: patch

Found in version 30.0.50

Done: Po Lu <luangruo <at> yahoo.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: luangruo <at> yahoo.com, stefankangas <at> gmail.com, 64440 <at> debbugs.gnu.org
Subject: bug#64440: 30.0.50; [PATCH] Highlight on non toolkit menu bar items
Date: Mon, 11 Sep 2023 18:58:39 +0300
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: luangruo <at> yahoo.com,  stefankangas <at> gmail.com,  64440 <at> debbugs.gnu.org
> Date: Mon, 11 Sep 2023 16:59:11 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> [...]
> 
> >> Is that what you are looking for?
> >
> > This gives some of the answers, but the command 'pgrow' (defined on
> > src/.gdbinit) would have done that better, and would also show the
> > glyphs themselves.  Can you show what 'pgrow' produces in this case?
> 
> Here is what I get:
> 
> (gdb) pgrow
> TEXT: 120 glyphs
>   0    0: CHAR[F] str=0x66f834da[0] blev=0,btyp=L w=7 a+d=11+2 face=10
>   1    7: CHAR[i] str=0x66f834da[1] blev=0,btyp=L w=7 a+d=11+2 face=10
>   2   14: CHAR[l] str=0x66f834da[2] blev=0,btyp=L w=7 a+d=11+2 face=10
>   3   21: CHAR[e] str=0x66f834da[3] blev=0,btyp=L w=7 a+d=11+2 face=10
>   4   28: CHAR[ ] str=0x66f834da[-1] blev=0,btyp=B w=7 a+d=11+2 face=10
>   5   35: CHAR[E] str=0x66fede1c[0] blev=0,btyp=L w=7 a+d=11+2 face=10
>   6   42: CHAR[d] str=0x66fede1c[1] blev=0,btyp=L w=7 a+d=11+2 face=10
>   7   49: CHAR[i] str=0x66fede1c[2] blev=0,btyp=L w=7 a+d=11+2 face=10
>   8   56: CHAR[t] str=0x66fede1c[3] blev=0,btyp=L w=7 a+d=11+2 face=10
>   9   63: CHAR[ ] str=0x66fede1c[-1] blev=0,btyp=B w=7 a+d=11+2 face=10

Thanks.  That's what I imagined we have there.  So I guess considering
that a string ends where is SCHARS end is reasonable.

But note that the above means you could also detect where each item
ends by looking for the glyph whose string position is -1.  So maybe
add an assertion there that the glyph after the last character has its
position as -1, in case we could have some complications there with
double-width characters or something.




This bug report was last modified 1 year and 207 days ago.

Previous Next


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