From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16691: 24.3.50; emacs_backtrace.txt Date: Mon, 10 Feb 2014 19:42:46 +0200 Message-ID: <83wqh2uand.fsf@gnu.org> References: <83a9e1wg93.fsf@gnu.org> <52F68E36.7070204@gmx.at> <83zjm1uz1g.fsf@gnu.org> <52F760B0.6050003@gmx.at> <83lhxkuu3x.fsf@gnu.org> <52F7CFC4.2030905@gmx.at> <83fvnsujgc.fsf@gnu.org> <52F88A69.3060104@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392054253 30162 80.91.229.3 (10 Feb 2014 17:44:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2014 17:44:13 +0000 (UTC) Cc: 16691@debbugs.gnu.org, lekktu@gmail.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 10 18:44:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WCuu1-0006Su-DO for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Feb 2014 18:44:17 +0100 Original-Received: from localhost ([::1]:57046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCuu1-00018B-2N for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Feb 2014 12:44:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCutr-00016j-QX for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2014 12:44:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCutn-0007Ep-9H for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2014 12:44:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCutn-0007Ek-5P for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2014 12:44:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WCutm-0004oM-Nn for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2014 12:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16691 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 16691-submit@debbugs.gnu.org id=B16691.139205419418427 (code B ref 16691); Mon, 10 Feb 2014 17:44:02 +0000 Original-Received: (at 16691) by debbugs.gnu.org; 10 Feb 2014 17:43:14 +0000 Original-Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCusw-0004n5-Nq for submit@debbugs.gnu.org; Mon, 10 Feb 2014 12:43:14 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:39709) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCust-0004ma-UJ for 16691@debbugs.gnu.org; Mon, 10 Feb 2014 12:43:09 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N0S00K00JRBDL00@mtaout24.012.net.il> for 16691@debbugs.gnu.org; Mon, 10 Feb 2014 19:42:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0S00FIGJU77250@mtaout24.012.net.il>; Mon, 10 Feb 2014 19:42:07 +0200 (IST) In-reply-to: <52F88A69.3060104@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85286 Archived-At: > Date: Mon, 10 Feb 2014 09:14:33 +0100 > From: martin rudalics > CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@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.