bug#7426: 23.2; term.el: After running stty -opost, printing \n\r inserts trailing spaces

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

Chong Yidong <cyd@stupidchicken.com> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> term-vertical-motion expands to vertical-motion and it's that call that
>> results in the spaces being inserted in the buffer.
>>
>> I worked around the issue by removing, after-the-fact, spaces inserted
>> by the (vertical-motion 0) call.  A more efficient solution would be to
>> prevent vertical-motion from inserting the spaces in the first place,
>> but that happens deep within Emacs somewhere.  I'm hoping a terminal
>> expert can suggest where to look.
>
> That's strange.  vertical-motion should not affect the buffer contents;
> it only moves point.

I did some more tracing and it's not vertical-motion.  Here's a
simplified test case:

/*
  M-x term
  (Run program: /bin/bash)
  RET
  C-c M-x eval-expression
  (setq show-trailing-whitespace t)
  $ gcc -o term-trailing-spaces term-trailing-spaces.c
  $ stty -opost
  $ ./term-trailing-spaces
  (trailing spaces shown in red)
  $ stty opost
  $ ./term-trailing-spaces
  (no trailing spaces)
*/

#include <stdio.h>

int main (int argc, char* argv[])
{
  printf ("\n");
  return 0;
}

With stty -opost, the new test case produces (dots represent spaces):

$ ./term-trailing-spaces
........................
........................$.

That matches gnome-terminal's visual output for the same test.  I can't
tell if it uses spaces to produce that output.

I can eliminate the trailing spaces with this change:

Index: term.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/term.el,v
retrieving revision 1.115
diff -u -r1.115 term.el
--- term.el	13 Mar 2009 01:43:03 -0000	1.115
+++ term.el	20 Nov 2010 23:28:57 -0000
@@ -2619,7 +2619,7 @@
     (save-excursion
       (end-of-line)
       (setq point-at-eol (point)))
-    (move-to-column term-current-column t)
+    (move-to-column term-current-column)
     ;; If move-to-column extends the current line it will use the face
     ;; from the last character on the line, set the face for the chars
     ;; to default.

But then the output is:

$ ./term-trailing-spaces

$.

which doesn't match gnome-terminal visually, so I don't think that's a
correct solution.

When the terminal is in char mode the trailing spaces don't affect
input.  When the terminal is in line mode, input problems happen as a
result of the trailing spaces.

I think the reason it's a problem is explained in the
term-pending-delete-marker comment:

(defvar term-pending-delete-marker) ;; New user input in line mode needs to
;;		be deleted, because it gets echoed by the inferior.
;;		To reduce flicker, we defer the delete until the next output.

Maybe the correct solution is whenever (move-to-column ... t) is called
in line mode, term-pending-delete-marker needs to be used to delete the
extra spaces.