help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Does anyone really use emacs in terminal?


From: Pascal J. Bourguignon
Subject: Re: Does anyone really use emacs in terminal?
Date: Sun, 12 May 2013 21:44:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hongxu Chen <leftcopy.chx@gmail.com> writes:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>
>> Am 12.05.2013 um 00:32 schrieb Jai Dayal:
>>
>>> so if
>>> you're not willing to do a little extra work and expect me to prove the
>>> most basic trivial things, I'm going to ask you to put something on the
>>> line, i.e., when I show you Vim's calculus plugins, you never post on this
>>> mailing list again.  deal?
>>
>> Vi has an interface to shell level: :!. This way you can use expr,
>> bc, or dc to calculate something for vi – or use a GNU Emacs script
>> for something less comprehensible…
> However this is inconvenient since Vim just forked a new shell
> process. Now and then I forget whether the shell's parent process is Vim.

He reason why it's inconvenient, is because once you fork a child
process, it cannot modify the data structure in the parent process
anymore.  So ok, you can perhaps calculate, or do calculus (seems
somebody doesn't know the difference), but you cannot have those process
modify the data in the vim buffers, or in vim memory.

Sure, perhaps you can also have a command or a script in vim to load
some file modified by those child processes, but that's the point:
there's no calculus program implemented in vim, like there are
implemented in emacs.  Or spreadsheets, or web browsers, or email
readers, or games, etc.


>> A bit different is :!emacs -nw <RET> – now you are in GNU Emacs, in 
>> terminal, as
>> the subject announces, and can forget that you were in vi before and now are 
>> not
>> that limited. You can even files on some remote host! No plugin necessary.

Still not in vim.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.
You can take the lisper out of the lisp job, but you can't take the lisp out
of the lisper (; -- antifuchs


reply via email to

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