Vim is a really nice editor: vi with all the nubbly bits trimmed and a silky smooth layer of enhancements smeared over the top. I hope you enjoy the ride.

For what it's worth, forget :wq and use :x instead.

Should you persist for a while with vim I have no doubt that you'll find that BBEdit --compared to vim-- is a joke. And not a very funny one, either.

Sorry, did I say "joke"? Only joking, of course... no offence intended. I *heart* pictures of Rich Siegel's cars!

pjmm,

Thanks for your comments and the tip!

Cheers,
FJ

I'm currently using TextEdit. I fits my needs just fine. I keep my to-do list (I'm a big GTD fan), blog posts, novel ideas, etc., and it works just fine. When I need to work in a terminal, I use Nano. It's simple, and it gets the jub done with leaving backup files strewn everywhere.
As for running a business on a bare-bones OpenBSD install, I think almost any small business where all the employees are sufficiently computer-savvy could do so, especially a professional blogging or web-design business. Text editing, networking, FTP, web browsing, and e-mail are all included. The only thing one would need to add would be accounting and/or billing software.

Mike,

Thanks for sharing your experience. TextEdit can indeed be extremely convenient!

FJ

The fact that the "old tools" still seem to work that good for you just proves that todays operating systems have not evolved much in the last 30 years.

I find it truly sad.

Recently, on my trip somewhere I found myself with a little spare time at the train station which I usually use to go to the news agency and have a look at the mags on display. There, on the news stand, are now a slur of glossy Linux mags. I took one and leafed through it and I suddenly knew what was wrong with Linux: The mags felt like those Atari ST mags back in the early 80s: Code listings to copy, DIY articles about how to connect a scanner to your computer and reconfigure the kernel and download and compile the driver and create the startup scripts to load it and where to put those on the different distributions and which Kernel patch to avoid and so on.

I was hoping those times were gone. Not that it wasn't fun to tinker with your computer (remember how you could play music with the Apple II drive by moving the head about real quick with some assembler hacks?), but you shouldn't have to just to scan in a page.

I would include Smultron as another editor option. I think it is quite capable.

I switch between Smultron and vim everyday. Vim ':s' is still unbeteable as a search and replace tool, but Smultron includes spell checking as you type...

vi'ing a little bit (just the basics) is still quite cool, because whatever UNIX system you log in (and they are plenty of them) you will find it there.

What I think is great about vi is that you don't have to use your mouse (I know that traditional mac users love their mouse, but think about rsi), and that it is even accessible remotely through ssh ;-)
It's amazing what you can already do with learning 10 basic commands. And when you know regex, there is almost no limit to what you can do ;-)

I don't know how you're learning Vim, so I'll give the probably known tip:

If you don't know about vimtutor, you should - just run vimtutor and you'll get Vim loaded with a tutorial text file walking you through the basics. It takes about half an hour to go through the whole thing, if memory serves, maybe a little longer on the first pass. When I first started with Vim, I did that first, then re-took the tutor 2-3 days later, and then went through it once more a week or so later. That will bring you up to par with Notepad-level editing, so you can start getting work done with Vim instead of fumbling around and wondering how things work.

And from there on out, the sky's the limit.

Hint: after typing :help on the command-line, you can tab-complete help topics; and anywhere you can use tab-completion on the command line, you can hit Ctrl-D to get a list of all possible completions. This works so well for me that I never felt compelled to read much of the manual linearly; especially since many help topics have several synonyms listed.

Welcome to the world of vi users! Vi rules, and Vim even more so. I'm a 10 year user of vi and vim, but especially vim contains so much functions, i just keep finding interesting ones (and promptly forgetting how to use them).

Somehow, learning vi is a kind of spiritual event. You don't really *need* it, right? But for me, i discovered a different world, beneath all the glitter and glamour of fancy GUIs; something closer to the engines of computers (not only unix...)

Knowing vi will also earn you respect from those-in-the-know.

Running a business on bare-bones OpenBSD? Should be possible. Might even be more efficient than something loaded with complexity. Of course you'll have a hard time finding staff for non-tech positions...

Vim tips from vim.org. Chock full of useful information.

Oliver: Perhaps you could tell us how text has changed significantly from the days of the "old tools" that should have made things like vim not work well? It has nothing to do with operating systems.

Is learning Vi and Mutt still reasonable in a world of BBEdits and Mailsmiths, SubEthaEdit and Kiwis?

Heck yes! BBedit's scriptability is nothing to sneeze at, but Vim gives you the entire command line universe to work with. You can use v (visual) to select text, or specify a range of lines, and pipe your selection into any command-line filter or shell script. I should also point out that Vim has its own scripting language, but I haven't even started delving into it.

Here's a handy time-saver I learned about recently: move your cursor over a word and press * -- this moves to the next occurrence and highlights all occurrences of that word.

A recent Distributing the Future (O'Reilly) podcast talked about high-performance interfaces (and I consider Vim to be one). The speaker said the difference between a purpose-built interface and a generic interface is like the difference between a violin and a kazoo -- in 15 minutes, you can get as good as anyone can get on a kazoo. A more complex instrument (Vim, violins) may take much longer to master, but mastery provides a depth and breadth of performance that can't be matched by a more generic instrument.

I'm not calling BBedit a kazoo; but Vim is, in my opinion, a far more powerful editor. You might want to install the Aqua/Carbon version to free up your Terminal window as well.

I "forced" myself to learn vi about 7 years ago. At the time I was using Alpha on the mac. It was hard for about a month. I picked up the Learning vi book from O'Reilly and got cheat sheets from the web. Then I started with vim and added a few plug-ins. It's amazing how powerful this editor is when you take the time to learn what you can do. Once you get get comfortable check out some of the plugins. One of my favorites for vim is "Align". You can specify a section of code and align everything based on a character. For example an "=" to make all your assignment statements line up nice. I hate messy code!

In vi, if you have smart indenting set and paste from an external application, the start position will get messed up unless you use
set :paste and set :nopaste before and then after you paste from the external application. It's super helpful, but took me awhile to find.

Good luck with vim - it is an excellent tool. A good, short piece to read is Bram Moolenaar's Seven habits of effective text editing. Make sure that you are using vim 7, by the way. The addition of tabs and spell-checking on the fly are well worth it. (And it saves you from listening to xmanoel's advice about Smultron). One last tip - visual block mode (Ctrl-v) has astonishing power that will amaze shoulder-lookers.

Woops! I meant :set paste and :set nopaste

One of the infuriating things about vim and similar 'old school' software is that they make you realize how much substance their newer brethrens lack. Take for example block editing, folding, customizable syntax highlighting, unlimited undo/redo and crash recovery - few modern editors (and I look in particular at IDE editors) offer all that in one package.

Heh. It seems Michael has already shown the utility of the vim.org tips page.
The autoindent toggle is covered in the sixth tip in the list (sorted by rating, descending).

Vim is awesome and has served me well for....gosh....don't know how many years. An adjustment I've been making to my vimming habits over the past year or two is editing multiple files at the same time. You can :e {{filename}} in an existing vim and it'll start editing it. You can :bn or :bp to move to the next buffer or previous buffer. (Of course, I've mapped them to C-n and C-p.) Also, splitting your window is incredibly useful. :sp to split horizontally and :vsp to split vertically. C-w {{typical vim cursor movement keys}} will move you from pane to pane.

One of the things I love about vim is never having to reach for a mouse (or touchpad). Despite its power, I'm actually investigating emacs and going to give it a fair shake.

Windows users? No problem!
You can use vim (and gvim) on Unix, Mac, Windows.
And X11.

>The fact that the "old tools" still seem to work that good for you just proves that todays operating >systems have not evolved much in the last 30 years.
>I find it truly sad.

You could flip that round, and say it is truly sad to design something with a short lifespan. And vim has definitely evolved over the years - what you're looking for is revolution, rather than evolution - and revolutions, like the introduction of GUI, are a lot rarer.

(And there are too many people interested in false starts - computers you talk to? Can you imagine sitting in an office with a hundred people talking to machines??).

I've been using vi since my undergrad days at Cal (its birthplace, where it is pronounced "vee eye"), and dabbled in emacs every 5 years since then. Unfortunately my brain is pretty much hard-wired to vi's keystrokes. Fortunately, vim has added all the features (multi-undo is the biggest) that made me long after emacs.

As a beginner, you should definitely check out vim's "macro recording" facility. Along with :s, you have the power to do things that "I suppose you could accomplish in BBEdit, or another editor", but much much more easily. The macros have "learning mode" ("qa" starts it), then you do some commands, then "q" again. Then you play back the macro with "@a". The "a" is the name of the macro -- you can have many many of them, but I usually just define one at a time. If you have the macro position the cursor at the next line, then you can repeat the macro for the next 20 lines by typing "20@a". I've done amazing things with this simple power.

As another recent transitioner to vim, I have to recommend cream (http://cream.sourceforge.net) as a wonderful stopgap. Essentially, it's a set of vim macros that converts vim into a CUA-type editor (i.e. ^S to save, ^Z to undo, mouse highlight, etc). I'm a bit worried that I won't properly learn vim, but I have to admit that it's suddenly become my favorite editor, since I didn't have to relearn all my habits. And, I can pretend to myself that I'll slowly transition over to vim-standard commands.

I did a lot of Unix system administration and for Unix sysadmins vi is still very useful (most servers do not have x11) and I know it pretty well but to say that there is no progress in computers like somebody here did because it still beats editors like text-mate or bbedit is really more a interesting kind of phenomenon of having invested a lot in learning Vi and not wanting to throw it away and therefor loving because the modern editors are a lot nicer and easier to learn and also a lot more powerful.

I cut my teeth on web design via Telnet using Pico, I've got a lot of 'muscle-memory' there with that application. I have recently learned a few Vi commands for those servers that offer only that!

this seemed like a great opportunity to toot my own horn. being a vi user for many years i didn't see much use to the build-in emacs bindings in cocoa, so i did a bit of hacking and came up with viAllOver. its basically vi bindings for cocoa. it works fine on 10.4 on my intel macbook, you may want to compile it for the intels. i haven't worked on it for a long time, mostly do to lack of interest by others, this seemed like a good opportunity to stir up some interest. it is very basic, few commands, but it works well enough for everyday use. let me know if you want to help out. thanks.

I started out with vim, and it is awesome. These days I'm mostly using TextMate. I still use vim a lot when I'm using Windows, but I have been able to make macros/scripts far easier in TM, plus it's so nice looking.

I've tried BBEdit and many others, but I always go back to VI -- or more truthfully, VIM. Menus are for sissies. Besides, once you get the swing of things, VI is the fastest text editor you can use, and it really isn't all that hard to learn. You can probably learn 90% of it in a few hours of playing around.

Of course, the real power comes from learning regular expressions in VI which can take years to master. But, once you learn the ins and outs of regex, you can apply it across all of Unix.

Oliver: Perhaps you could tell us how text has changed significantly from the days of the "old tools" that should have made things like vim not work well? It has nothing to do with operating systems.

Nothing has changed and that is the problem.

Take source code, for example. The editor should really be able to understand what I am trying to say. After all, it is a language made for communicating with the computer.

Instead, even simple syntax mistakes only show up when the compiler is run.

Best practices and code writing policies could be built in to the editor. Take the idea of templates or themes and apply it to source code editing. I know this is an almost religious topic, but why should every developer have to go through the same mistakes and develop his own peculiarities when in comes to naming conventions and even things like how many spaces are in a tab so that the code looks pretty? A lot of problems regarding "readable code" stem from this issue.

The other most common form of text files (excluding Word docs, and don't get me started on that pile...) is probably config and prefs files. Apple is moving in a great direction with these and ideally there should be a UI for that anyways.

So, I think these "text files" should be pretty obsolete by now. And that is where the OSs have failed.

Indeed Vi (or Vim) is an excellent "old-school" text editor, and sometimes it's the perfect tool for the job. But as I've used TextMate more and more, I seem to find more and more reasons why older tools like Vi and Emacs aren't needed, or even as useful in most situations.
Yes I do know that BBEdit, SubEthaEdit, etc. have there fans, but they really doesn't offer the multitude of functionality, and ease of extendibility you should get with a text editor.
TextMate offers just this. In truth if you know regex's and unix commands there's just about nothing you can't get it to do. So if there's a command you want but don't see you can add it. Anything that can be done at the command line can be done to text or documents in TextMate.

It also handles the issues of of multiple documents easier than I ever feel vi or Emacs has.

Allan, the developer of TextMate, is constantly working to improve TextMate. Plus there's always people making new bundles and commands, so it's functionality is always expanding. I also love Allan's philosophy of putting as much functionality in the bundles as possible. What this means for the user is if you don't like the way a command does something you can just change it.

Finally, if you're using a Mac part of it has to be for the interface of it. And that's just what TextMate does, is it takes the functionality of a unix text-editor and brings it to the Mac Interface.

I now prepare myself for the barrage of flame I am about to get.

Oliver,

I do agree most Linux magazines would scare away a great many computer users. I have toyed with Linux a good myself and, while I can see what makes the platform great and wonderful, I feel it lacks the spartan organization and consistency of an OpenBSD install. Of course, to each his tool and his expectations. As far as systems not evolving much, I am not sure this applies to the entire industry but it certainly applies to branches of it, notably those that, due to their young age are back into the early stages of the experience building cycle.

FJ

Xmanoel,

Simultron is indeed a very interesting application, although I confess I am not a regular user by any means.

FJ

Mike,

It is very true we Mac users love our mice and are not ashamed to use them! ;^)

You are very right in pointing out the power of the keyboard and regular expressions: these are without the shadow of a doubt the true "Power tools" of the computing world.

FJ

Aristotle,

Thanks a lot for the vimtutor tip, it is indeed most interesting. I had overlooked it and am very grateful you put me right back on track.

FJ

John,

It indeed seems forgetting what one just learnt is, as far as Vi and Vim are concerned, very easy, although I expect it holds true of most command-line interfaces and continued use is the best defense against that phenomenon.

Spiritual event? That is definitely an interesting take on the matter and I do tend to agree with you.

I would indeed think running a business on command-line OpenBSD would make it harder to fill some positions. Since we do train our team however I guess it would just be a of changing tutorials...

FJ

William,

Thanks for the tip!

FJ

FARfetched,

BBedit's scriptability, while different in nature than, say, the scriptability of command-line tools leaves absolutely nothing to desire.

Very interesting comment about High-Performance Interfaces! I shamefully confess I missed that particular edition of the podcast... I shall investigate!

Thanks also for the tips!

FJ

Simdude,

Thank you for the tips!

FJ

Michael,

A very interesting remark! Thanks heaps.

FJ

Michael,

A very interesting remark! Thanks heaps.

FJ

Jeremy,

Impressive mastery of Terminal use!

FJ

Jamba,

Indeed... The very fact Vim has been ported to pretty much every platform under the sun is a testimony to its success and the dedication of its following.

FJ

dylan,

Macros can indeed be terribly useful! Thanks a lot for pointing that feature out!

FJ

dylan,

Macros can indeed be terribly useful! Thanks a lot for pointing that feature out!

FJ

Alex,

Hmm, cream, eh? Interesting idea...

FJ

Brian,

No need for flames here and your comment is welcome.

FJ

Well, just some thoughts as someone who drifted through a variety of text editors. I was a long-time user of vim, then recently switched back to emacs. I think one advantage of the older text editors is that they have a very deep base of contributed macros and scripts. So in contrast to what Oliver says, many of the modes that have been added onto vim and emacs include tools for supporting best-practices for many programming languages and html. I'm not especially an emacs zealot but the emacs tools for lisp, python, and LaTeX included with aquamacs were far and above anything else available for OS X. Although TextMate is on my list for the next time I want to procrastinate.

Although if I can get on my soapbox a bit. As much as geeks like me have software and hardware fetishes, the real magic in technology is determined by social processes. The real time/money sink comes from learning and changing processes.

Take source code, for example. The editor should really be able to understand what I am trying to say. After all, it is a language made for communicating with the computer.

Well, yes, and no.

"First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute." -- Abelson and Sussman

Source code is a bit like the standardized jargon that is used in other fields of study, such as math and physics so that ambiguity and confusion can be reduced when communicating ideas between people.

Instead, even simple syntax mistakes only show up when the compiler is run.

Well, there is a reason for this. An editor is supposed to be a general tool -- in order to pick up even simple syntax mistakes you need to throw a scanner on top of it (note that most advanced editors are capable of this as it's just a form of syntax highlighting) and can mark simple errors as invalid. Of course you have to supply the scanning rules for every language in question. And if you want to spot more complex syntactical errors, you'll need to build a generic parser generator into your editor and feed it a grammar description. So now you've got editor + lex + yacc => editor+. But wait! There's more! What if we're dealing with a language like OCaml or Haskell or Qi... we'd sure like to be able to import their type-checking systems into the editor, right? I mean, it's a computer program... it should be able to understand when I've got a type error too...

Eventually you end up with an editor that has to be able to embed the compiler (or at least the first few stages thereof) of any language into it -- a bit like a Smalltalk for all seasons. Isn't it far better to simply allow your simple editor to talk with something like a Lisp REPL, or the OCaml toplevel interpreter to perform the syntactic and type information analysis for you?

But no... that's got to obviously be the wrong approach, as the simple communicating processes model is old school Unix. Yech! Phooey!

Best practices and code writing policies could be built in to the editor.

So who decides on those best practices?

But yes, one could for example, store the code in a more abstract form -- awash in a sea of XML or whatever. The resulting tag soup could later be presented according to some set of translation rules specified to the editor. Of course, then you have to have some way to pull the code out of the soup before feeding it into the compiler or sending it to someone whose editor is an archaic old thing... yep. Sounds like we need a specialized process that our editor could communicate with over channels. Where have I heard of that before?

The other most common form of text files (excluding Word docs, and don't get me started on that pile...) is probably config and prefs files. Apple is moving in a great direction with these and ideally there should be a UI for that anyways.

Oh please tell me that you're not talking about Property List Editor here...

So, I think these "text files" should be pretty obsolete by now. And that is where the OSs have failed.

Again, I fail to see the connection between OS and text file. Yes, the current OSs all support (and in many cases require) text based information transfer, but you've not been able to show that they are obsolete for bridging the communication gap between humans and computers (and human to human as well). If you have any ideas for this, or could point to any research that seems to be making useful progress, I'd love for you to post about it here on macdevcenter. But simply bemoaning that we "should" have outgrown this by now isn't a very effective argument.

William hits on a lot of points about why editors don't do what Oliver wants. If you want that type of thing, go for an IDE - Eclipse has plenty of language bundles, lots of people love Visual Studio.
Personally, I find myself still using an editor over an IDE, but I've been programming since 1982 and old habits die hard. I'm obviously not alone as there are many people who continue to favour text editors. And I'm still as productive as some of my IDE using colleagues - provided you can develop as fast as you think, and you don't feel your tools get in the way, then that's all that counts.

Something that IS worth noting is that with dynamic languages, even having access to the compiler wouldn't help the editor, in that the nature of some objects is unknown till runtime. Or consider the issue of languages like Javascript, which don't even have a consistent syntax (the editor would need to know about IE5,6,7,Firefox,Safari and Opera's separate implementations of Javascript in order to show errors).

Something else worth noting is that nothing could be terser than regexp at doing the same job. Terseness = high learning curve but good productivity. It would be possible to make an editor that understood 'For all lines with the word Geoff in them, substitute London for New York' but I can't think of a way of doing it with more economy than regular expressions.

Textmate - from what I understand, it was developed by a former vi user??

Config files : Moving from binary formats to XML is a step-forward in my book. Sure it's bloated in terms of space, but it takes things from machine readable to human readable.

simple syntax mistakes only show up when the compiler is run.

Syntax highlighting sometimes highlights syntax errors -- on a couple of occasions, I've realized I missed a quote in an awk script when Vim colored all the text on the next several lines. I agree that a general solution would mean building a parser for every language into the editor (talk about code bloat!), but sometimes syntax highlighting is enough.

I spent a long time on unix systems using vi. When vim became widely available, I started using that. I've tried emacs (including viper, its vi emulation package), and I find I just like Vim better. One advantage of vim that hasn't been noted yet is community support. The newsgroup news:comp.editors, the vim mailing list, and the yahoo group http://groups.yahoo.com/group/vim/messages all have a large and very helpful set of users. Usually, I can find out what I want just by searching old messages.

Some people have criticized Vim because it doesn't provide enough programming language support. This is by design; the user community of vim as a whole does not want vim to try to be all things to all people, like emacs. The emphasis is to make vim a great all-purpose text editor, and they have succeeded.

Making the choice to use Vi/Vim is a choice to use a true professional editor. Many people take it at face value, and deduce that it's an outdated relic... this is not the case. I've been using Vim since college, and I have yet to find any editor or IDE that can match its power. Not to mention... Vim exists on every major OS, so you get to learn once, use everywhere.

JMC,

Thank you for sharing your comments and feelings.

Constructive criticism is always welcome here on the Network. Please refrain from using uncouth language however. Everyone here has the best of intentions: let's keep it that way.

FJ

Interesting comments.. :D