comint-carriage-motion causes severe problems.

[Luc Teirlinck]

I do not know what problem(s) comint-carriage-motion is supposed to fix.
I use ielm extensively and M-x run-lisp and M-x shell frequently.  I have
never experienced any problems in Emacs20.7 before this function was 
introduced, but started experiencing plenty of them in Emacs21.

(remove-hook 'comint-output-filter-functions 'comint-carriage-motion) 

makes all these problems disappear and does not seem to introduce any
new ones.

The worst problems occur in ielm. (See the run below.)  In my own
usage of ielm, they are so bad that ielm is totally unusable without
executing the above line of code.  Trying to compile a function will
mess up the syntax badly and mess up everything unless one takes
specific action to manually correct the syntax situation.  Playing
around with any type of code involving key bindings or keyboard macros
just keeps printing out the wrong results and keeps messing up the
syntax, which has to be continuously manually corrected.  In fact any
string containing ^H or ^M characters causes trouble.  Similar results
occur in other comint applications as well, although the problem is
less acute there for the simple reason that strings containing ^H or
^M occur less often there than in ielm.

I believe that at the very least this function should be removed from
ielm.  I do not believe that there is really any reason to have
comint-output-filter-functions mess around with the string returned by
pp-to-string.  If there would be, then there would be something wrong
with pp-to-string.

Whether it has a place in other comint applications depends on the
severity of the problems it is supposed to fix.  I looked at old bug
reports posted around the time this function was introduced and the
only thing I could find was a posting concerning ls --color, which
seemed to be a problem specific to telnet-filter, not a general comint
problem.  I know programs which, when ran from a shell-buffer will
intersperse their output with repeats and ^H's.  However,
comint-carriage-motion makes these problems worse rather than solving
them.  Without the function, the output looks ugly, but is
readable. With the function, the output is unrecognizable.

Again, I am not necessarily saying that this function is a mistake
for all comint applications (although I definitely believe it is for
ielm).  It all depends on the severity of the problems it fixes and
whether or not there are better ways to fix them.

Does anybody remember which problem(s) this function is supposed to fix?

If this function fixes problems that are limited to particular comint 
applications, then it should be added to the local value of
comint-output-filter-functions for those particular applications, not
to the global value, as is presently the case.

Below is an ielm run, with comint-carriage-motion enabled.  To
understand the problems fully, one should run this example with
font-lock-mode enabled.  Redoing the example after executing:

(remove-hook 'comint-output-filter-functions 'comint-carriage-motion)

will give the correct results.

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (read-kbd-macro "\C-ca\C-m")
"              ; self-explanatory
ELISP> (defun aa (x y) (set x y))
aa
ELISP> (aa 'b 9)
9
ELISP> b
9
ELISP> (byte-compile 'aa)
#[(x y)
     L\207"    ; a piece of this string is missing
  [x y]
  2]

ELISP> "\bbb"
bb"            ; self-explanatory
ELISP> "aa\rbb"
bb"            ; self-explanatory
ELISP> 


Sincerely,

Luc Teirlinck.