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

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

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

I'm not sure if this should be counted as a bug.  This is not a
serious one, but causes a strange look in pixel-based smooth scrolling
a window with scaled text in the Mac port.  The recipe below can also
be reproduced in various X11 builds.  Probably this is related to
Bug#17969.

Steps to reproduce:

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.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

In GNU Emacs 24.3.92.1 (x86_64-apple-darwin13.2.0, GTK+ Version 3.12.2)
 of 2014-07-09 on YAMAMOTO-no-iMac.local
Repository revision: 117365 monnier@iro.umontreal.ca-20140708183807-3hfyv6otyq5tgxcj
Windowing system distributor `The X.Org Foundation', version 11.0.11406000
Configured using:
 `configure --without-imagemagick LDFLAGS=-L/opt/local/lib
 CPPFLAGS=-I/opt/local/include'

[-- Attachment #2: wrapped-tab.png --]
[-- Type: image/png, Size: 44864 bytes --]

[-- Attachment #3: wrapped-tab-scrolled.png --]
[-- Type: image/png, Size: 33797 bytes --]

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.