Re: comint-carriage-motion causes severe problems.

[Luc Teirlinck]

Richard Stallman wrote:

   Luc, could you please give some examples of programs where
   comint-carriage-motion makes things worse, and show what the output
   looks like both with and without comint-carriage-motion?

As mentioned in my earlier message, I now agree with Miles that
comint-carriage-motion should be in the global value of
comint-output-filter-functions, but not in the local ielm value.

Miles says that the function is necessary for the correct functioning
of interactive Unix programs.  The program I was referring to, where
comint-carriage-motion makes a bad situation even substantially worse,
is the mathematical software package magma.  I could send you examples
of runs if this is still relevant or of interest to you or
Miles.  However, the correct running of Unix programs in M-x shell is
more important than the correct running of specialized software
packages that could only be made to run correctly by writing a
specialized mode especially for them.  (They would require their own
highly specialized and complex syntax-table and syntactic rules, among
other things.)

I was actually less concerned with making mathematical software
packages run correctly (which would require tons of work) than with
the same type of problems that occur in ielm.  But in other applications
of comint control characters meant to be printed as such occur very
infrequently, whereas in ielm they are routine.

What happens is that I (just every now and then) have C programs or
Common Lisp programs yielding control characters that need to be
printed out as such.  I can not run these programs from a shell in an
Xterm (unless I redirect their output to a file) because the shell
itself mutilates their output just like comint-carriage-motion does.
Thus I run them from M-x shell or M-x run lisp (obviously with
comint-carriage-motion disabled) to see the correct output
interactively, without having to look it up in a separate file.  We
are in effect talking here about using M-x shell and M-x run-lisp to
improve shell behavior rather than to just imitate it.  But these
improvements are actually necessary to enable Emacs to understand the
syntax correctly which is absolutely essential, certainly in M-x
run-lisp, for proper functioning of font-lock, show-paren, and
several motion and other commands relying on syntax.  (For exactly the
same reasons as in ielm.)

However, I fully agree that the above is highly specialized and
a-typical usage.  Hence I agree with Miles.

Maybe one little detail:

Would it not be somewhat better and more logical to put, in comint.el,
comint-carriage-motion in the defvar of
comint-output-filter-functions, rather than using a separate add-hook
for it? 

This would have two advantages:

1. It would make the comint.el code easier to understand.

2. As noted above, while I agree that comint-carriage-motion belongs
   in the global default value of comint-output-filter-functions,
   there are, for the reasons outlined above, definitely situations
   where one, at least temporarily, wants to remove it.  In the event
   that, in some way or another, comint.el gets loaded again, the defvar
   will not re-add comint-carriage-motion secretly behind the user's
   back, but the add-hook will.  Essentially, we are talking about the
   same difference as the one between defvar and setq. 

However, if this change would cause any problems, then it is not that
important.  Require and provide make a reloading of comint unlikely,
assuming all comint using code uses them rigidly.

Sincerely,

Luc Teirlinck.