GNU bug report logs - #16691
24.3.50; emacs_backtrace.txt

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sat, 8 Feb 2014 17:32:02 UTC

Severity: normal

Tags: moreinfo

Merged with 16660, 16918

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

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: martin rudalics <rudalics <at> gmx.at>
Cc: 16691 <at> debbugs.gnu.org, lekktu <at> gmail.com, drew.adams <at> oracle.com
Subject: bug#16691: 24.3.50; emacs_backtrace.txt
Date: Mon, 10 Feb 2014 19:42:46 +0200
> Date: Mon, 10 Feb 2014 09:14:33 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, drew.adams <at> oracle.com, 16691 <at> debbugs.gnu.org
> 
>  >> - int x, y: Where and how are these set for a particular row (including
>  >>    header- and mode-line) and when and how are these eventually consumed?
>  >>    This is the greatest mystery for me so far.
>  >
>  > They are assigned in display_line and display_string.  Examples from
>  > display_line:
>  >
>  >   row->y = it->current_y;
> 
> Does the value set here account for extra_line_spacing or is the latter
> (as I presume) handled separately?

The y-coordinate of the row does include the extra_line_spacing, it
must.  More accurately, the next row gets its y coordinate increased
due to extra line spacing of the previous row.

We calculate the value inside PRODUCE_GLYPHS (which expands into a
call to x_produce_glyphs in a GUI session), and then enlarge
it->descent by the computed value.  Then display_line, which calls
PRODUCE_GLYPHS, copies these values from 'struct it' to the glyph row,
updates row->height accordingly, and uses row->height to increment
row->y when it advances to the next row (see near the end of
display_line).

>  >   [...]
>  >   if (it->current_x - it->pixel_width < it->first_visible_x)
>  >     row->x = x - it->first_visible_x;
>  >
>  > Mode line and header line are generated from strings, so look in
>  > display_mode_line and display_string.
> 
> I tried that but never found anything useful there.  I suppose the
> header line has current_y always set to 0.  But the mode line?

The magic hides in init_iterator, which is called by display_mode_line:

  /* Use one of the mode line rows of W's desired matrix if
     appropriate.  */
  if (row == NULL)
    {
      if (base_face_id == MODE_LINE_FACE_ID
	  || base_face_id == MODE_LINE_INACTIVE_FACE_ID)
	row = MATRIX_MODE_LINE_ROW (w->desired_matrix);
      else if (base_face_id == HEADER_LINE_FACE_ID)
	row = MATRIX_HEADER_LINE_ROW (w->desired_matrix);
    }

IOW, we rely on the fact that the header line is always the first row,
and the mode line is the last one.

>  > Not sure what you mean by "consumed".  Consumed by whom and for what
>  > purposes?
> 
> I suppose when exposing the window (another part of Emacs display which
> I don't understand yet).  What would current_y else be used for?

Why are we suddenly talking about current_y?  There's no such member
in the glyph_row structure.

If you meant row->y, then it is used in many different places,
including the display back-end, various redisplay optimizations (which
compare rows of current and desired matrices), functions that find
buffer/string positions that correspond to a mouse click, and move_it_*
functions which simulate display, to name just a few.

If you meant something else, please elaborate.




This bug report was last modified 9 years and 148 days ago.

Previous Next


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