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

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

[Per Bothner]

The "line" submode of term mode duplicates much of the functionality
of comint mode.  When I wrote term mode, my hope was that it would
subsume comint mode, or that comint mode would be built on top of
term mode.  That never happened - so far.

'shell mode' should basically be the same as 'term' mode, except
that shell mode starts of in line-editing mode, while term mode
starts up in character mode.

There are obvious advantages to merging these modes. One is
we have ansi escape sequence handling in a single place.
Another is that you can run console applications from shell mode.

In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.18.7)
  of 2016-02-02 on buildhw-05.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11800000
System Description:	Fedora release 23 (Twenty Three)

Configured using:
  `configure --build=x86_64-redhat-linux-gnu
  --host=x86_64-redhat-linux-gnu --program-prefix=
  --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
  --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
  --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
  --libexecdir=/usr/libexec --localstatedir=/var
  --sharedstatedir=/var/lib --mandir=/usr/share/man
  --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
  --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
  --with-gpm=no build_alias=x86_64-redhat-linux-gnu
  host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
  -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
  -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
  -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Shell-script

Minor modes in effect:
   sh-electric-here-document-mode: t
   diff-auto-refine-mode: t
   xterm-mouse-mode: t
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: (only . t)

Recent messages:
Wrote /home/bothner/DomTerm/bin/domterm
Mark set
Saving file /home/bothner/DomTerm/bin/domterm...
Wrote /home/bothner/DomTerm/bin/domterm
Mark set
Saving file /home/bothner/DomTerm/bin/domterm...
Wrote /home/bothner/DomTerm/bin/domterm
Mark set
Saving file /home/bothner/DomTerm/bin/domterm...
Wrote /home/bothner/DomTerm/bin/domterm

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message idna format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils info css-mode ispell view mule-util
parse-time sgml-mode sh-script smie executable etags ring texinfo
smerge-mode diff-mode easy-mmode scheme nxml-uchnm rng-xsd xsd-regexp
rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse
rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln
nxml-rap nxml-util nxml-glyph nxml-enc xmltok add-log conf-mode
help-mode autoconf autoconf-mode make-mode vc-dispatcher vc-svn cc-langs
misearch multi-isearch vc-git js advice help-fns byte-opt bytecomp
byte-compile cl-extra cl-loaddefs cl-lib cconv json imenu thingatpt
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs vc-cvs server time-date xt-mouse tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 515998 51413)
  (symbols 48 29080 0)
  (miscs 40 1048 8712)
  (strings 32 53861 12727)
  (string-bytes 1 1792324)
  (vectors 16 27981)
  (vector-slots 8 1509840 153066)
  (floats 8 176 561)
  (intervals 56 77667 486)
  (buffers 960 103)
  (heap 1024 74981 4504))

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

[Ingo Lohmar]

On Tue, Feb 23 2016 12:33 (-0800), Per Bothner wrote:

> The "line" submode of term mode duplicates much of the functionality
> of comint mode.  When I wrote term mode, my hope was that it would
> subsume comint mode, or that comint mode would be built on top of
> term mode.  That never happened - so far.
>
> 'shell mode' should basically be the same as 'term' mode, except
> that shell mode starts of in line-editing mode, while term mode
> starts up in character mode.
>
> There are obvious advantages to merging these modes. One is
> we have ansi escape sequence handling in a single place.
> Another is that you can run console applications from shell mode.



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?

I dumped any use of term.el because I could not control its
complexities, no matter what overrides, patches and advices I used.  I
have not looked back after using shell-mode where it's useful instead,
and not running console applications anymore.

Term is *significantly* more complex than shell (175k vs 54k), and does
a lot more things (for better or worse).  Maybe factoring out the ANSI
sequence parsing is what you really want?

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/

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

[John Wiegley]

>>>>> 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?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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/