all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#30584: Tab stretches vanish when horizontal scrolling.
@ 2018-02-22 22:42 Keith David Bershatsky
  2018-03-07 18:45 ` Eli Zaretskii
  0 siblings, 1 reply; 2+ messages in thread
From: Keith David Bershatsky @ 2018-02-22 22:42 UTC (permalink / raw)
  To: 30584

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





^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#30584: Tab stretches vanish when horizontal scrolling.
  2018-02-22 22:42 bug#30584: Tab stretches vanish when horizontal scrolling Keith David Bershatsky
@ 2018-03-07 18:45 ` Eli Zaretskii
  0 siblings, 0 replies; 2+ messages in thread
From: Eli Zaretskii @ 2018-03-07 18:45 UTC (permalink / raw)
  To: Keith David Bershatsky; +Cc: 30584-done

> Date: Thu, 22 Feb 2018 14:42:56 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> 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.

Thanks, should be fixed now on the master branch.





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-03-07 18:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-22 22:42 bug#30584: Tab stretches vanish when horizontal scrolling Keith David Bershatsky
2018-03-07 18:45 ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.