Live data from Hacker News

The Grammar of Vim

rc3.org

11–20 of 38 posts

Re: The Grammar of Vim

#11
post #6

Earlier quoted context omitted.

I am increasingly disappointed in all those Vim 'emulators'. VsVim, jVi, ... They aren't vim, no plugins, no real customizations. I really like that they exist, but it could be better. We need the REAL vim in an IDE, not some vim functionality.. EDIT: I use VsVim and you can disable it with ctrl+shift+F12. This helps when working together with other people..

Now THIS is a great idea. vim lacks a lot of modern features, and the fact that it has to be compatible with running on shells means that it can't implement a lot of things which you would need to make it look and feel like a normal editor. For example, we'd need the ability to make windows that are only part of the screen, in order to make convenient popups (for, say, ctrl-p find in files actions). We'd need the abi…

Did you try https://github.com/carlhuda/janus ?

Re: The Grammar of Vim

#12
post #7
post #4

I've been reading through the brand new Practical Vim by Pragmatic Bookshelf, it goes pretty in depth in this and much much more: http://pragprog.com/book/dnvim/practical-vim

What is the level of the book? Is it worth getting if I'm a pretty heavy vim user already, or is it more of a beginner's guide?

"if you master the techniques in this book, you’ll never need another text editor. In 120 Vim recipes, you’ll quickly learn the editor’s core functionality"

If you're a heavy vim user then you probably already know the editor's core functionality.

"and tackle your trickiest editing and writing tasks"

But wait! Tricky tasks. It's for everybody!

Re: The Grammar of Vim

#13
post #6

Earlier quoted context omitted.

Now THIS is a great idea. vim lacks a lot of modern features, and the fact that it has to be compatible with running on shells means that it can't implement a lot of things which you would need to make it look and feel like a normal editor. For example, we'd need the ability to make windows that are only part of the screen, in order to make convenient popups (for, say, ctrl-p find in files actions). We'd need the abi…

Most of this can be done with Vim already... And the stuff that can't, like graphics, popups... I don't care for. How would you control that sidebar? With the MOUSE O.o !? I like nerdtree exactly because it's a buffer, because I can navigate it like my text. The essence of my comment above is that I want this in my IDE's, not the other way around.. Also: vim has tabs (:tabnew)... And there are search plugins for vim,…

I'm not blaming you specifically, but this is the problem - anytime someone points out something that could be better with vim, people jump in to show "yes vim CAN do that". And they're right. It's just that it's done worse, and takes a lot of setting up to get right.

To elaborate on the "worse" part, there are a few problems right now:

1. The plugins don't interact nicely with each other. For example, NERDTree exists, but it doesn't always play nicely with other plugins. Keeping it always stuck on the left side of the screen, taking up the same space, is not possible. If you use fuzzyfinder, for example, running fuzzyfinder from withing the NERDTree buffer will open the new buffer INSTEAD of NERDTree. This is never what I want. For another example, try jumping to a saved mark across files (e.g. 'V) from within NERDTree.

This is not even getting into plugins that will create new windows, and screw with your window layout, including messing up NERDTree.

In my vision, I would want to have a sidebar, make it keyboard-controllable of course, just make it "outside" of the actual vim, letting you control it absolutely. This is just one example.

2. The second problem is, vim looks bad. I'm sorry, but little graphical conveniences just don't exist in vim, and it is often the worse for it. For example, open Sublime Text's "find if project" drawer. It looks much better, is better convenience-wise, and it's something I use 200 times a day - I want it to be perfect. The fact that the drawer appears in the top-left, has a larger font-size, uses bold properly to make it clear what you're selecting, etc., is something that is just plain BETTER.

3. As for the current solutions to some of the things you mentioned:

Find file in project plugins: Yes they work. They don't look nice (see point 2 above), but they do exist. However, you have a choice between:

- Command-t, which is annoying to set up (don't take my word for it - look at the list of users who rant and rave about how good ctrl-p is, because it is easier to set up!).

- Ctrl-p - awesome (I use this one), but often slow. Especially when I want to display 50 results at a time (I have a large screen, I want to USE it). Coloring all the results is slow, and I'm not on a slow machine or anything. I'm not even talking about the indexing time, which luckily for me isn't a problem with my currently small projects.

- FuzzyFinder - nice, but looks terrible, and has a lot of funky behavior. E.g., the NERDTree mess (ctrl-p avoids this by writing code in the plugin to detect "common buffers" and not load things into them - not a scalable solution).

As for tabs, sure, vim has tabs - except they're not supposed to be used like the tabs everyone is familiar with, because that's what buffers are for. They're more for "workspaces". Forget the terrible naming of a feature which is similar, but different to what everyone else in the world means when they say "tab" - there are still no good ways to show which files you have open. It's not a killer feature, but a convenience a lot of people would like.

Summary: Let me get this straight. I love vim. I adore it. I kind of hate it, because having used vim, I can't find myself liking anything else - even my beloved Sublime Text 2, which is an amazing editors, frustrates me for lack of vim features.

The reason I write all of this is because I want the editing experience of vim, but the "everything-else" experience of Sublime Text 2 (or any modern editor). That would be an amazing thing.

Re: The Grammar of Vim

#14
post #3

I have been using Vim for a few years. I recently installed a trial version of ViEmu plugin for Visual Studio. With Vim inside my main IDE at work, I have the chance to really master it. But I ran into an unexpected hiccup - nobody else can use it when we're collaborating on code! Sadly, I think this might be a big enough reason to remove it.

I just disable ViEmu whenever other people sit down at my keyboard. The switch is right up there in the menu bar.

More recently though, I just open up Sublime Text and have them work in that. My computer, my rules.

Re: The Grammar of Vim

#15
post #7
post #4

I've been reading through the brand new Practical Vim by Pragmatic Bookshelf, it goes pretty in depth in this and much much more: http://pragprog.com/book/dnvim/practical-vim

What is the level of the book? Is it worth getting if I'm a pretty heavy vim user already, or is it more of a beginner's guide?

I'd say the best way to learn more about vim if you are already a heavy vim user is to join both the vim-dev and vim users mailing list in google groups. People post questions in the vim user mailing list every day and I've learned many new things just by reading the answer that other people gave.

Re: The Grammar of Vim

#16
post #6

Earlier quoted context omitted.

I am increasingly disappointed in all those Vim 'emulators'. VsVim, jVi, ... They aren't vim, no plugins, no real customizations. I really like that they exist, but it could be better. We need the REAL vim in an IDE, not some vim functionality.. EDIT: I use VsVim and you can disable it with ctrl+shift+F12. This helps when working together with other people..

Now THIS is a great idea. vim lacks a lot of modern features, and the fact that it has to be compatible with running on shells means that it can't implement a lot of things which you would need to make it look and feel like a normal editor. For example, we'd need the ability to make windows that are only part of the screen, in order to make convenient popups (for, say, ctrl-p find in files actions). We'd need the abi…

You should check out macVim. There's a build available with a real gui project tree, and it has regular GUI tabs that you want. I use it occasionally, but I like having everything in one place with tux panes:)

Re: The Grammar of Vim

#17
post #6

Earlier quoted context omitted.

I am increasingly disappointed in all those Vim 'emulators'. VsVim, jVi, ... They aren't vim, no plugins, no real customizations. I really like that they exist, but it could be better. We need the REAL vim in an IDE, not some vim functionality.. EDIT: I use VsVim and you can disable it with ctrl+shift+F12. This helps when working together with other people..

Now THIS is a great idea. vim lacks a lot of modern features, and the fact that it has to be compatible with running on shells means that it can't implement a lot of things which you would need to make it look and feel like a normal editor. For example, we'd need the ability to make windows that are only part of the screen, in order to make convenient popups (for, say, ctrl-p find in files actions). We'd need the abi…

I would like to respectfully suggest you have it backwards.

I agree a lot of that stuff would be nice with vim, don't get me wrong, but I think we don't need an IDE layered on top of vim, so much as we to do some work on DEintegrating the development environment.

I'm not advocating for getting rid of all-in-one tools, I've seen the power of VS and IntelliJ etal in competent user's hands, they are fine envrionments, if that is your preference and it makes you productive, then awesome.

What I think the programming environment world needs (not just vim) is a standard way for user interfaces to talk to tools. Right now if you come up with a great way to auto refactor code, or do inline static analysis or build tool chains or whatever, you have to target a specific environment, or redo a lot of work to have it work available in multiple tools. However if there was a standard api or protocol, the same code would work for all developers and you could focus your effort on making the tool that much better.

It isn't immediately obvious to me how this would work, and I've been thinking about it off and on for a while now, but I think it could be a major benefit to the world, in the way http/html have freed up a lot of the nonsense around programming interfaces for users in a cross-platform way. My thinking right now is being largely influenced by the git model of "plumbing" and "porcelain" command setup, where the "porcelain" is the editor/environment tool.

Anyway, I probably did a poor job of explaining my thinking, it being saturday morning and all.

Re: The Grammar of Vim

#18
A link, or links much like this describing the "grammar" of Vim, gets reposted every few months, which is probably fine because it's a good thing to learn and share, but it would be nice if there were a HN "Hall of Fame" which would prevent reposting things like this over and over and over again. It could have either posts, or "concepts" with some of the more popular posts about Vi/Vim/etc, Emacs, C++, etc.

(What reposts, you say? I was thinking of http://news.ycombinator.com/item?id=2911930 or http://news.ycombinator.com/item?id=3361993 linking to Yan Pritzkers original post, referenced in parent link. But to be fair, they are different posts, not truly reposts.)

(However, there's also value in serendipity of new users "discovering" great links, so perhaps we can just leave well enough alone. Yeah, I know, useless comment when it takes both sides of a point).

Re: The Grammar of Vim

#19
post #9
post #7

Earlier quoted context omitted.

What is the level of the book? Is it worth getting if I'm a pretty heavy vim user already, or is it more of a beginner's guide?

Same here. Need something for advance vim users.

IMO once you get past knowing the core stuff on an editor, the next frontier is scripting. If you would consider yourself advanced in vim, I would suggest starting to learn VimL

Re: The Grammar of Vim

#20
post #2

True but I'd say this verb-noun idiom only accounts to 15% of the user manual. For instance learning fold commands za will tell you nothing about other commands using 'a'.

Text objects are the core of editing though, stuff like z or all the g commands are more situational. I replace the contents of a string (ci"), delete a word (daw), copy the contents of an array (yi]), etc WAY more often then things like folding
Post reply on HN