GNU bug report logs - #17974
24.3.92; scrolled wrapped tab starts with wrong position

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17974 in the body.
You can then email your comments to 17974 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.92; scrolled wrapped tab starts with wrong position
Date: Wed, 09 Jul 2014 08:44:41 +0900

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> 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'

[wrapped-tab.png (image/png, inline)]

[wrapped-tab-scrolled.png (image/png, inline)]

Message #12 received at 17974-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 17974-done <at> debbugs.gnu.org
Subject: Re: bug#17974: 24.3.92;
 scrolled wrapped tab starts with wrong position
Date: Wed, 09 Jul 2014 17:16:17 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.