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

131–140 of 169 posts

Re: Vim Creep (2011)

#131

Post by FeepingCreature »

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

Okay, the actual fzf call is just the $(fzf). But when you use a keybinding with -x, your shell executes the command directly. So when you press return in fzf, indicated by the exit code being zero, we additionally do three things:

- echo a facsimile of the prompt followed by the edit command so that it looks like you just typed "edit filename"

- insert that facsimile into the history buffer so that you can redo the edit command with arrow-up

- actually start the editor

- and clear the commandline of anything you may have written beforehand, which would otherwise still be there and break the illusion.

The reasoning behind this dance is that if you just do an ordinary bind, you just get the edit_fuzzy call in your bash history, which is pretty useless. You want the actual generated edit call, not the edit_fuzzy call. So we use bind -x and "pretend that you typed in the edit call manually". We could just make ctrl-E insert the edit command into the readline buffer, but then we'd have to press return twice.

${PS1@P} is "PS1, expanded as if it were a prompt (P)".

Re: Vim Creep (2011)

#132

Post by FeepingCreature »

bsg75 wrote: post #120
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 share how a drop down terminal figures in here as compared to a standard window?

I just like drop down terminals. :)

Re: Vim Creep (2011)

#133

Post by rendall »

I had this experience a few weeks ago. I was showing a colleague something, using vim as normal, and he started shouting "Whoa whoa! What are you doing? You don't use a mouse?"

"Vim!"

Re: Vim Creep (2011)

#134

Post by billylindeman »

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…

i use coc-nvim with tsserver and i'm pretty sure it supports this

https://github.com/neoclide/coc-tsserver

Re: Vim Creep (2011)

#135

Post by JNRowe »

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.

Even without resorting to external tools the expression register(:h @=) can act as a surprisingly good builtin calculator, and there is a moderately large builtin math library(:h functions).

Like all registers you can abuse it in many ways too, like as dirty inplace calculator when you're writing docs. For example, yank a example calculation, insert from register(:h i_CTRL-R_=), operate on your yank(:h @").

Re: Vim Creep (2011)

#136

Post by throwaway744678 »

jackyinger wrote: post #126
Privacy846 wrote: post #124

Earlier quoted context omitted.

Unix isn’t integrated enough. You can’t go very far with just throwing strings around (or bytes). You can’t safely refactor, say, Java code like you can do in Intellij. Maybe you can piece something together manually that does the same thing, eventually. But if you have to do all of that work yourself then I wouldn’t call it integrated.

I think the point is that with *nix you aren’t just stuck with what some product manager at JetBrains thought was a cool feature. And when you want to brew something up from scratch, or do the same task for the nth time, you don’t have learn how on earth this IDE implemented it, or learn a whole new API. Take for instance an IDE’s find usages function, often a simple grey -r from a judiciously chosen directory gets y…

Any sane IDE 'find usage' is miles above your simple grep: just try that on any sypbol with a name common enough, and compare the results...

Re: Vim Creep (2011)

#138

Post by JNRowe »

dmitryminkovsky wrote: post #129
sweeneyrod wrote: post #119

Earlier quoted context omitted.

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.

Do you know if it’s possible in vim to show hover for an arbitrary selection? A visual selection?

Like many things in vim it depends on whether you wish to write it ;)

You can define your own popup(:h bexpr) however you feel, including per-filetype or buffer. Instead of simply operating on the variables it defines to you can also work upon the selection by querying the register(:h quotestar) instead.

As an example, I like displaying wordnet¹ popups when writing prose. Occasionally, I'll also dump diction² output in to a popup too.

However, I do think that using messages(:h :messages) might make more sense for selection info in general. That way you can select a text, call a map to display information, and still easily recall that data when you're in another place via :messages at a later time. Depends entirely on your use case, and once again how interested in writing the functionality you are.

¹ http://wordnet.princeton.edu/

² http://www.gnu.org/software/diction/diction.html

Re: Vim Creep (2011)

#139

Post by hansvm »

throwaway744678 wrote: post #136
jackyinger wrote: post #126

Earlier quoted context omitted.

I think the point is that with *nix you aren’t just stuck with what some product manager at JetBrains thought was a cool feature. And when you want to brew something up from scratch, or do the same task for the nth time, you don’t have learn how on earth this IDE implemented it, or learn a whole new API. Take for instance an IDE’s find usages function, often a simple grey -r from a judiciously chosen directory gets y…

Any sane IDE 'find usage' is miles above your simple grep: just try that on any sypbol with a name common enough, and compare the results...

This winds up not being a big deal if you use grep a lot because you'll tend toward greppable names.

More importantly though, in a codebase big/complicated enough to need "find references" functionality beyond what you get from grep, do you not also have comments, reflection, and all manner of other garbage that you need to search for via some mechanism anyway?

For a few languages (more on the way) you also have semgrep as a way to add something a bit more powerful than "find references" into a normal shell workflow.

Re: Vim Creep (2011)

#140

Post by Privacy846 »

jackyinger wrote: post #126
Privacy846 wrote: post #124

Earlier quoted context omitted.

Unix isn’t integrated enough. You can’t go very far with just throwing strings around (or bytes). You can’t safely refactor, say, Java code like you can do in Intellij. Maybe you can piece something together manually that does the same thing, eventually. But if you have to do all of that work yourself then I wouldn’t call it integrated.

I think the point is that with *nix you aren’t just stuck with what some product manager at JetBrains thought was a cool feature. And when you want to brew something up from scratch, or do the same task for the nth time, you don’t have learn how on earth this IDE implemented it, or learn a whole new API. Take for instance an IDE’s find usages function, often a simple grey -r from a judiciously chosen directory gets y…

> I think the point is that with [Unix] you aren’t just stuck with what some product manager at JetBrains thought was a cool feature.

But you see that’s exactly what you are, because you can’t refactor Java code with what you call “Unix tools”. So your only option is to install actual IDEs on Unix.

And “find usages” finds... actual usages (e.g. method calls), not simple text matches which can end up being 80% noise. For `grep -r` you might try `Ctrl+Shift+f` instead.

Post reply on HN