GNU bug report logs - #30584
Tab stretches vanish when horizontal scrolling.

Previous Next

Full log

View this message in rfc822 format

From: Keith David Bershatsky <esq <at> lawlist.com>
To: 30584 <at> debbugs.gnu.org
Subject: bug#30584: Tab stretches vanish when horizontal scrolling.
Date: Thu, 22 Feb 2018 14:42:56 -0800

Step 1.  Launch Emacs 26 from the terminal so that we can observe STDERR messages when dumping the glyph row.

Step 2.  Switch to the *scratch* buffer.

Step 3.  Evaluate the following Lisp code:

    (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)))

Step 4.  On a new line, type:  C-q TAB C-q TAB Hello-world.

Step 5.  Evaluate:  (scroll-left 2)

Step 6.  M-x dump-glyph-row

We observe that the _second_ tab STRETCH, which was visible immediately _before_ Step 5, is now missing.  We see that the tab STRETCH that is missing has a dump glyph row width of -1.  If we were to look at the value of it.pixel_width, it would be equal to negative the value of a regular width character; i.e., -7.

[The same behavior would exist if there were more than two visible tab STRETCH on the same line; i.e., only the first tab STRETCH remains visible and all subsequent tab STRETCH disappear from view and take on a negative pixel width.]

EXPECTED BEHAVIOR:  The _second_ tab STRETCH should not disappear from view and it should maintain its full width unless and until it starts horizontally scrolling out of view should the user decide to increase the amount of horizontal scrolling.

On a related issue, this particular bug complicates resolving problems described in bug#30226.  For example, move_it_in_display_line_to does not want to stop on the character immediately following the negative tab STRETCH that disappeared from view (the subsequent character gets skipped over).  My current programmatic workaround involves modifying move_it_in_display_line_to by forcing IT to essentially stop ....  I'll submit a separate status report to the bug#30226 tracking number in the near future once I do some more testing.  Inasmuch as this current bug of the tab STRETCH disappearing stands on its own two feet and is easy to reproduce, I believe that it should have its own separate tracking number.

Row     Start       End Used oE><\CTZFesm     X    Y    W    H    V    A    P
==============================================================================
 10       400       414   20 111000110000     0  160  160   16   16   12   12
           -1        -1	    0
           -1        -1
           -1        -1
 Glyph#  Type       Pos   O   W     Code      C Face LR
      0     C        -1   0   7 0x000020          26 00
      1     C        -1   0   7 0x000031      1   26 00
      2     C        -1   0   7 0x000031      1   26 00
      3     C        -1   0   7 0x000020          26 00
      4     S       400   B  35 0x000000          28 00
      5     C       401   B   7 0x0000bb      .   29 00
      6     S       401   B  -1 0x000000          28 00
      7     C       402   B   7 0x000048      H    0 00
      8     C       403   B   7 0x000065      e    0 00
      9     C       404   B   7 0x00006c      l    0 00
     10     C       405   B   7 0x00006c      l    0 00
     11     C       406   B   7 0x00006f      o    0 00
     12     C       407   B   7 0x00002d      -    0 00
     13     C       408   B   7 0x000077      w    0 00
     14     C       409   B   7 0x00006f      o    0 00
     15     C       410   B   7 0x000072      r    0 00
     16     C       411   B   7 0x00006c      l    0 00
     17     C       412   B   7 0x000064      d    0 00
     18     C       413   B   7 0x00002e      .    0 00
     19     C         0   0   7 0x000020           0 00

Thanks,

Keith

Previous Next

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