How could someone make a more powerful editing tool than vi, you may ask? The answer is Vim, and this article provides details on the many enhancements that have made Vim a highly used and acceptable editor in the world of UNIX and Linux.
How could someone make a more powerful editing tool than vi, you may ask? The answer is Vim, and this article provides details on the many enhancements that have made Vim a highly used and acceptable editor in the world of UNIX and Linux.
Wow, underscores at the beginning of all your script’s variable names certainly makes it look uglier. What is the purpose? To avoid conflict with already-exported variables? I’d just choose a more descriptive name for my variable.
Comments like these merely discourage people from even wanting to contribute to OSNews.
EDIT:
I know it wasn’t an OSNews contribution…
Edited 2008-09-11 02:58 UTC
I’m not crazy about prefixing variables with underscores either, but as long as the script’s author is consistent with a convention like that it’s not a bad practice.
I actually suffix Bourne shell variables with a 1 (which is probably equally silly) because I’m paranoid that I’ll unwittingly conflict with another env variable.
Is the linked article the correct one? The linked article is on shell scripting and only mentions Vim in one section. The description here on OSNews suggests the entire article is entirely about Vim.
This is likely the correct article:
http://www.ibm.com/developerworks/aix/library/au-speakingunix_vim/?…
I would ask how could someone make a more powerful editor, if this was actually a fact, and not lifted from the imagination of the writer. I would’ve said “EMACS”, but someone might consider this not at face value.
VI was/is a strong editor, but definitely not the most powerful editing tool. Maybe it was at the time it was created, but that was several decades ago. Even removing Vim, and all the VI clones from the historic equation, VI’s abilities were equaled, or surpassed during the time that went by from its creation to these days. As of today, most people consider Vim to equal VI, with the original VI (or Vim-Tiny/Compatible mode) looking feeble and restrictive in comparison.
This is a throwaway post with a throwaway caption, but one assumes the author to know his mettle, or stay with what he does know.
When listed which architectures VIM is ported to, most major OS are listed, even the arcane OpenVMS. But not Solaris nor HP-UX. Why is that? Is it because they compete directly with AIX?
And, when looking at the references at the bottom, 3 of them are about VIM, but the rest 7 are mostly about AIX stuff. Why is that, in an article about VIM? 30% VIM stuff and 70% AIX (or Unix) in an VIM text?
:o)
Edited 2008-09-11 10:49 UTC
I use MacVim, which is a port of gVim. However, Vim was designed as an advanced editor for the console, and it’s still brilliant for that, but I find myself getting frustrated with the lack of easy configuration.
I’m very excited about the newly implemented Vi bindings for Kate. I like that the project takes an already brilliantly configurable graphical editor, and adds Vi bindings for fast editing. If something tricky needs doing, it’s easy to grab the mouse and head to a menu, but stick to the keyboard for oft-repeated tasks.
As much as I like the features vim packs into a terminal text editor, I still don’t like the learning curve it brings to the end user. For someone that’s new to command line (I’m not), it’s not the easiest editor to understand and use. I don’t code, so a lot of the extra features don’t really benefit me a whole lot. I’ve been using nano for years due to its simplicity and very small (next to non-existent) learning curve.
I still know the basics of using vi(m), and I know I could read the man page for it. But, why would I when nano does everything I need it to do, and fairly well?
I second the excitement for vi bindings for Kate, not because I use vi, nor know its bindings, but because it allows for transparent operation between working environments. I will explain what this transparency involves after I first make another point.
I’m not trying to start a flamewar, but I believe for most intents and purposes GUI text editors are absolutely superior to CLI text editors. Some may have grown accustomed to the comfort of a CLI text editor, but as far as productivity is concerned, there’s a reason most of the computing world has moved to GUI interfaces. Additionally, CLIs are *embeddable* in GUI interfaces, so all the individual advantages of running a CLI (power of scripting, more easily detachable/relocatable terminals, less screen clutter, etc.) are available from a GUI but not the other way around.
But, having consistent key bindings between environments allows you to pick up where you left off, without the mental overhead (see what I did there!) of having to switch your behaviors when you switch environments (CLI vs. GUI.) Really, in my *opinion* the reason you would use a CLI text editor is when GUI facilities are unavailable, such as when on a public computer, or a blackberry.
What I would like to see is a dual mode GUI/CLI editor (forgive me if I am unaware of the capabilities of VIM/Emacs, or whatever) which is usable both from the CLI and the GUI which shares the state of the documents being edited (I guess via a subethaedit-type mechanism.)
I personally prefer Emacs, and don’t even like the VI interface. And as another poster pointed out, the learning curve is steep, at least when compared to something like Nano. However, VI enjoys one true advantage is that every Unix/Linux version I’ve ever used seems to come with VI included. If you know at least basic VI commands, you can get something done in a hurry. This is especially important in the age of live CDs, since you can’t simply install Emacs or another editor when you’re running a live CD.
Oh no, please, don’t start another thread Vi vs. Emacs 🙂
Why bother with that when the article submission is an inflammatory remark about the superiority of vim over vi?
Being 43 times larger I am sure they managed to fit a copy of emacs there somewhere.
Use it where its practical. I use vi when I borked something up and need to do a quick livecd fix, but for any lengthy endeavors, vim or emacs have the features to make life easier.