bug#22785: 24.5; comint/shell modes should be merged with term mode

[Per Bothner]

On 02/24/2016 10:20 AM, John Wiegley wrote:
> > > > > > Per Bothner <per@bothner.com> writes:
>
> > To clarify: The goal is to essentially merge term.el and comint.el.
> > Comint.el might still exist, but only as a think veneer on term.el. shell
> > might or might not existing as a separate mode, but it would at most be a
> > thin veneer on top of term mode.
>
> I'm not sure what to think about this. Term is a bit of a complex beast, it is
> true, and it has far fewer users than comint. What is the motivation exactly?
> Would any mode other than shell interaction benefit from this merge?

While term is a bit of a complex beast, so is shell+comint mode.
Throw in ansi-color and it's more complex than term.

The existence of ansi-color shows there is a demand for at least handling
ansi escape sequences for colors and highlighting.  And if you're going to
handle those you might as well also support cursor movement and finish
the job.

Some inferior-process modes might prefer to make use of the inferior's readline,
at least as an option.

Sometimes a repl may want to do more than read/write times.  It may
want to switch colors, "print" pictures (as supported by Racket/Geiser),
ask for a password or a single-letter key.  Of course all of this can be done
with comint, but it's easier if one can use the same logic and protocols
whether in a comint mode, in term mode, or in a non-emacs terminal emulator.

Right now there is a lot of code duplication in Emacs.  term.el duplicates much
of comint.el.  ansi-color.el duplicates term.el. Etc.  It would be better to
clean this up.
--
        --Per Bothner
per@bothner.com   http://per.bothner.com/