Hacker News new | comments | show | ask | jobs | submit login

I love Vim. I understand the 'Vim is a language' concept, and use it every day.

But I have to wonder: is this the best that Vim can do? Vim as a language is a great concept. But IMHO, the execution sort of sucks. Twenty years have gone by, and 'Vim as a language' is still a big mystery that takes a long long time to understand...

Someone should take that concept and run with it. Surely 'editor as a language' can be done better.




One way to improve stuff would be to show you how you could have done stuff more efficiently.

For example if you press v and then repeat l until you're at the end of the word, and then do something with the selection, vim (or a plugin maybe) could tell you 'hey, you could have done that with ve (e moves to the end of the current word)'.


Perhaps in the form of a thought balloon emitted from an anthropomorphic paperclip.



The idea that really excites me is 'STRUCTURE editor as a language' - that is, the same sort of grammar as Vim, but manipulating semantically meaningful structures like expressions or functions instead of text. I'd love to see an editor reenvisioned completely around that concept, with "normal" text editing only as a fallback.

(Of course, Vim does have text objects, which are fantastic - one of the chief reasons I use Vim. But they have limitations; I think you can go a lot further.)


Take a look at the E editor, it marries Vim's exceedingly efficient editing language with semantically meaningful text objects. http://en.wikipedia.org/wiki/E_Text_Editor (The website seems to be down, which is a shame)

Or if you have days to burn, emacs+paredit+evil can russtle quite a few jimmies if you take the time to define some custom keybindings for it.


The significant development there is to efficiently work with ASTs for the different languages. Maybe the only reason that kind of implementation isn't shared is because it is typically rolled into commercial IDEs rather than being opened up and exposed in a way that is accessible to existing editors.


Ah, nevermind. I totally misread your comment. Not deleting my comment for the link to the Paredit video.

Paredit would be a step in that direction: http://emacsrocks.com/e14.html

I also recall editors of old having that functionality (Zmacs?).


Paredit is super great, indeed. Lisp is perfect for this sort of thing.


I think that's genius! Languages have parallel syntax structures in common, more often than anything else!


so have I got a deal for you :) Anyway, my recently published "nestgrid" framework is precisely that (among other possible uses). A mix of xml editor, spreadsheet, direct manipulation of objects ui, and all around cool thing; flash demo included. See http://nestgrid.wordpress.com/nestgrid-paper/

EDIT: fixed url as per @nocman's advice.


You muffed the URL -- here's the one that works

http://nestgrid.wordpress.com/nestgrid-paper/

:-D


This looks really interesting! I look forward to reading through it tonight.


Someone has taught Emacs how to converse in the language of vim: http://gitorious.org/evil/pages/Home

Believe it or not, Emacs is quite a fluent speaker. I was surprised to find that even esoteric things like rectangle selections work perfectly and :%s incrementally showing the results of your search and replace as you type is a hoot.

Sure, emacs has its own accent and quirks, but after using emacs+evil as my only text editor for the last year, I'm now convinced that emacs is a better "vim" than vim itself is.

I could go on and on about how using evil+emacs brings vim keybindings to my editor, mail client, music player, IM client, etc which vim could never provide. I could talk about how wonderfully extensible elisp is for hacking up Emacs' core internals. But at the end of the day, I only use emacs+evil because it's an environment that I'm comfortable with.

If you have a few days/months/years to lose yourself down this rabbit hole, why not give it a try?


After a few years of just vim, I now also use emacs+evil as a better vim.

The way emacs handles indentation is already a huge improvement.


Any language takes some time to understand and even more to use effectively.

Understanding Vim's nOm command pattern is pretty easy (repeat n times operator O to text motion command m moves over). But using it effectively takes some practice. Committing it to muscle memory takes about 6 months (same amount of time it takes to master touch typing). You cannot do this faster.

Becoming an expert (which means not only effectively choosing and using commands to transform some text, but knowing a decent subset of entire functionality and also knowing how to extend the functionality) takes even more time.

And if your language were that primitive that mastering it can be done in a day or two, would it really be that complete and high level enough?


That wasn't true for me. Working through vimtutor for vim and the `C-h t' tutorial for emacs, followed by some spaced repetition over the next few weeks, got the basic motion commands of both editors fully ingrained in my muscle memory. It took longer for my fingers to internalize using operators on text objects in vim, but you can definitely master the basics in a few days. Even though I use vim as my daily editor and haven't really used emacs (at least with emacs-style keybindings) since working through the interactive tutorial years ago, it only takes me a few seconds to get comfortable navigating an emacs buffer without having to think.

Granted, emacs keybindings deliberately don't constitute a language (the whole point of emacs is to remap them for different functionality in different contexts), but I don't think it took me much longer to "become an expert" at vim's language of editing.


Wow! That takes guts. I just gave up and switched to vim keybindings in all my editors and bash.


Lispers and Smalltalkers would tell you: Maybe, if you're lucky.


There's a lot more that the language of Vim can do than what's in this article. You should check out this screencast on vi/vim's command/text equivalence (analogous to LISP's code/data equivalence): http://blog.extracheese.org/2010/11/screencast-custom-vim-re...

Also, this thread's article doesn't go into keys like ftFT;,#* or the incredibly useful Vim-specific feature called text objects. This gives a good introduction to a lot of that: http://www.viemu.com/a-why-vi-vim.html


I am a Vim user too! Because of my curiosity, I tried Emacs and I was amazed how easy it is for beginners! There are very simple quick-start guide that don't force to use all the great features just yet. And all things that can be confusing for beginners are turned off by default. We can learn something. :)

Also, I like to think that Vim is not an editor. It's a language or, you may even say, a concept of editing text.


I think vimtutor does a good job as a quick-start guide.


The mouse is a much easier language to learn and more versatile (it took me fifteen years to become as fluent with the trackpad as I got in a few hours with a mouse). It doesn't make you think you're more productive, but it does actually make you more productive. (See "Tog on Interface".)

The fact that die hard vim users are amazed whenever they learn a new trick they never encountered in ten years of using vim every day speaks for itself. (And happy mouse users look at the obscure shortcut for incrementing an integer and shrug.)

OK — mod me down into oblivion.


Sometimes, the mouse is all you need. That's understandable.

Other times, what you need, is to append a certain string to every line in the text containing a certain regular expression. Other times, you need to delete a column of characters and move that column somewhere else.

Vim (and emacs) is not about the most common keystrokes. It's about every other obscure and relatively rare task that comes up, that in total, add up to become a huge chunk of the working programmer's time. Yes, adding characters to the beginning, middle, or end of a line is easy without vim. Yes, moving up and down paragraphs or around the file can be done without vim. The power of vim is not manifest in these simple maneuvers, but in its expressiveness in handling every other exceptional case.


Every time a vim or emacs user tries to convince me of the virtues of their insanely "powerful" editor I ask them to demonstrate a use-case and have yet to be impressed by a single response. Every example in the stack overflow thread leaves me bored -- if you like tinkering with macros rather than actually getting something done, enjoy your "language". This is the old command-line versus GUI argument writ small.

What I like is watching the vim or emacs advocate show me their macro examples and then showing them how BBedit (for example) leverages regexp (and provides lots of learnable shortcuts, macros, and scripting support) while getting you enormous benefits out of the box because it uses a mouse.


The difference between CLI and GUI is simple. The latter is highly optimized for a particular workflow and to perform a set of preconceived tasks that are baked with a release that gets an occasional update.

If you asked me to show you why I find value in editors like vim and emacs, I'd show you a DSL I wrote for work purposes and show you the extensions I wrote to edit them efficiently. Alternatively, I'd show you a number of customized workflows for cross compiling lua to C# or something.

I've used sublime text, textmate, bbedit and I'm not saying they aren't well designed editors. They are and if the stuff you are doing is stuff that everybody is doing, then great. But I don't think you understand that at this point in time, none of these GUI-based editors come even close to satisfying my personal needs as a developer.


You realize that vim also uses a mouse?


Although I'm a Vim user I appreciate your comment and think you have a good point. However, I can't stand when a commenter anticipates a negative reaction to their post and dares readers to downvote them.

Of all the communities online, let's have faith that at least on HN a well-argued comment will receive recognition whether or not it reflects a popular opinion. To bait downvoters is to imply that this community prizes popularity over integrity, and in doing so polarizes the discussion.


Don't see it as a dare. See it as reverse psychology.


> a long long time to understand

No. The vim language has a simple and easy to understand grammar that is very close to that found in many natural languages. That part is freaking easy to grasp. The vocabulary is a lot bigger, though, but like with natural languages, you can be a perfectly functional speaker/user without knowing everything there is to know. As long as you make yourself understandable and know how to use a dictionary you are fine.

And, like with all natural languages, practicing, making mistakes… are keys.


vim is not for everyone and if it was too easy, it would probably be limited, perhaps even loose some respect. To attain a certain high level of usability things naturally start becoming more complex.

>Surely 'editor as a language' can be done better.

everything can always be done better, but its a matter of doing. When the doing starts, it will appear that its not as easy in execution as conception.


The thing is that vim is actually pretty simple to learn. The arrow keys still work. in macvim you have a high level of usability out of the box with mouse support enabled, copy and paste from the system pasteboard using normal keys, etc....

Even if you are using vanilla vim you can learn the basics of how to edit a file to notepad levels in about 1 min. (command line vim "new file name", press i, use as a normal editor, press escape, press :wq)


vim -y starts vim in "easy" mode where vim essentially behaves like dumb editor like Notepad++ would. And even in terminal (at least in OS X with iTerm2) you get mouse support for cursor positioning and visual selections.


whether vim is respected obviously does not matter as long as it works better


> not as easy in execution as conception

Nobody said it'd be easy


I am only interested in hearing about this from people who already actually understand vim. It is not that hard to understand, but if you do not understand it then you are just going to produce something else you like and fail to capture what worked in vim.


On the contrary, I think people who are already comfortable with vim have a harder time identifying the pains of learning it.

There are many problems that started out as pains but are second nature to us now, so we don't think to optimize them.

I remember spending a ridiculous amount of time trying to figure out link and include paths to add a new library in visual studio when I was a new programmer. Doing so now is so easy I hardly need to think about it, but in reality it hasn't gotten any easier. I am simply familiar with the process.

Really, installing a new library should be as straightforward as installing an extension in a web browser. There is little essential complexity there, and yet this process has not become easier (in C/C++) for decades.

Anyone who knows enough about how to solve the problem has already groked it and isn't interested in solving it anymore. This is the problem I see with wanting an improved vim from someone who is already a vim expert. The problems they have with vim are disjoint from the problems a new programmer would have with vim.

What I will say is that if you are going to create a new editor, by the time you are done you should have become an expert in all the major text editors. You're absolutely right that any new editor should have seriously considered the features available in vim and emacs and others. However I have no problem with someone who isn't an expert getting inspiration to create their own editor out of their frustrations with vim. Many great things were stared in similar ways by people who weren't experts (yet).


I agree. I have been using Vim for the last three years but never actually realized its commands were constructed with such a rationale.


It could be argued that sam did it better (or acme, but it used sam's language, so it amounts to the same thing).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: