[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Per Bothner
Subject: bug#22785: 24.5; comint/shell modes should be merged with term mode
Date: Tue, 23 Feb 2016 13:24:35 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

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
address@hidden   http://per.bothner.com/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]