Live data from Hacker News

Porn, Zen, and .vimrc

karolis.koncevicius.lt

121–130 of 131 posts

Re: Porn, Zen, and .vimrc

#121

Earlier quoted context omitted.

I have exclusively used vim keys for years now, but even after that time I find some of this just doesn’t ring true. Anything in vi that involves counting some number is usually faster with normal keys or the mouse. For example moving down 20 lines is way faster with the mouse, you just click. With vi you have to count the lines in your head - better hope you don’t lose count half way because two lines blur together.…

You don't have to count. I typically make a rough estimation and go from there. For me that still is faster than putting hand on mouse, searching current cursor position, aim, click, and back to proper keyboard position. Of course ymmv

I remember in grade school where we practised turing to an approximate page in a book. I always think of it like this.

Re: Porn, Zen, and .vimrc

#122
post #83

Earlier quoted context omitted.

All it’s missing is ‘set expandtab’ ;-)

Noo I like tabs! Maybe you can explain to me, I genuinely do not get why people are religious about spaces instead of tabs. You have to backspace more times to get rid of an indent!

Tabs are better in theory, obviously.

However people insist on using spaces. Like between words in sentences or between tokens in a line of code.

Spaces are better than mixing tabs and spaces, especially with "modern" (newer than 30 years old) tools. Especially if you use these editors enough that you are never indenting manually with backspace or tab/spacebar.

So the options are tabs+spaces mixed together or just spaces unless you are dealing with tab delimited files with no spaces in them, which is rare.

The tradeoff is you lose the ability for different people working on the same thing to see different indentation levels. In exchange you don't regularly get your formatting confusing messed up because of some kind of invisible control character confusion.

Re: Porn, Zen, and .vimrc

#123

Bro I don't mean to make you the shining example of what I'm talking about but can we please try to be succinct with write-ups? The whole first half of the article could've been summarized with a single sentence: "As is typical with newbie vim enthusiasm, I spent many hours producing a 1000+ line vimrc over a long time that I eventually realized complicates my word editing process more than it helps." I mean come on.…

I found it informative and enjoyable to read. I'm glad it had the details that it did and would have gotten less out of it if those details had been omitted.

Of course it's fine to value succinctness, but it sounds like your saying the author did something wrong or that he owes you something. Maybe "I found there were too many details and would have preferred it was much more succinct; for example..." would have been a better tone than "can we please try to be succinct"?

Re: Porn, Zen, and .vimrc

#124

I personally find vin to be a good tool for editing text without leaving the terminal. But when I’m writing a lot of code, I’ve found the vim ide concept to be far more trouble than its worth. Modern IDEs like VSCode + Vim bindings is my preferred platform

I wouldn't call VSCode an IDE. It is an editor with plugins that give it IDE features. If that's your goal, you can really customize vim to similar place. VSCode is at the edge of an editor and an IDE though, or so is my feeling at least. I feel like the massive need for ease of use and speed clashes with the needs of power users (e.g. for Java EE or database developers), and that this push vs pull might to be the do…

You’re being downvoted because that’s nonsense. It comes built-in with formatting, intellisense, a terminal, a debugger, Git support, and syntax highlighting.

Secondly, trying to discern between an “IDE” and a “text editor” in 2020 is a fools errand. It’s pointless because there’s such a grey area between where one definition starts and ends.

Re: Porn, Zen, and .vimrc

#125
post #17
post #7

> This article describes my Vim journey, starting from heavy personal customization and ending with a renewed love for defaults this exact pattern is found in so many vi|m articles and is touted as a triumph of vim's default patterns, when it is really a failure of vim to support whole ranges of functionality. as a daily user of neovim, i know that vscode is a superior alternative and am waiting for a month off to tr…

I also find that vim defaults are very lackluster, I could spend all day listing its faults: - hjkl is not a reasonable default mapping for motion, for one it doesn't make it obvious that j is down and l is up since the keys are next to one another (which makes it a lot harder to memorise in the first place) but on top of that it wastes two very premium home row keys, h and l, for something that you really shouldn't…

This, people in this thread are talking like the defaults like they were handed down by devine beings from the ancient past. The truth is that they are often just warts from and old past that can't be removed for backwards compatibility.

My personal vim ethos: You can, and you SHOULD tailor it to yourself.

Re: Porn, Zen, and .vimrc

#126

I personally find vin to be a good tool for editing text without leaving the terminal. But when I’m writing a lot of code, I’ve found the vim ide concept to be far more trouble than its worth. Modern IDEs like VSCode + Vim bindings is my preferred platform

One thing I never understood is why Vim bindings are a big gain when you have a mouse. I see a single edit, it takes me all of one second to click for a large jump, even less for cursor key combos in case of a small jump. For mass edits there is find/replace and find+multi cursor. 80% of my time in the editor I spend thinking about the code anyways - I have zero interest to optimize deciseconds of my time, or worse,…

I've come to the conclusion that the discrete interface of the keyboard and keypresses meshes well with the discrete nature of text versus the analog control the mouse gives. When selecting by individual characters/lines, I'd much rather use my keyboard and know that for each keypress I'm interacting with some X amount of text than fumble with my mouse until I get exactly what I want selected. Vim keybindings specifically are nice because they provide a pretty universal interface - most applications I use implement Vim keybindings, so there's very little context switching when working with my IDE, CLI file browser, Firefox w/ Vim Vixen, etc.

Also, I find that preventing constant movement from the keyboard to my mouse and back helps mitigate wrist pain and discomfort from long sessions at my PC.

Re: Porn, Zen, and .vimrc

#127

Earlier quoted context omitted.

Mouse takes far longer than a second for a selection. Switching between keyboard and mouse already takes longer than typing the usual vim-commands for a simple action. And casual keyboard-commands just don't scale well. Moving cursor x chars means you must type the movement-key x times. With vi you just type the number x and the movement, and usually save big time. Aditionally, vi has more knowledge about textual obj…

I have exclusively used vim keys for years now, but even after that time I find some of this just doesn’t ring true. Anything in vi that involves counting some number is usually faster with normal keys or the mouse. For example moving down 20 lines is way faster with the mouse, you just click. With vi you have to count the lines in your head - better hope you don’t lose count half way because two lines blur together.…

H/M/L is your friend (move to the top/middle/bottom of current screen). Getting to the wanted position usually takes me less time than just moving my right hand to the mouse and back.

Re: Porn, Zen, and .vimrc

#128
post #77

Earlier quoted context omitted.

> I have zero interest to optimize deciseconds of my time, or worse, optimize my perceived productivity vs. my actual productivity (e.g. forcing myself away from the mouse by ways of pattern matching that increases both mental overhead and time required). I think you just said it. Its not interesting/nor a priority for you to optimize things to that level. Those using vim properly and trying to move away from the mou…

Not sure if you over read the second part of that phrase, but I have serious doubts whether the efficiency gains touted by Vim users are real or only perceived. I'd like to see some good hard data on that, comparing users of similar proficiency level at various editing styles.

Honestly, I use vim too, and I have learnt the "language" of vim i.e. the grammar and consider myself an advanced beginner.

I have doubts whether the efficiency gains are that useful in every day life. There will some days where I make some pretty widespread refactoring changes over files or the yanking/register stuff can be quite useful, but in general, every day programming, I don't see the efficiency gains.

I have another theory for why people like Vim so much.

Using vim makes you feel like the old-school, crazy powerful, very smart programmers shown in Hollywood. It makes you realize the dream that the little child had when he saw programmers on TV. ( at least for me ) and honestly, its more fun to be doing that so I do it. :)

Maybe I am not that good at vim. But at my level, i don't see great efficiency gains. I simply see more fun gains, and that's good enough for me.

Post reply on HN