bug#17974: 24.3.92; scrolled wrapped tab starts with wrong position

[Eli Zaretskii]

> Date: Wed, 09 Jul 2014 08:44:41 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> 1. $ emacs -Q -D &
> 2. (setq frame-resize-pixelwise t) C-j
> 3. C-x 5 2
> 4. (progn
>      (text-scale-set 5)
>      (dotimes (i 10) (insert (make-string 7 (+ ?a i)) ?\t))
>      (insert ?\n)) C-j
> 5. Resize the newly created frame so it looks like the first
>    screenshot.  Notice that there is some space before "fffffff"
> 6. Type "(scroll-up 1)" and repeatedly hit "C-x C-e" until the line
>    starting with "fffffff" comes at the top.
> 
> Result:
> 
> The line starting with "fffffff" is shown without leading space (the
> second screenshot) whereas there was some space before the last scroll
> up.

This is not a bug, but rather an explicitly coded feature: tab stops
in a continued line are calculated from the beginning of the visible
portion of the (physical) line, and tab stops the distance to which
appears narrower than the font's space glyph are skipped (i.e. the
display engine goes to the next tab stop).

Scroll commands force window-start to be at a certain buffer position,
in this case in the middle of a continued line.  The portion of the
line before window-start is not displayed, and its tab stops are not
counted, which changes the position of the tab stops in the visible
portion of the line.  (Going back to the beginning of a long line for
the purpose of taking into account the tab stops there would be a
performance killer, especially in very long lines.)

This situation is relatively rare, because for most "normal-sized"
fonts the probability of a tab stop to be spilled to the next line
with less pixels than a space glyph is very small.