Re: What I'm missing when using M-x shell

[Tim X]

"Francis Moreau" <francis.moro@gmail.com> writes:

> [ please CC me when replying to me ]
>
> On Fri, Sep 12, 2008 at 7:34 PM, Dan Espen
> <daneNO@more.mk.spamtelcordia.com> wrote:
>> Compiles are M-x compile, greps are M-x grep,
>> ls is dired, email is MH-E.
>
> But what would you suggest as replacement for:
>
> $ make && gdb || mail -s "Compilation failed" home
>

Surely you don't use such a command when doing things interactively? A
command like that is something I would use in an automated build process
that isn't run interactively. For example, I've used something similar
in a envrionment where we wanted to rebuild each night from SVN. 

This to me is a different question to working interactively. I don't see
you cold ever eliminate the shell completely as many non-interactive
processes use it. However, I do believe you can work totally through
emacs. In fact, I know you can because that is how I *have* to work. 

I'm a blind programmer and work almost exclusively in the Unix world. My
main interface to the system is through emacs and using a package called
emacspeak. In general, if there is an emacs specific package to do a
job, I use that (e.g. dired, tramp, VM, w3m, view-process (now using
proced) ediff, PCL-CVS, psvn, man/woman, etc) and then revert to M-x shell, M-x
term and M-x eshell when I need access to the shell or need to run a
program directly in a shell etc. 

Though I've not used them, you also have elisp clones of things like
screen and even basic window management packages. At one time I even
used emacs as my window manager under X e.g. last part in my
.xsession file was to try and run emacs and if that failed, run an
exterm that executed a program that told me emacs had failed and started
a very basic screen reader program in an xterm. 


> More generally sh scripts allow automatisation processes that you
> can't simply do with emacs commands, it similar to using a mouse
> actually. I don't think you can get rid of them.
>

I use lots of shell scripts to do various things, but I run them from
within emacs and in some cases, have them bound to specific key
bindings. 

> Futhermore there are a lot of tools out there that are not integrated
> to emacs if you do so, you don't have enough keys on the keyboard to
> create bindings ;)
>
yes, there are a lot of things that don't have 'native' emacs
modes. However, I disagree there are not enough available key bindings -
there are more than anyone is ever going to remember. What a lot of
people don't do or possibly don't even realise is that in addition to M-
and C- for meta and control bindings, you also have hyper and
super. These can be bound to keys like the windows menu key and some of
those other often unused keys on your keyboard. Combine those with shift
and you have a lot of combinations. Admittedly, some of them can be
uncomfortable to use, but thats a different issue and depends on things
liike the type of keyborad, your style of typeing and even things like
the size of your hands, length of your fingers, degree of flexibility
you have in your hands, table height and chair. 



> So I don't think you can realistically get rid of a shell
>

You can't get rid of the shell - its fundamental to how the system
works. However, you can create an environment wehre you only interact
with the shell through emacs without losing any functionality or
flexibility. It may take some work to get it configured, but thats a
different issue. 


> So for now I don't think I can forget Gnu Screen: one screen to handle
> a terminal with a shell where all my ncurse based applications can
> work properly and another screen where emacs lives.
>

Your ncurses applications should behave fine under M-x term provided you
have the correct terminfo information setup. Things can be a little more
complex if you want to un ncurses programs over ssh on another host, but
this can be fixed by adding the necessary terminfo data to the remote
servers. 

Tim


-- 
tcross (at) rapttech dot com dot au