Why is Vi(m) bad
Steve
I turned my nose up at vi because I couldn't compile from within it, and
I thought having to press M : i to actually write text was weird.
All of that was years ago.
Now I am a more experienced programmer.
I have dealt with learning things with emacs that were weird, different,
frustrating.........as well as other systems.
Vi(m) has also improved to be more flexible, including being able to
split the screen, run shell commands from within etc.
The vi(m) users always seem to have a "yes" answer for me when I ask
them "can you do that in vi(m)".
Given that I would be interested in hearing why vi(m) is bad.
Are most folks just like me, back in college vi vs emacs were the only
choices and they simply went one way as opposed to another?
Steve
stevesusenet AT yahoo DOT com
The Java Resource Dump
http://www.geocities.com/beforewisdom/Tech/Java/index.html
Steve's Tech Links:
http://www.geocities.com/beforewisdom/Tech/index.html
-------------------------------------------------------
"Rancor is an outpouring of a feeling of inferiority"
- Jose' Ortega y Gasset
--------------------------------------------------------
David Kastrup
> I became a gnu emacs user in college as a new programming student.
>
> I turned my nose up at vi because I couldn't compile from within it,
:!make is not really more complicated than M-x compile.
> and I thought having to press M : i to actually write text was
> weird.
M : i ? Eh?
> All of that was years ago.
>
> Now I am a more experienced programmer.
> I have dealt with learning things with emacs that were weird,
> different, frustrating.........as well as other systems.
>
> Vi(m) has also improved to be more flexible, including being able to
> split the screen, run shell commands from within etc.
>
> The vi(m) users always seem to have a "yes" answer for me when I ask
> them "can you do that in vi(m)".
Can you do the like of <URL:http://preview-latex.sourceforge.net> in
vi(m)?
That will give the "sour grapes" answer at best.
> Given that I would be interested in hearing why vi(m) is bad.
You are kidding, right? One of the most widely used and efficient
editors certainly can't be seriously called bad. vi is pretty good.
It is just that for quite a few of my editing uses, it is not good
enough. See the above example.
One large advantage Emacs has is its first letter, "extensible". It
has grown loads of convenient code and packages for editing purposes.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Shyamal Prasad
Steve> Given that I would be interested in hearing why vi(m) is
Steve> bad.
Huh? vi is evil, that is well established fact. The spawn of evil is
evil. Therefore, vim is evil. Almost axiomatic to me.
This liberal attitude of questioning the One True Editor (tm) is
really getting out of hand. Give people a little freedom of thought
and everything goes down the tubes......
Steve
> has grown loads of convenient code and packages for editing purposes.
So is vim apparently. My buddy at work showed me vim with a new
customgui drop menu with all sorts of macros a friend of his made.
James A. Crippen
> Huh? vi is evil, that is well established fact. The spawn of evil is
> evil. Therefore, vim is evil. Almost axiomatic to me.
>
> This liberal attitude of questioning the One True Editor (tm) is
> really getting out of hand. Give people a little freedom of thought
> and everything goes down the tubes......
Nobody expects the Emacs Inquisition!
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
David Kastrup
> "Steve" == Steve <add...@bottom.of.post.nospam.com> writes:
>
> Steve> Given that I would be interested in hearing why vi(m) is
> Steve> bad.
>
> Huh? vi is evil, that is well established fact. The spawn of evil is
> evil. Therefore, vim is evil. Almost axiomatic to me.
And Job was faithful to Emacs, and prospered. But the temptator
asked to be allowed to do his bidding, and offer Job something to be
called viper. And his keybindings abandoned him.
Rob Reid
Steve> I became a gnu emacs user in college as a new programming student.
Steve> I turned my nose up at vi because I couldn't compile from within it,
Steve> and I thought having to press M : i to actually write text was
Steve> weird.
Isn't having to type in a cryptic incantation before editing enough?
And does :!make highlight the errors and take you to them like M-x compile
does?
Nix
> Can you do the like of <URL:http://preview-latex.sourceforge.net> in
> vi(m)?
Yes, easily.
You take the source code to gvim, and change it (quite significantly)...
... but I don't know if that counts. Probably not.
(But then, no Emacs variant has come through the preview-latex
experience with an entirely unchanged C core either ;} )
>> Given that I would be interested in hearing why vi(m) is bad.
>
> You are kidding, right? One of the most widely used and efficient
> editors certainly can't be seriously called bad. vi is pretty good.
Even I think it's damned useful for quick editing tasks (and I know
almost none of the useful tricks; I can barely do move-by-word in it);
but TRAMP has reduced my dependence upon vi for sysadmin tasks and
suchlike a lot.
vi's biggest problem was that the commercial Unixes lost its
documentation and didn't bother to maintain it for years. vim fixed
both of those.
(Oh, and the rebarbative command set and modality: but Emacs's
keybindings aren't always the most brilliant either...)
> One large advantage Emacs has is its first letter, "extensible". It
> has grown loads of convenient code and packages for editing purposes.
And for every other purpose one can imagine. Hell, you can use it as
a (primitive) paint program now!
(And Gnus has probably drawn more people to the Emacsen than any other
single package...)
--
`There's something satisfying about killing JWZ over and over again.'
-- 1i, personal communication
David Kastrup
> On 24 Jul 2002, David Kastrup said:
> > Can you do the like of <URL:http://preview-latex.sourceforge.net> in
> > vi(m)?
>
> Yes, easily.
>
> You take the source code to gvim, and change it (quite significantly)...
>
> ... but I don't know if that counts. Probably not.
Having to dump the existing binary and recompile your own (if you have
no write access to the original one) pretty much defeats the
extensibility aspect. I asked "can you do it in vim?", not "can you
do that to vim?".
The latter has already been answered positively by LyX developers:
they have been able to do it to LyX, but LyX' display engine did not
make this as large a surgery as it would be on vi and its ilk.
> (But then, no Emacs variant has come through the preview-latex
> experience with an entirely unchanged C core either ;} )
I call "false" upon this: I don't count bug fixes as "changes" in that
manner. Both Emacsen have had sufficient power designed into them.
Even though I am afraid that some prospective features will require
more core functionality particular from GNU Emacs.
> >> Given that I would be interested in hearing why vi(m) is bad.
> >
> > You are kidding, right? One of the most widely used and efficient
> > editors certainly can't be seriously called bad. vi is pretty good.
>
> Even I think it's damned useful for quick editing tasks (and I know
> almost none of the useful tricks; I can barely do move-by-word in
> it);
w
And move 4 words with
4w
> but TRAMP has reduced my dependence upon vi for sysadmin tasks and
> suchlike a lot.
tramp is really nice, even though it would be nice if Kai could make
his mind up on one syntax and feature set and stick with it. The
in-between stages are currently one of the two parts making CVS Emacs
adventurous right now (the other are completely mindboggling redisplay
errors when scrolling).
> (Oh, and the rebarbative command set and modality: but Emacs's
> keybindings aren't always the most brilliant either...)
Different things. vi bindings are supposed to be ergonomic, Emacs
bindings are supposed to be mnemonic. Probably because there are so
many of them that no user will be expected to be able to type them
without thinking, anyway.
Kai Großjohann
> tramp is really nice, even though it would be nice if Kai could make
> his mind up on one syntax and feature set and stick with it. The
> in-between stages are currently one of the two parts making CVS Emacs
> adventurous right now (the other are completely mindboggling redisplay
> errors when scrolling).
I also wish Tramp would have been perfect when I included it in
Emacs:-) Alas, it was not so.
kai
--
A large number of young women don't trust men with beards. (BFBS Radio)
Mike Warren
> > Huh? vi is evil, that is well established fact. The spawn of evil is
> > evil. Therefore, vim is evil. Almost axiomatic to me.
> >
> > This liberal attitude of questioning the One True Editor (tm) is
> > really getting out of hand. Give people a little freedom of thought
> > and everything goes down the tubes......
> Nobody expects the Emacs Inquisition!
Surely you mean ``M-x emacs-inquisition''...?
(Or, perhaps, M-x psychoanalyze-pinhead if you want something which
actually works ;)
--
mike [at] mike [dash] warren.com
<URL:http://www.mike-warren.com>
GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A 0CF9 1087 0884 5799 11BD
d2002xx
frames in GUI environment? A built-in programming languages as
powerful as emacs-lisp?
Also, some features that I expect in emacs:
1.Tag system that can auto-update tags and understand what's
inheritance
2.Refactoring browser (I'm still searching...)
3.Mail/news reader that doesn't "freeze" when getting mail.
4.Faster HTML browser
I wonder can vim do these?
Steve
I never used Vi(m), I have friends that use VIM and from what they
told me:
- VIM runs both in a shell and in x-windows
- supports split screens in the shell. The GUI supports mulitple and
split windows.
- has an extension language. Its not lisp, but I've heard that it is
very easy. IMHO that is a good thing as it encourges people to
extend. I saw some very impressive macros and gui extensions made by
one guy who didn't put a lot of effort into it.
- whats a refractoring browser? :)
- I am *told* that you can do something to use vim to read your email
- I don't think VIM has a dedicated html browser. I think vim users
just push a button/fire a command to bring up their buffer in the
default web browser.
If you are working on html or javascript this is probabally what you
want anyway.
The Vi(m) people have made comp.editors their unoffical home.
You should ask some of these questions there.
Vim has come a LONG way from Vi. The impression that I got is that
eventhough it lacsk a usenet reader and mail client it is getting
close to rivaling emacs in code editing features.
I'll never use it, I hate those modes, but it is time review how I
think of vi(m).
Mike Warren
> 3.Mail/news reader that doesn't "freeze" when getting mail.
AFAIK, this is because the Emacs lisp interpreter is single-threaded
(for now; apparently there's some work underway to multi-thread it) so
everything you do ``freezes'' Emacs for a while (it's just that most
things are really quick in comparison to groking new mail).
d2002xx
> told me:
>
> - VIM runs both in a shell and in x-windows
>
> - supports split screens in the shell. The GUI supports mulitple and
> split windows.
>
> - has an extension language. Its not lisp, but I've heard that it is
> very easy. IMHO that is a good thing as it encourges people to
> extend. I saw some very impressive macros and gui extensions made by
> one guy who didn't put a lot of effort into it.
I took a look at it. But ... I still like lisp :)
>
> - whats a refractoring browser? :)
Something helps do refactoring such as moving method, renaming
class... I just want to learn to such thing. I know it exists in
eclipse. And there is a xref in emacs for C and Java, but it's
commerial...
> - I am *told* that you can do something to use vim to read your email
Can vim avoid "freeze" when getting mail?
> - I don't think VIM has a dedicated html browser. I think vim users
> just push a button/fire a command to bring up their buffer in the
> default web browser.
> If you are working on html or javascript this is probabally what you
> want anyway.
>
> The Vi(m) people have made comp.editors their unoffical home.
>
> You should ask some of these questions there.
If I have time to switch to another editor...
> Vim has come a LONG way from Vi. The impression that I got is that
> eventhough it lacsk a usenet reader and mail client it is getting
> close to rivaling emacs in code editing features.
>
> I'll never use it, I hate those modes, but it is time review how I
> think of vi(m).
Yeah, me too. And I have seen some people switch to vim, but I'm
wondering if vim is "better" than emacs?
d2002xx
>
> AFAIK, this is because the Emacs lisp interpreter is single-threaded
> (for now; apparently there's some work underway to multi-thread it) so
> everything you do ``freezes'' Emacs for a while (it's just that most
> things are really quick in comparison to groking new mail).
Thanks. I expect it :) But it seems not yet to show up in CVS.
Per Abrahamsen
Last I heard RMS considered multi-threading a "nice but not important"
feature (he obviously doesn't use Gnus).
I haven't heard of any work underway to multi-thread it. We just
might get it with Guile, though.
David Kastrup
> d20...@myrealbox.com (d2002xx) writes:
>
> >> > 3.Mail/news reader that doesn't "freeze" when getting mail.
> >>
> >> AFAIK, this is because the Emacs lisp interpreter is single-threaded
> >> (for now; apparently there's some work underway to multi-thread it) so
> >> everything you do ``freezes'' Emacs for a while (it's just that most
> >> things are really quick in comparison to groking new mail).
> >
> > Thanks. I expect it :) But it seems not yet to show up in CVS.
>
> Last I heard RMS considered multi-threading a "nice but not important"
> feature (he obviously doesn't use Gnus).
gnus-asynchronous's value is nil
*If nil, inhibit all Gnus asynchronicity.
If non-nil, let the other asynch variables be heeded.
You can customize this variable.
Defined in `gnus-async'.
Nils Kassube
> Something helps do refactoring such as moving method, renaming
> class... I just want to learn to such thing. I know it exists in
> eclipse. And there is a xref in emacs for C and Java, but it's
You can get Bicyle Repairman (or something like that), a
refactoring tool for Python and Emacs for free. And
if you don't know Python, now is a very good time to
learn it ;-)
Nix
> Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
>> d20...@myrealbox.com (d2002xx) writes:
>>
>> >> > 3.Mail/news reader that doesn't "freeze" when getting mail.
>> >>
>> >> AFAIK, this is because the Emacs lisp interpreter is single-threaded
>> >> (for now; apparently there's some work underway to multi-thread it) so
>> >> everything you do ``freezes'' Emacs for a while (it's just that most
>> >> things are really quick in comparison to groking new mail).
>> >
>> > Thanks. I expect it :) But it seems not yet to show up in CVS.
>>
>> Last I heard RMS considered multi-threading a "nice but not important"
>> feature (he obviously doesn't use Gnus).
>
> gnus-asynchronous's value is nil
>
> *If nil, inhibit all Gnus asynchronicity.
> If non-nil, let the other asynch variables be heeded.
That's hardly multi-threading: things like entering new groups still
freezes your Emacs for some time while it sucks down the overview and
chews over the thread structure.
Ideally, non-gnus buffers would be unlocked then.
(But, of course, multithreading Emacs --- multithreading *anything* ---
requires changes to all the code so it's multithread-aware. Fat chance
of that with all the elisp code out there.)
--
`Mips are real and bitrate earnest, shifting spam is not our goal;
silicon to sand returnest, was not spoken of the soul.'
--- _Eventful History: Version 1.x_, John M. Ford
Henrik Motakef
> We just might get it with Guile, though.
Whats up with this Emacs and Guile thingy? It keeps popping up now and
then, sometimes it even sounds as if it was already clear that some
future Emacs version will use Guile (which is Scheme, as far as I
understand) instead of Elisp. Is this the case?
And if so: WHY OH WHY would anybody want to use Scheme and not Common
Lisp as a replacement for Elisp? It would require far more changes to
existing Elisp code, and after all, there are two GNU projects that
implement CL, one of them even being really good (clisp), the other
getting better (GCL, which seems to try to get standard CL
comformant). Additionally, given that quite a lot of Elisp code
(require)s cl and/or eieio anyway, which mocks stuff standardized in
CL but not Scheme, I fail to see the point of this.
Lute Kamstra
> Per Abrahamsen <abr...@dina.kvl.dk> writes:
>
> > We just might get it with Guile, though.
>
> Whats up with this Emacs and Guile thingy? It keeps popping up now and
> then, sometimes it even sounds as if it was already clear that some
> future Emacs version will use Guile (which is Scheme, as far as I
> understand) instead of Elisp. Is this the case?
It's being heavily discussed right now:
http://mail.gnu.org/pipermail/emacs-devel/2002-August/thread.html
Lute.
--
(spook) => "AK-47 asset BLU-97 A/B"
(insert-file-contents "~/.signature") => (error "`~/.signature' too rude")
Per Abrahamsen
> And if so: WHY OH WHY would anybody want to use Scheme and not Common
> Lisp as a replacement for Elisp?
- Guile is the standard extension language for GNU.
Glenn Morris
But we all know the dangers of going down the "standard" route...
etc/JOKES:
ED! ED! ED IS THE STANDARD!!!
D. Goel
> Whats up with this Emacs and Guile thingy? It keeps popping up now and
> then, sometimes it even sounds as if it was already clear that some
> future Emacs version will use Guile (which is Scheme, as far as I
> understand) instead of Elisp. Is this the case?
not instead of elisp.. elisp will stay as it is, AFAIU.. just the backend,
which is currently written in c, will change to guile, AFAIK.
some advantages of using guile as the backend can be found at:
http://www.gnu.org/software/guile/guile.html
Martin Thornquist
> Henrik Motakef <henrik....@web.de> writes:
>
>> Whats up with this Emacs and Guile thingy? It keeps popping up now and
>> then, sometimes it even sounds as if it was already clear that some
>> future Emacs version will use Guile (which is Scheme, as far as I
>> understand) instead of Elisp. Is this the case?
>
> not instead of elisp.. elisp will stay as it is, AFAIU.. just the backend,
> which is currently written in c, will change to guile, AFAIK.
Well... I browsed the recent discussion on emacs-devel on Guile, and I
got the impression that while there (naturally) needs to be a
compatibility mode for elisp, there is to be a possibility (perhaps
the preferred alternative) of using Guile with some extensions for
handling buffers etc.
Sam Steingold made the quite interesting statement that he had hacked
up elisp compatibility for CLISP in a weekend. He also repeatedly
tried to get RMS to discuss Common Lisp vs. Guile, something RMS
mostly ignored, only stating that he has disliked Common Lisp since he
once found it hard to implement (duh! Common Lisp is designed to be
easy for the programmer, at the price of a bit more work for the
implementor).
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
d2002xx
Is guile faster than C? Slow is absolutely unacceptable for a backend...
Martin Thornquist
> Is guile faster than C? Slow is absolutely unacceptable for a backend...
Languages aren't fast or slow, implementations are.
Henrik Motakef
> [ d20...@myrealbox.com ]
>> Is guile faster than C? Slow is absolutely unacceptable for a backend...
> Languages aren't fast or slow, implementations are.
"Guile is an interpreter for the Scheme programming language..."
<http://www.gnu.org/software/guile/guile.html>
Sounds like an implementation to me...
Steve
>
> - Guile is the standard extension language for GNU.
Is it used in any application yet?
Steve
Steve
> Is guile faster than C? Slow is absolutely unacceptable for a backend...
I agree completely.
There is far too much new software out there today that is
"politically/academically/design correct" and slow as sh**t.
In a house, location, location, location.
In software, especially editors, poor speed overshadows everything.
Steve
David Kastrup
The text processor TeXmacs, the window manager scwm, the office suite
Siag and the plotting util guppi come to mind.
For a more complete list, see
<URL:http://www.glug.org/projects/list.html>.
It also explains some more things about the Emacs-Guile project.
Martin Thornquist
> "Guile is an interpreter for the Scheme programming language..."
> <http://www.gnu.org/software/guile/guile.html>
Oh. I thought is was a dialect of Scheme, as yet only with one
implementation. So what "Scheme programming language" does it
implement? Strict R5RS?
Anyway, my statement still holds for the C part of what I responded
to.
Rob Thorpe
There are no plans to replace the C backend of Emacs, only possibly
the interpreter part. This is planned to be replaced with guile, elisp
will continue to be usable, either by translating it to scheme or
retaining its interpreter as well.
Elisp is not going anywhere soon, there are hundreds of thousands of
lines of it in Emacs.
Henrik Enberg
> Is guile faster than C? Slow is absolutely unacceptable for a backend...
Guile is written in C just like the Emacs Lisp interpeter. I don't
know which one is faster though.
--
Booting... /vmemacs.el
Mike Warren
The Gimp uses it as its extension language, IIRC.
Rob Thorpe
> steves...@yahoo.com (Steve) writes:
> > Per Abrahamsen <abr...@dina.kvl.dk> wrote
>
> > > - Guile is the standard extension language for GNU.
>
> > Is it used in any application yet?
>
> The Gimp uses it as its extension language, IIRC.
The gimp uses scheme but it uses SIOD not guile, it's very similar though.