--- Begin Message ---
|
Subject: |
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#30584: Tab stretches vanish when horizontal scrolling. |
|
Date: |
Wed, 07 Mar 2018 20:45:08 +0200 |
> Date: Thu, 22 Feb 2018 14:42:56 -0800
> From: Keith David Bershatsky <address@hidden>
>
> 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.
--- End Message ---