From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#29627: 25.3; x-show-tip does not display text when x-gtk-use-tooltips is nil and left/right-margin-width is set Date: Sun, 10 Dec 2017 16:08:30 +0200 Message-ID: <83k1xuu141.fsf@gnu.org> References: <83shcju0kv.fsf@gnu.org> <5A2D03EB.1070007@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512914952 21680 195.159.176.226 (10 Dec 2017 14:09:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 14:09:12 +0000 (UTC) Cc: 29627@debbugs.gnu.org, terlar@gmail.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 10 15:09:02 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eO2Ht-00059v-MO for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Dec 2017 15:09:01 +0100 Original-Received: from localhost ([::1]:44840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eO2I0-0006Sx-JM for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Dec 2017 09:09:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eO2Hv-0006Sq-16 for bug-gnu-emacs@gnu.org; Sun, 10 Dec 2017 09:09:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eO2Ht-00084o-Uc for bug-gnu-emacs@gnu.org; Sun, 10 Dec 2017 09:09:02 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45935) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eO2Ht-00084Z-Qf for bug-gnu-emacs@gnu.org; Sun, 10 Dec 2017 09:09:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eO2Ht-00050i-IP for bug-gnu-emacs@gnu.org; Sun, 10 Dec 2017 09:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Dec 2017 14:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29627-submit@debbugs.gnu.org id=B29627.151291493819250 (code B ref 29627); Sun, 10 Dec 2017 14:09:01 +0000 Original-Received: (at 29627) by debbugs.gnu.org; 10 Dec 2017 14:08:58 +0000 Original-Received: from localhost ([127.0.0.1]:54616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eO2Hq-00050Q-3b for submit@debbugs.gnu.org; Sun, 10 Dec 2017 09:08:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eO2Ho-00050B-NV for 29627@debbugs.gnu.org; Sun, 10 Dec 2017 09:08:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eO2Hi-0007rN-CU for 29627@debbugs.gnu.org; Sun, 10 Dec 2017 09:08:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eO2He-0007np-6B; Sun, 10 Dec 2017 09:08:46 -0500 Original-Received: from [176.228.60.248] (port=1939 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eO2Hd-000676-IP; Sun, 10 Dec 2017 09:08:45 -0500 In-reply-to: <5A2D03EB.1070007@gmx.at> (message from martin rudalics on Sun, 10 Dec 2017 10:52:43 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:140895 Archived-At: > Date: Sun, 10 Dec 2017 10:52:43 +0100 > From: martin rudalics > > > Thanks, fixed on the emacs-26 branch. > > Could you please tell why such a harsh treatment was necessary? In > particular why (1) showing the margins initially failed and (2) instead > of just forcing the window margins have zero width you made the window a > pseudo-window. First, I didn't make the window a pseudo-window; it was always a pseudo-window. The line w->pseudo_window_p = true; existed in x-show-tip ever since Emacs 21. I didn't feel comfortable with changing that now, certainly not on the release branch. The bug happened because pseudo-windows cannot have display margins, an assumption that is in the display code all over the place. Here's a typical example: static void frame_to_window_pixel_xy (struct window *w, int *x, int *y) { if (w->pseudo_window_p) { /* A pseudo-window is always full-width, and starts at the left edge of the frame, plus a frame border. */ struct frame *f = XFRAME (w->frame); *x -= FRAME_INTERNAL_BORDER_WIDTH (f); *y = FRAME_TO_WINDOW_PIXEL_Y (w, *y); } The actual root cause for this bug was that update_marginal_area, when does this: output_cursor_to (w, vpos, 0, desired_row->y, 0); if (desired_row->used[area]) rif->write_glyphs (w, updated_row, desired_row->glyphs[area], area, desired_row->used[area]); rif->clear_end_of_line (w, updated_row, area, -1); which in case in point avoided calling the write_glyphs method when called for area = RIGHT_MARGIN_AREA (because the 'used' count is of course zero). That left the output cursor at the beginning of the glyph row, and then clear_end_of_line method cleared the text which was already displayed, because of this snippet: from_x = w->output_cursor.x; /* Translate to frame coordinates. */ if (updated_row->full_width_p) { from_x = WINDOW_TO_FRAME_PIXEL_X (w, from_x); to_x = WINDOW_TO_FRAME_PIXEL_X (w, to_x); } else { int area_left = window_box_left (w, updated_area); from_x += area_left; to_x += area_left; } And you will see that window_box_left does this for pseudo-windows: if (w->pseudo_window_p) return FRAME_INTERNAL_BORDER_WIDTH (f); which is just another example of the above-mentioned assumption about pseudo-windows being margin-less. So from_x remained (almost) zero, unlike in normal windows, and the already displayed text was deleted. For some reason that I cannot identify, and don't really care about, the original recipe did work until Emacs 24.3. But it could only work by sheer luck, or maybe something else was preventing the window of the tooltip frame to acquire display margins. I just made this official with my changes, that's all. As for why I forced the tip buffer have zero margins, instead of doing the same with the window in which that buffer is displayed, then: . why does it matter? the buffer is a temporary buffer generated specifically for showing the tip text; . I thought doing that with the window is more complex, what with all the different ways one can affect a window's parameters Having said all that, if you see problem(s) caused by my change, please describe them; I'm not married to the fix I pushed.