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

[Per Bothner]

On 02/23/2016 01:05 PM, Ingo Lohmar wrote:
> To me, that seems to be a bad idea.  They are two different modes
> precisely *because* they are quite different.  If you want to run
> console applications, why would you use shell-mode at all?

Why not?  There are also hybrid applications, such as ones that
use readline.  You can't use readline in shell mode, but you can
in term mode.

> I dumped any use of term.el because I could not control its
> complexities, no matter what overrides, patches and advices I used.

Well, there have been some kludges (as well as some improvements) to term
since I worked on it.  It was on the whole probably seen less maintenance
than comint mode, since more modes extend the latter.

> Term is *significantly* more complex than shell (175k vs 54k),

That is the wrong comparison.  You need to compare the size of term mode
with that of comint mode (162k).  Shell mode is just a relatively modest
extension of comint mode.

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.

Maybe it would make more sense to merge term-mode terminal-handling
into comint.  shell mode could still extend comint mode.
In that case M-x term would more-or-less be the same as starting
up shell mode and switching to the char submode.
--
        --Per Bothner
per@bothner.com   http://per.bothner.com/