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

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16660 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>, 16691 <at> debbugs.gnu.org, drew.adams <at> oracle.com, lekktu <at> gmail.com
Subject: bug#16691: 24.3.50; emacs_backtrace.txt
Date: Sat, 26 Dec 2015 14:26:32 +0100

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

>> Date: Mon, 10 Feb 2014 19:35:25 +0100
>> From: martin rudalics <rudalics <at> gmx.at>
>> CC: lekktu <at> gmail.com, drew.adams <at> oracle.com, 16691 <at> debbugs.gnu.org
>> 
>>  > If you meant row->y, then it is used in many different places,
>>  > including the display back-end,
>> 
>> Where is the display back-end?  If it's update_window
>
> It is _called_ by update_window.  In update_text_area, you will see
> the calls to rif->write_glyphs, which eventually calls the back-end
> (xterm.c, w32term.c, term.c, etc.).
>
>> we there set
>> 
>>        yb = window_text_bottom_y (w);
>> 
>> and then
>> 
>> 	  mode_line_row->y = yb;
>> 
>> so any prior notion of that row's y is lost.  And for the header line we
>> do
>> 
>> 	  header_line_row->y = 0;
>> 
>> But this still doesn't use row->y.  Where is the backend that uses
>> row->y to determine where on the screen to draw that row?
>
> Are you talking only about the mode line and the header line?  If so,
> then yes, those rows don't need the y coordinate, as they "know" where
> it is in advance.
>
> I thought you were asking a more general question about row->x and
> row->y.

It's unclear what the situation in this bug report is, or who is waiting
for more info from whom.  :-)  Is this still an issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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