Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim for Humans

vimebook.com

Post reply on HN
Print view View original

241–250 of 251 posts

Re: Vim for Humans

#241

Post by masukomi »

satai wrote: post #200
userbinator wrote: post #184

Earlier quoted context omitted.

I use Ctrl+[ instead of Esc, since I find that far faster and requiring less hand movement. I notice from observing other people type that there is an aversion to moving hand position, whereas the idea of moving hand position is not unfathomable to me, perhaps as I have played piano and violin. I'm not averse to moving hand position, and I don't use the strict one-finger-per-key rules either, but I do try to minimise…

Nice trick: remap Capslock to Esc.

I find that people who consider remapping capslock to anything else are people who don't know how to touch type. If you are in that camp I would strongly recommend spending the time to retrain yourself to learn how to touch type with home row position. You'll find that the capslock becomes a much more valuable key. You'll also find that your wrists are happier. It's an annoying time investment,but it's a valuable one. I combined it with switching to Dvorak... which really hampered my typing speed for a couple weeks but also helped improve my wrist happiness.

Re: Vim for Humans

#242

Post by vlunkr »

gravypod wrote: post #111
vlunkr wrote: post #52

Earlier quoted context omitted.

Just curious, what editor(s) do you use? I was using Sublime Text, and for the hardest part of switching to Vim was feeling the huge productivity drop in the beginning as I relearned how to do everything.

I used sublime for a bit, but I didn't like getting nagged. Right now I'm using some JetBrains products and Nano. I sketch everything out into nano, then I pull it into CLion when it's ready to be cleaned, updated, iterated, and in general changed to become a "final" version.

JetBrains products aren't free either...

Re: Vim for Humans

#243

Post by malnourish »

alphapapa wrote: post #116
malnourish wrote: post #31

Earlier quoted context omitted.

Incorrect according to whom? If you can understand it, it's not incorrect. You might not like the style, but that doesn't make it wrong.

> If you can understand it, it's not incorrect. acn yuo stunderand htis? i no oyu cna so acocrding ot yuo its nto rwong. oaky.

That's clearly not what I meant. Grammatical prescriptivism is considered incorrect by pretty much any linguist.

Re: Vim for Humans

#244

Post by edoloughlin »

gbrown_ wrote: post #3

I've only skimmed this but there seems to be a focus on customizing and plugins from the get go. I think it's worth getting to know Vim "as is" before doing such things. Indeed there certainly some things that aren't the most useful or obvious but it's good to understand their original intent. Not to crap on the author of this but I'd recommend Drew Neil's Practical Vim over this (and pretty much every other Vim book…

> there seems to be a focus on customizing and plugins from the get go

This is understandable. Coming from Emacs, I need an equivalent of projectile to stay productive while learning.

Re: Vim for Humans

#245

Post by flukus »

Annatar wrote: post #239
flukus wrote: post #237

Earlier quoted context omitted.

Windows doesn't treat them in an special way either. You can open a text file with any/no extension.

You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types , and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating in…

A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.

Re: Vim for Humans

#246

Post by mreiland »

gepoch wrote: post #91
Philipp__ wrote: post #68

It took me a while to realize what really vim is for. What led me to realization was switching to Emacs. I read this post, and second checkbox says "modern customizable IDE". And I stopped there. Why you may ask? Well, I used Vim for 3 years before trying Emacs this spring. And I loaded it with all the heavy plugins(YCM), but Emacs led me to realization that Vim is more of an editor than IDE. Even with plugins I thin…

I will add some of my own opinions: My feeling is that real value of Vim is its novel approach to modal text manipulation, and you shouldn't let the fact that it has a standalone lightweight reference implementation usefully installed on almost every machine that you use confuse you. Vim script is not a great plugin language, and the vim runtime itself is not fantastic at doing things beyond the text editing. I think…

I've never found a vim emulator in another editor that felt right. It's always a second class citizen and there's always something that breaks the illusion due to the way the vim keybindings interact with some other part of the editor.

I prefer to not use vim emulators in non-vim software specifically for that reason.

Re: Vim for Humans

#247

Post by mreiland »

pmoriarty wrote: post #152
Philipp__ wrote: post #68

It took me a while to realize what really vim is for. What led me to realization was switching to Emacs. I read this post, and second checkbox says "modern customizable IDE". And I stopped there. Why you may ask? Well, I used Vim for 3 years before trying Emacs this spring. And I loaded it with all the heavy plugins(YCM), but Emacs led me to realization that Vim is more of an editor than IDE. Even with plugins I thin…

I don't think it's true that vim "just doesn't even come close to Emacs" . They each have their strengths and weaknesses. As bad as the defaults for vim are, they're even worse in emacs (IMO) -- especially for former vim users (though I haven't tried spacemacs, which is supposed to make things automagically a lot more comfortable for people coming from vim). Evil mode helps a lot, but even with evil, most commands in…

I considered switching to Emacs once, but the slower startup time was a complete deal breaker for me.

Emacs isn't even really slow at starting up, it's just noticeably slower than vim and I have this thing about editors that are slow to startup... I use notepad as my primary text editor on windows because it starts up instantly.

Re: Vim for Humans

#248

Post by Annatar »

flukus wrote: post #245
Annatar wrote: post #239

Earlier quoted context omitted.

You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types , and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating in…

A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.

No they do not, what in the world gave you that impression?

UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expect the OS to work.

Even so, a desktop environment on UNIX is just yet another application, sometimes it is just a single process. The operating system empathically does not provide any kind of file type recognition or handling for such a desktop environment application, and any such file type recognition and handling is proprietary to that application.

Since the core UNIX paradigm is one of everything is a file, and all files are nothing but a stream of bytes, the OS has no concept about the contents .h, .c, not shell scripts, let alone .wav, .au, or .mp3 files, for instance. The UNIX operating systems only deliver streams of bytes at the request of applications via the open(2) and read(2) system calls. That's policy. The mechanism of what applications (consumers) of that or those byte streams do with the stream is left up to the applications which consume the streams:

A Unix File Is Just a Big Bag of Bytes

A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.

http://www.catb.org/esr/writings/taoup/html/ch20s03.html

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...

Re: Vim for Humans

#249

Post by flukus »

Annatar wrote: post #248
flukus wrote: post #245

Earlier quoted context omitted.

A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.

No they do not, what in the world gave you that impression? UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expe…

> No they do not, what in the world gave you that impression?

Using desktop environments. If I click on a text file in KDE, it opens in kate. Same with every other linux desktop I've used and same one mac.

You're yet to say a single thing that doesn't apply equally on windows and unix.

Post reply on HN