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#30226: Fixing it->pixel_width / it->current_x when tabs and line numbers. Date: Sat, 27 Jan 2018 16:56:05 +0200 Message-ID: <83bmhfjqpm.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1517064931 5933 195.159.176.226 (27 Jan 2018 14:55:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Jan 2018 14:55:31 +0000 (UTC) Cc: 30226@debbugs.gnu.org To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 27 15:55:27 2018 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 1efRsr-0000G1-II for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jan 2018 15:55:09 +0100 Original-Received: from localhost ([::1]:52812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efRus-0002IH-8p for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jan 2018 09:57:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efRuj-0002H7-Jv for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 09:57:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efRug-0003Zi-EI for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 09:57:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37420) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1efRug-0003ZJ-9j for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 09:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1efRug-0004fD-27 for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 09:57: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: Sat, 27 Jan 2018 14:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30226 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30226-submit@debbugs.gnu.org id=B30226.151706497717865 (code B ref 30226); Sat, 27 Jan 2018 14:57:02 +0000 Original-Received: (at 30226) by debbugs.gnu.org; 27 Jan 2018 14:56:17 +0000 Original-Received: from localhost ([127.0.0.1]:45317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efRtw-0004e5-P3 for submit@debbugs.gnu.org; Sat, 27 Jan 2018 09:56:17 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efRtu-0004ds-R3 for 30226@debbugs.gnu.org; Sat, 27 Jan 2018 09:56:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efRtl-0002wr-JS for 30226@debbugs.gnu.org; Sat, 27 Jan 2018 09:56:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efRtl-0002wj-Fd; Sat, 27 Jan 2018 09:56:05 -0500 Original-Received: from [176.228.60.248] (port=3394 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1efRtk-0003bl-3Q; Sat, 27 Jan 2018 09:56:04 -0500 In-reply-to: (message from Keith David Bershatsky on Mon, 22 Jan 2018 23:52:20 -0800) 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:142585 Archived-At: > Date: Mon, 22 Jan 2018 23:52:20 -0800 > From: Keith David Bershatsky > > Here is a revised patch that removes an erroneous section that was experimental. Thanks, but I'm unable to reproduce the original problem, so I cannot yet discuss the reasons, let alone the solution. Here's what I did in Emacs built from the current emacs-26 branch: 1) Inserted the following snippet into *scratch*: (setq display-line-numbers t) (setq buffer-display-table (make-display-table)) (aset buffer-display-table ?\t (vector (make-glyph-code ?\u00BB 'font-lock-warning-face) (make-glyph-code ?\t 'highlight))) (setq tab-width 8) 2) Evaluated it ("M-x eval-region RET"). 3) Went to the end of the buffer, inserted a few empty lines, then went up 2 lines from EOB, and typed "C-q TAB Hello-world" 4) Typed "M-x dump-glyph-row RET" The result is this data shown on stderr: Row Start End Used oE><\CTZFesm X Y W H V A P ============================================================================== 11 409 422 18 010000100000 0 176 192 16 16 12 12 -1 -1 0 -1 -1 -1 -1 Glyph# Type Pos O W Code C Face LR 0 C -1 0 8 0x000020 20 00 1 C -1 0 8 0x000031 1 20 00 2 C -1 0 8 0x000032 2 20 00 3 C -1 0 8 0x000020 20 00 4 C 409 B 8 0x0000bb . 23 00 5 S 409 B 56 0x000000 22 00 <<<<<<<<<<<<<<<<<< 6 C 410 B 8 0x000048 H 0 00 7 C 411 B 8 0x000065 e 0 00 8 C 412 B 8 0x00006c l 0 00 9 C 413 B 8 0x00006c l 0 00 10 C 414 B 8 0x00006f o 0 00 11 C 415 B 8 0x00002d - 0 00 12 C 416 B 8 0x000077 w 0 00 13 C 417 B 8 0x00006f o 0 00 14 C 418 B 8 0x000072 r 0 00 15 C 419 B 8 0x00006c l 0 00 16 C 420 B 8 0x000064 d 0 00 17 C 0 0 8 0x000020 0 00 This is as expected: the width of the default font is 8, and the size of the stretch glyph #5 is 8x8 = 56, as expected. Next, I typed "M-: (scroll-left 1) RET" and again invoked dump-glyph-row. The result: Row Start End Used oE><\CTZFesm X Y W H V A P ============================================================================== 11 409 422 17 011000100000 0 176 176 16 16 12 12 -1 -1 0 -1 -1 -1 -1 Glyph# Type Pos O W Code C Face LR 0 C -1 0 8 0x000020 20 00 1 C -1 0 8 0x000031 1 20 00 2 C -1 0 8 0x000032 2 20 00 3 C -1 0 8 0x000020 20 00 4 S 409 B 48 0x000000 22 00 <<<<<<<<<<<<<< 5 C 410 B 8 0x000048 H 0 00 6 C 411 B 8 0x000065 e 0 00 7 C 412 B 8 0x00006c l 0 00 8 C 413 B 8 0x00006c l 0 00 9 C 414 B 8 0x00006f o 0 00 10 C 415 B 8 0x00002d - 0 00 11 C 416 B 8 0x000077 w 0 00 12 C 417 B 8 0x00006f o 0 00 13 C 418 B 8 0x000072 r 0 00 14 C 419 B 8 0x00006c l 0 00 15 C 420 B 8 0x000064 d 0 00 16 C 0 0 8 0x000020 0 00 Note that the glyph corresponding to the u+00BB character now disappeared from display, and therefore the stretch glyph is #4, its width is 48 -- again, as expected. I then typed "M-: (scroll-left 1) RET" once more, followed by dump-glyph-row, and the results are: Row Start End Used oE><\CTZFesm X Y W H V A P ============================================================================== 11 409 422 17 011000100000 0 176 168 16 16 12 12 -1 -1 0 -1 -1 -1 -1 Glyph# Type Pos O W Code C Face LR 0 C -1 0 8 0x000020 20 00 1 C -1 0 8 0x000031 1 20 00 2 C -1 0 8 0x000032 2 20 00 3 C -1 0 8 0x000020 20 00 4 S 409 B 40 0x000000 22 00 <<<<<<<<<<<<< 5 C 410 B 8 0x000048 H 0 00 6 C 411 B 8 0x000065 e 0 00 7 C 412 B 8 0x00006c l 0 00 8 C 413 B 8 0x00006c l 0 00 9 C 414 B 8 0x00006f o 0 00 10 C 415 B 8 0x00002d - 0 00 11 C 416 B 8 0x000077 w 0 00 12 C 417 B 8 0x00006f o 0 00 13 C 418 B 8 0x000072 r 0 00 14 C 419 B 8 0x00006c l 0 00 15 C 420 B 8 0x000064 d 0 00 16 C 0 0 8 0x000020 0 00 Now the stretch glyph's width is 40 pixels, again as expected. So the width of the stretch glyph is computed correctly. And your screenshots also show similar results, where the width of the stretch glyph is decremented for each call to scroll-left. Your problem description talks about it->pixel_width, not about glyph->pixel_width, but the latter should be equal to the former, because x_produce_glyphs does this when it finishes computing the width of the stretch glyph: if (it->glyph_row) { append_stretch_glyph (it, it->object, it->pixel_width, it->ascent + it->descent, it->ascent); and the function append_stretch_glyph then assigns the value of its 3rd argument to glyph->pixel_width: static void append_stretch_glyph (struct it *it, Lisp_Object object, int width, int height, int ascent) { ... glyph->pixel_width = clip_to_bounds (-1, width, SHRT_MAX); So I'm not sure why you are saying there's a bug in the display code regarding it->pixel_width of the stretch glyphs that represent TAB characters. You say: > In a nutshell, it->pixel_width and it->current_x are both incorrect in that situation. Because the X is wrong, all subsequent references to it->current_x on the same line are also wrong. I don't understand why you are saying that it->current_x is wrong. What is that assertion based on? Maybe there's some misunderstanding of what current_x is and relative to what position does it measure the X coordinate. Can you tell what you expected current_x to be in some specific situation (i.e., specific horizontal scroll of the display in the above scenario), and what you really found?