GNU bug report logs - #5117
23.1.50; Weird display when wrap-prefix contains tabs

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 5117 in the body.
You can then email your comments to 5117 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Matthew Dempsky <matthew <at> dempsky.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Thu, 3 Dec 2009 14:06:26 -0800

Here's the contents of `foo.el':

    (require 'cl)
    (with-output-to-temp-buffer "bonk"
      (with-current-buffer standard-output
        (loop for i from 1 to 100 do
              (insert (make-string (+ (random 5) 3) ?x) " "))
        (visual-line-mode)
        (setq wrap-prefix "\t")))

If I run `Emacs -Q foo.el' and then `M-x eval-buffer', it creates a new
buffer "demo", but instead of each continuation line being consistently
indented by 8 spaces, they're each randomly indented between 1 and 8
spaces.

The issue appears to be due to the expansion of tabs being related to
the actual current column rather than the visual current column.
Literal tabs within a wrapped paragraph exhibit similar behavior.

This additionally sometimes confuses `visual-line-mode's line motion
keys.


In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-12-02 on admins-macbook-pro-2.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns' '--without-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x e v a l - b u f f e r <return> M-` h s

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow mail-extr message ecomplete rfc822 mml mml-sec password-cache
mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045
qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash
mail-utils emacsbug sendmail regexp-opt tmm electric help-mode view cl
cl-19 tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)

Message #10 received at 5117 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Matthew Dempsky <matthew <at> dempsky.org>
To: 5117 <at> debbugs.gnu.org
Subject: Re: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Thu, 3 Dec 2009 14:38:20 -0800

This patch seems to correct the behavior:

--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -21380,7 +21380,7 @@ x_produce_glyphs (it)
 	  if (font->space_width > 0)
 	    {
 	      int tab_width = it->tab_width * font->space_width;
-	      int x = it->current_x + it->continuation_lines_width;
+	      int x = it->current_x;
 	      int next_tab_x = ((1 + x + tab_width - 1) / tab_width) * tab_width;

 	      /* If the distance from the current position to the next tab

Message #15 received at 5117 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Matthew Dempsky <matthew <at> dempsky.org>
Cc: 5117 <at> debbugs.gnu.org
Subject: Re: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Sat, 05 Dec 2009 16:14:52 -0500

> This patch seems to correct the behavior:
>
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -21380,7 +21380,7 @@ x_produce_glyphs (it)
>  	  if (font->space_width > 0)
>  	    {
>  	      int tab_width = it->tab_width * font->space_width;
> -	      int x = it->current_x + it->continuation_lines_width;
> +	      int x = it->current_x;
>  	      int next_tab_x = ((1 + x + tab_width - 1) / tab_width) * tab_width;
>
>  	      /* If the distance from the current position to the next tab

The "+ it->continuation_lines_width" was added for a reason.  IIRC, it
is so that continued lines containing tabs are displayed correctly.

Message #20 received at 5117 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Matthew Dempsky <matthew <at> dempsky.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5117 <at> debbugs.gnu.org
Subject: Re: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Sat, 5 Dec 2009 16:36:19 -0800

On Sat, Dec 5, 2009 at 1:14 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> The "+ it->continuation_lines_width" was added for a reason.

I tracked back through the history of the code, and that part has been
there since the code was introduced as far as I can tell.

> IIRC, it is so that continued lines containing tabs are displayed correctly.

Can you define "correctly"?  When I remove the addition, it displays
'correctly' from what I expect: a tab always indents the text to the
next visual column that's a multiple of 8.

The current behavior ensures that the same tab always expands to the
same number of space characters regardless of where the line wraps,
but I don't see any reason why this behavior is desirable in the
presence of `word-wrap'.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Matthew Dempsky <matthew <at> dempsky.org>
Cc: 5117 <at> debbugs.gnu.org
Subject: Re: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Fri, 01 Jan 2010 13:35:59 -0500

> > The "+ it->continuation_lines_width" was added for a reason.
>
> I tracked back through the history of the code, and that part has been
> there since the code was introduced as far as I can tell.
>
> > IIRC, it is so that continued lines containing tabs are displayed correctly.
>
> Can you define "correctly"?  When I remove the addition, it displays
> 'correctly' from what I expect: a tab always indents the text to the
> next visual column that's a multiple of 8.

Sorry for the delay in replying.

Suppose that (i) next tab stop is 3 characters off the right edge of the
text area, and (ii) you have text going all the way to the right edge.
Now insert a tab character.  With the current code, Emacs displays the
tab up to the 3rd character of the continuation line.  This is
"correct", in the sense that the continuation line is a "continuation"
of the previous line with the tab stops picking up where they left off.

With the patch you propose, Emacs would instead display up to the 8th
character of the continuation line.

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5117 <at> debbugs.gnu.org
Subject: Re: bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs
Date: Sat, 09 Jul 2016 09:11:04 -0400

Chong Yidong <cyd <at> stupidchicken.com> writes:

>> > The "+ it->continuation_lines_width" was added for a reason.
>>
>> I tracked back through the history of the code, and that part has been
>> there since the code was introduced as far as I can tell.
>>
>> > IIRC, it is so that continued lines containing tabs are displayed correctly.
>>
>> Can you define "correctly"?  When I remove the addition, it displays
>> 'correctly' from what I expect: a tab always indents the text to the
>> next visual column that's a multiple of 8.
>
> Sorry for the delay in replying.
>
> Suppose that (i) next tab stop is 3 characters off the right edge of the
> text area, and (ii) you have text going all the way to the right edge.
> Now insert a tab character.  With the current code, Emacs displays the
> tab up to the 3rd character of the continuation line.  This is
> "correct", in the sense that the continuation line is a "continuation"
> of the previous line with the tab stops picking up where they left off.
>
> With the patch you propose, Emacs would instead display up to the 8th
> character of the continuation line.

Since it seems that this is (according to Chong) not a bug, but the way
things should work, I' m going to close this bug.  Feel free to
disagree; we can always re-open it.

Previous Next

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