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

111–120 of 169 posts

Re: Vim Creep (2011)

#111

Post by [deleted] »

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.

[deleted]

Re: Vim Creep (2011)

#112

Post by C0d3r »

0x008 wrote: post #59
FeepingCreature wrote: post #22

Earlier quoted context omitted.

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

fzf can be used as a cool selector in the terminal, it just outputs what you picked from the list, so if you run `ls | fzf`, it will pass the list of files/dirs into fzf, where you can fuzzy search, select and it outputs to STDOUT.

So if you want to edit a file from inside a directory easily, you can do:

vim $(find | fzf)

Re: Vim Creep (2011)

#113

Post by eeZah7Ux »

sodapopcan wrote: post #53
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).

4) You also learn a ton while trying out different ways to create your own development environment

Re: Vim Creep (2011)

#114

Post by BadInformatics »

IggleSniggle wrote: post #91
barbs wrote: post #70

Earlier quoted context omitted.

Not to be too pedantic but shouldn't that be ddGp? Also, have you tried the Vim plugin for VSCode?

I've tried the Vim plugin for VSCode a few times personally, but I don't trust it. It's incomplete, and it has its own secondary understanding of history that can get you into trouble when it interacts poorly with VSCode's own history. Anyway, that was my experience for my short time using it. I'm curious if there are any longtime vim users using VSCode with the Vim plugin, and if so, what are their experiences, and…

I used to, but switched to https://github.com/asvetliakov/vscode-neovim. It's much faster, doesn't lag the editor at all and has less of an impedance mismatch because it uses Neovim under the hood instead of trying to emulate functionality from scratch.

There are a few reasons why I use a vim plugin instead of vim proper for most day-day work:

1. I do plenty of data science-y stuff that requires support for good visuals. Vim's support here is pretty lackluster and Jupyter's Vim mode sucks. VS Code has a great interactive mode with full autocomplete and a dedicated window that records plots/output history.

2. Language servers and LSP plugins are so much easier to manage. I rarely if ever have to babysit updates and I don't have to install a bunch of system-wide dependencies to get certain ones to build.

3. Making the above (and all other fancy VS Code functionality) work on multiple remote machines is a breeze. The normal Vim workflow would require cloning dotfiles (not a big deal), running setup with something like GNU Stow (almost never installed) and then futzing around with LSP plugins as in 2).

4. Built-in rendering of rich docstrings/doc pages (think Markdown, Sphinx RST). I want to say certain extensions/languages support LaTeX as well, which would be a bear to read in Vim.

Re: Vim Creep (2011)

#115

Post by BadInformatics »

0x008 wrote: post #63
pojntfx wrote: post #16

Earlier quoted context omitted.

I highly recommend trying out VSCodeVim. Use it for Go, JS, C, Rust and more - it's really enjoyable, and even stuff like C - W works just fine.

Unfortunately that plug-in is a horrible performance hit to an editor that already is on the slow side of typing responsiveness.

Seconding the suggestion for https://github.com/asvetliakov/vscode-neovim. Performance aside, it supports many more vim features and I believe it also plays better with undo.

Re: Vim Creep (2011)

#116

Post by enriquto »

horsawlarway wrote: post #94
enriquto wrote: post #86

Earlier quoted context omitted.

> I don't understand - how is using a debugger a waste of time? The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding asserti…

I feel like your understanding of a debugger is very limited. To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project. A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing. Not even touching the places where a debugger solves a prob…

First of all, I agree 100% that a debugger is an indispensable tool. I just say that it is often not necessary or useful when you are writing new code or reading old code that you are supposed to edit. Your example about interpreting a crash dump is definitive.

I've had a fair share of using debuggers in my life, and I ended with my anti-debugging stance as a matter of fatigue, and a sense of time lost. I know what debuggers are capable of, especially regarding data visualization. But for your example of the variable watch, what are you going to watch, precisely? That the value of a variable is always positive? That it increases one by one? All these things are better served by assertions. What kind of information can be inferred by just looking at the evolution of values of a variable that is not easily formalized as an assert or a simple in-code test?

Re: Vim Creep (2011)

#117

Post by antoineMoPa »

horsawlarway wrote: post #94
enriquto wrote: post #86

Earlier quoted context omitted.

> I don't understand - how is using a debugger a waste of time? The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding asserti…

I feel like your understanding of a debugger is very limited. To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project. A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing. Not even touching the places where a debugger solves a prob…

It's weird to write the test after solving the problem. You should write the test before solving the problem to get the most benefit. You can then edit + compile + run test until the test pass and normally this is shorter than the "edit+compile+start app+replicate bug manually in application+debug" loop.

Re: Vim Creep (2011)

#118

Post by detaro »

enriquto wrote: post #86
barbs wrote: post #75

Earlier quoted context omitted.

I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.

> I don't understand - how is using a debugger a waste of time? The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding asserti…

If code had instrumentation for every variable someone ever looked at with a debugger it would be unreadable because it'd be buried under instrumentation code, configuration to only enable instrumentation when needed, ... That's not to say instrumentation/logging/... aren't useful tools that can be more appropriate, but "never use a debugger" seems like a misguided dogma that seems surprisingly common. Part of the strength of a debugger is being able to look at all the things to find the ones worth a closer look, without having to add instrumentation or logging to every single one.

> by adding [...] comments, [...] etc

If you need a debugger, those are not there or not good enough, and you can only meaningfully add them after you understand what's happening.

(EDIT: there is also a wide variety in what people count as a "debugger" further muddying the debate)

Re: Vim Creep (2011)

#119

Post by sweeneyrod »

dmitryminkovsky wrote: post #60
lawn wrote: post #12

Earlier quoted context omitted.

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 emul…

All LSP clients for vim will give you that; it is whatever command calls `hover` on the language server (e.g. ALEHover for ALE or LanguageClient_textDocument_hover for LanguageClient-neovim). Obviously you should bind these to some convenient command like t.

Re: Vim Creep (2011)

#120

Post by bsg75 »

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 share how a drop down terminal figures in here as compared to a standard window?
Post reply on HN