GNU bug report logs -
#64440
30.0.50; [PATCH] Highlight on non toolkit menu bar items
Previous Next
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
Message #43 received at 64440 <at> debbugs.gnu.org (full text, mbox):
> 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 14:32:39 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> + *x_end = *x_start;
> >> + for (i = *h_start; i < *h_end; ++i)
> >> + *x_end += row->glyphs[TEXT_AREA][i].pixel_width;
> >>
> >> Here, I convert those limits from chars to pixels.
> >
> > What does this glyph_row look like? Does it include several strings
> > one after the other or something?
> >
> > In general, we always test the index of a glyph in a glyph row against
> > glyphs[TEXT_AREA].used, and I'm worried that these tests are absent
> > from the code above. Which is why I'm asking for more details about
> > the arrangement of the menu text in these glyph rows.
>
> Hi,
>
> Here's what a "p *row" returns right after the "row = MATRIX_ROW
> (w->current_matrix, *vpos);" line:
>
> (gdb) p *row
> $9 = {
> glyphs = {0xef4a19dd000, 0xef4a19dd000, 0xef4a19e0510, 0xef4a19e0510},
> used = {0, 120, 0, 0},
> hash = 221095522,
> x = 0,
> y = 0,
> pixel_width = 840,
> ascent = 11,
> height = 13,
> phys_ascent = 10,
> phys_height = 12,
> visible_height = 13,
> extra_line_spacing = 0,
> start = {
> pos = {
> charpos = 0,
> bytepos = 0
> },
> overlay_string_index = 0,
> string_pos = {
> charpos = 0,
> bytepos = 0
> },
> dpvec_index = 0
> },
> end = {
> pos = {
> charpos = 0,
> bytepos = 0
> },
> overlay_string_index = 0,
> string_pos = {
> charpos = 0,
> bytepos = 0
> },
> dpvec_index = 0
> },
> minpos = {
> charpos = 0,
> bytepos = 0
> },
> maxpos = {
> charpos = 0,
> bytepos = 0
> },
> overlay_arrow_bitmap = 0,
> left_user_fringe_bitmap = 0,
> right_user_fringe_bitmap = 0,
> left_fringe_bitmap = 0,
> right_fringe_bitmap = 0,
> left_user_fringe_face_id = 0,
> right_user_fringe_face_id = 0,
> left_fringe_face_id = 0,
> right_fringe_face_id = 0,
> left_fringe_offset = 0,
> right_fringe_offset = 0,
> fringe_bitmap_periodic_p = false,
> redraw_fringe_bitmaps_p = false,
> enabled_p = true,
> truncated_on_left_p = false,
> truncated_on_right_p = false,
> continued_p = false,
> displays_text_p = false,
> ends_at_zv_p = false,
> fill_line_p = false,
> indicate_empty_line_p = false,
> contains_overlapping_glyphs_p = false,
> full_width_p = true,
> mode_line_p = false,
> tab_line_p = false,
> overlapped_p = false,
> ends_in_middle_of_char_p = false,
> starts_in_middle_of_char_p = false,
> overlapping_p = false,
> mouse_face_p = false,
> ends_in_newline_from_string_p = false,
> exact_window_width_line_p = false,
> cursor_in_fringe_p = false,
> ends_in_ellipsis_p = false,
> indicate_bob_p = false,
> indicate_top_line_p = false,
> indicate_eob_p = false,
> indicate_bottom_line_p = false,
> reversed_p = false,
> stipple_p = false,
> continuation_lines_width = 0,
> clip = 0x0
> }
>
> 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?
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.