Live data from Hacker News

The Grammar of Vim

rc3.org

31–38 of 38 posts

Re: The Grammar of Vim

#31
post #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 rep…

> Yeah, I know, useless comment when it takes both sides of a point

Incorrect. Given a subjective question, the most useful comments acknowledge and consider all possible answers according to their due weight.

Re: The Grammar of Vim

#32

Does emacs have a consistent grammar like this? I use vim, but have been interested in learning emacs too. However, every time I startup the emacs tutorial, I immediately start missing the vim's semantic grammar. Have I just not gotten far enough into emacs to discover that yet?

Not as such, though many commands can be prefixed by a "universal argument" count; "C-u 5 C-n" means "move forward 5 lines", just like "5j" does in vi.

In Emacs terminology, many vi commands can be followed by a movement command, in which case they act on the region from the current point to where the movement ends up. Instead of saying "dw" (delete forward-word), you'd use something like "C-space (mark position) M-f (forward-word) C-w (kill-region, AKA 'cut'). There are many semantic movement commands, acting on the space travelled just isn't automatic.

Re: The Grammar of Vim

#33

I suspect there's an opportunity/lesson lurking here somewhere. One of the biggest complaints devs have about tools is responsiveness. The more responsive a tool is, the higher time-density of information available to a developer. IDEs tend to suck in this regard, but Vim positively shines. Many people advocate Vim because it tends to shine in this department, even though they may not consciously realize it. Responsi…

I have Eclipse, Netbeans, Monodevelop, and Geany right now on 12.04. And besides having some ridiculous start up times (like, ~10 seconds, then again I have this test 12.04 partition on an old IDE hard drive from 2001. "shades" I must just be a daredevil...) they are pretty snappy, and I imagine any responsiveness shortfalls are JVM disk IO, so an old IDE drive with 60 mb sequential read / write is about as bad as it gets, and I don't lose productivity to slow software with them.

Re: The Grammar of Vim

#34
post #31
post #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 rep…

> Yeah, I know, useless comment when it takes both sides of a point Incorrect. Given a subjective question, the most useful comments acknowledge and consider all possible answers according to their due weight.

That's a nice thing to say, thanks. As I kept editing my comment, I kept thinking "Pick one side and stick to it... but I can't!"

Re: The Grammar of Vim

#35

Earlier quoted context omitted.

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, i…

> What I think the programming environment world needs (not just vim) is a standard way for user interfaces to talk to tools. Brilliant, that way the ultimate IDE is simply your desktop. Coming from linux, given the choice between an IDE and a bunch of shell windows running vim, gcc/g++, make, gdb, etc., I've always picked the latter. But it's missing tool communication. Now if we had some standard based on IPC that…

This is basically all that emacs provides: glue between programs, and maybe a really thin GUI layer for interacting with them.

Which, as I'm sure many will ravenously point out, leads back to the "encapsulated environment" problem; emacs then integrates these disparate programs so tightly that I'm now locked into it.

Post reply on HN