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

Vim Creep (2011)

rudism.com

Post reply on HN
Print view View original

51–60 of 169 posts

Re: Vim Creep (2011)

#51

Post by shmoogy »

FeepingCreature wrote: post #22
YesThatTom2 wrote: post #15

Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…

My .bashrc is on a quest to turn my yakuake into the better half of vscode. "The shell is my IDE" is definitely true. Though Google takes up a worryingly large fraction of it. Wonder if there could be a shell tool to just dump the first stackoverflow hit for a search. bashrc highlights: https://gist.github.com/FeepingCreature/649588a2f6fa27c717bd... - ctrl-G for "directory up" - ctrl-E for "find and open in editor" (…

>Though Google takes up a worryingly large fraction of it. Wonder if there could be a shell tool to just dump the first stackoverflow hit for a search.

I saw this yesterday and your comment reminded me of it: https://github.com/danrobinson/tracestack

I kind of thought it was a novel idea, but kind of pointless - if you know how to read a traceback you can Google it... but I guess it makes a lot of sense depending on your workflow.

Re: Vim Creep (2011)

#52

Post by seszett »

arendtio wrote: post #36
lunchladydoris wrote: post #26

Earlier quoted context omitted.

In case anyone else hasn't heard of or used :x > Like “:wq”, but write only when changes have been made. https://til.hashrocket.com/posts/2fdb6afb66-difference-betwe...

Some time ago, I read, that the usage of :x is discouraged, as the typo :X is easy to make and leads to encrypting the file accidentally.

My problem is writing :x instead of :w (on an AZERTY keyboard) and accidentally exiting when I just wanted to save.

Re: Vim Creep (2011)

#53

Post by sodapopcan »

markus_zhang wrote: post #34

I'll stick to an IDE. Modern IDEs are sophiscated enough that a Vim/Emacs newbie user probably needs years of practice and tons of plugins to match and go over its capabilities. I think Vim makes a lot of sense when 1) the machine doesn't have a proper IDE, and 2) you really do a lot of programming every day and you are young, like in 20s, so you can amortize the cost for longer time.

3) You get joy from tweaking and heavily customizing your editing environment (as I do).

Re: Vim Creep (2011)

#54

Post by tylerscott »

stfwn wrote: post #3

I studied piano full-time for a short while. My favorite thing about it was how working on my technique or a particularly tricky rhythmic pattern tickled my brain. I often found that I went through a few phases: “ahrg, this is impossible!”, “getting there but sloppy” and finally, often suddenly (after a good night’s sleep) “this is easy! I don’t know how I was ever not able to do this”. Using vim and learning new fea…

I never had the words to express that feeling. Tickling the brain is exactly the experience. I also love learning a new trick in Vim even after all these years.

Re: Vim Creep (2011)

#55

Post by cma »

grecht wrote: post #42

If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch typing is similar - it's useful because it removes some unnecessary barriers and thus makes the job more enjoyable, but it won't magically make you a better a programmer.

Lots of times you could write something more succinctly with less boilerplate using, say, C preprocessor macros, but then end up losing out on debuggability, and sometimes searchability. Complex block based editing etc. is useful in those situations. It's a limitation of the tools.

Re: Vim Creep (2011)

#56

Post by u801e »

billfruit wrote: post #44
YesThatTom2 wrote: post #15

Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…

In general though Emacs single handedly can do most of everything required in software development. One could practically spend all ones development time inside it, so I would say Emacs workflows are more impressive than Vi ones, especially since so much of great functionality is baked into it without even needing pluggins. This I say after a couple of recent days in which the GUD gdb interface was a great help in so…

> This I say after a couple of recent days in which the GUD gdb interface was a great help in solving a few of the problems I was working on. Does VI has something similar built in? Or for any of the common workflows like these which work out of the box, without needing plugins or extra configuration

Not quite, but the help page does mention a plugin called termdebug[1] that can be used with vim's new terminal feature.

> 1. Remote file editing on other computers.

The netrw plugin which comes with the default vim installation allows for this

> 2. Rectangular/columnar text edits and manipulations.

You can select text in column mode and delete, replace, or insert text before or after the column (which can be wider than a single column).

3. Essentially infinite kill ring : This I find is very useful, one becomes accoustomed to building blocks of text by assembling things from the kill rings. Also plays nice with point 4, easy macro record/replay

vim has registers that correspond to every ascii letter (I think emacs has this as well). From what I recall, when you delete or yank text, it goes through registers 1 through 9 which each subsequent operation shifting the previous operation to the higher numbered register. After register 9, the delete or yank is lost.

But, if you use the capital letter registers, you can append a subsequent deletion or yank to what's already in the register, which I believe would effectively act as an infinite kill ring. I'm not sure if emacs can do the same with its registers.

> Easy macro record/replay of even complicated edit sequences

Vim has this as well, and you can store one macro in each of the ascii letter and number registers as well.

> 5.Inbuild calculator, with both rpn and algebraic modes.

There may be a plugin for that, but you could certainly pipe a line of text through dc or bc and get the result in vim.

> 6. The Dired mode provides a very convenient file manager.

You can get this through the netrw plugin as well.

[1] https://vimhelp.org/terminal.txt.html#terminal-debug

Re: Vim Creep (2011)

#57

Post by sodapopcan »

dmitriid wrote: post #6

> You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse. You mean: spend untold hours scripting and recording interactions that give you about 10% of capabilities of a modern IDE. I've personally seen long-time vim users switch to Idea after looking over my shoulder.

Depends on the language you're working in. I work in Ruby and as good as RubyMine's refactoring is, it can never be 100% because Ruby's a dynamic language. There are a lot of RubyMine "power users" at my office and, other than less than perfect refactoring, I haven't seen anything it can do that vim can't do. In fact, when it comes to navigating files, rails.vim seems superior. The only thing I'm jealous of is the built-in terminal that has tabs within the main screen.

Re: Vim Creep (2011)

#58

Post by billfruit »

seszett wrote: post #50
billfruit wrote: post #44

Earlier quoted context omitted.

In general though Emacs single handedly can do most of everything required in software development. One could practically spend all ones development time inside it, so I would say Emacs workflows are more impressive than Vi ones, especially since so much of great functionality is baked into it without even needing pluggins. This I say after a couple of recent days in which the GUD gdb interface was a great help in so…

All these points are also natively handled by vim. Except for 5 which needs an external cli calculator.

But are those functionality available natively without plugins? All these are in the default emacs distribution possibly since more than 20 years, and are in a very usable, stable state of functionality.

Re: Vim Creep (2011)

#59

Post by 0x008 »

FeepingCreature wrote: post #22
YesThatTom2 wrote: post #15

Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…

My .bashrc is on a quest to turn my yakuake into the better half of vscode. "The shell is my IDE" is definitely true. Though Google takes up a worryingly large fraction of it. Wonder if there could be a shell tool to just dump the first stackoverflow hit for a search. bashrc highlights: https://gist.github.com/FeepingCreature/649588a2f6fa27c717bd... - ctrl-G for "directory up" - ctrl-E for "find and open in editor" (…

Can you explain the fzf binding? I don’t get what’s going on there

Re: Vim Creep (2011)

#60

Post by dmitryminkovsky »

lawn wrote: post #12
dmitriid wrote: post #6

> You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse. You mean: spend untold hours scripting and recording interactions that give you about 10% of capabilities of a modern IDE. I've personally seen long-time vim users switch to Idea after looking over my shoulder.

There are language servers for Vim that take you much closer to IDEs than you give it credit for. Goto definitions, intelligent autocomplete, inline diagnostics, smart renamers, type hints and more are all available. All with very little configuration and it works the same no matter the language (as long as it as SLP support).

Close but not close enough.

For example: in VSCode you can select/hover over any expression and it’ll tell you the computed TypeScript type. None of the current language server tools for Vim (eg ALE) give you that information [0]. Why would I live without this useful feature just to use Vim? I love Vim, but I love knowing the type the TS compiler thinks an expression is even more, especially when good enough Vim emulation is available.

[0] https://github.com/dense-analysis/ale/issues/3206

Post reply on HN