bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Matthew Dempsky]

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)

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Matthew Dempsky]

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

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Chong Yidong]

> 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.

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Matthew Dempsky]

On Sat, Dec 5, 2009 at 1:14 PM, Chong Yidong <cyd@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'.

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Chong Yidong]

> > 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.

bug#5117: 23.1.50; Weird display when wrap-prefix contains tabs

[Andrew Hyatt]

Chong Yidong <cyd@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.