Subject: bug#17974: closed (Re: bug#17974: 24.3.92; scrolled wrapped tab starts with wrong position)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 09 Jul 2014 14:17:03 +0000

Your bug report

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

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 [email-masked].

-- 
17974: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17974
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#17974: 24.3.92; scrolled wrapped tab starts with wrong position
From: Eli Zaretskii <[email-masked]>
To: YAMAMOTO Mitsuharu <[email-masked]>
Cc: [email-masked]
Date: Wed, 09 Jul 2014 17:16:17 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Date: Wed, 09 Jul 2014 08:44:41 +0900
> From: YAMAMOTO Mitsuharu <[email-masked]>
> 
> 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.

Subject: 24.3.92; scrolled wrapped tab starts with wrong position
From: YAMAMOTO Mitsuharu <[email-masked]>
To: [email-masked]
Date: Wed, 09 Jul 2014 08:44:41 +0900
List-Id: <debbugs-submit.debbugs.gnu.org>

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
				[email-masked]

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 [email-masked]
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'