GNU bug report logs -
#30584
Tab stretches vanish when horizontal scrolling.
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#30584: Tab stretches vanish when horizontal scrolling.
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 30584 <at> debbugs.gnu.org.
--
30584: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30584
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> Date: Thu, 22 Feb 2018 14:42:56 -0800
> From: Keith David Bershatsky <esq <at> 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.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 7 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.