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

141–150 of 169 posts

Re: Vim Creep (2011)

#141

Post by Privacy846 »

hansvm wrote: post #139
throwaway744678 wrote: post #136

Earlier quoted context omitted.

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

I have used `grep -r` a ton on our codebase and purpose-specific tools like “find usages” are always more to the point while `grep -r` can easily be misleading.

Also you can’t just tend toward greppable names (whatever that means) if you share a codebase with developers who are on Windows and wouldn’t be able to tell grep from sudo.

Re: Vim Creep (2011)

#142

Post by LiamHz »

Hahhaa wrote: post #109
b0rsuk wrote: post #72

Can you recommend some resources about using Vim effectively without turning it into an IDE? I'm a self-learned Vim user and I'm sure I could learn a lot by observing experienced vim users. Kakoune has ambitions to be the true "unix way" editor, but it makes some very questionable design decisions like plugins made in shell scripts. For the sake of compatibility. Neovim's decision to fully support Lua appeals to me m…

I'm a self-learned vim user too. I been using vim the wrong way till i watch this video, https://www.youtube.com/watch?v=l8iXMgk2nnY VIM tutorial: linux terminal tools for bug bounty pentest and redteams with @tomnomnom Now I keep my vimrc simple and use neovim for more complex stuff.

This was a great video, thanks for sharing! It made me realize that I haven't been using unix commands enough in Vim

Re: Vim Creep (2011)

#143

Post by dxdm »

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" (…

> and of course, for german keyboard layout devs, rebinding capslock to alt-gr.

I went the other way: use a US layout keyboard, and bind capslock to switch to German layout while capslock is being held down. I find that I need my fancy braces and brackets more than my umlauts. :)

Re: Vim Creep (2011)

#144

Post by _0w8t »

smichel17 wrote: post #37
_0w8t wrote: post #27

Earlier quoted context omitted.

Without plugins Visual Studio Code in principle is just an editor. Yet even without any plugins or language-specific support it still a better tool for development out-of-the-box than Vim or Emacs. It can quick open and search across a development tree with thousands of files with no configuration. So as an editor for config files and small projects Vim without plugins is OK. But that basic Vim experience just does n…

> It can quick open and search across a development tree with thousands of files with no configuration. git grep ?

Checkout chromium and try that on its tree. Or rgrep. Then try searching it with vscode and compare the timing especially with second and following searches. And vscode is smart enough to search files that where opened recently first bringing useful results instantly.

Re: Vim Creep (2011)

#145

Post by mehrdadn »

barbs wrote: post #71
mehrdadn wrote: post #9

Earlier quoted context omitted.

If you're looking for an IDE I recommend Visual Studio. (Classic, not Code. Yes, on Windows.) It's awesome.

Why do you recommend Visual Studio Classic?

I'm not really sure how to summarize it but I guess you could say it's both powerful and intuitive.

Re: Vim Creep (2011)

#146

Post by cracksmoka420 »

Privacy846 wrote: post #140
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…

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

> But you see that’s exactly what you are, because you can’t refactor Java code with what you call “Unix tools”.

"refactoring java code" is really not an exceptional task that vim (or emacs) cannot handle.

In situations where grep -r is too stupid, ctags exists.

Re: Vim Creep (2011)

#147

Post by simias »

_0w8t wrote: post #144
smichel17 wrote: post #37

Earlier quoted context omitted.

> It can quick open and search across a development tree with thousands of files with no configuration. git grep ?

Checkout chromium and try that on its tree. Or rgrep. Then try searching it with vscode and compare the timing especially with second and following searches. And vscode is smart enough to search files that where opened recently first bringing useful results instantly.

Of course if you need to cross reference the entirety of a gigaproject like Chromium you're going to need some sort of a cache and smart search. If I was a Chromium dev I'd probably set something up to help with that.

99.999% of source trees are a tiny fraction of that size however.

As I mentioned in another comment I routinely hack in the Linux kernel which contains about 15million SLOCs (per sloccount) and ripgrep takes less than 5s on a cold run and is near instant after that. ctags lookup almost instant regardless of cache. And that's on a 5 year old middle of the line SSD and CPU.

Inability to easily deal with chromium-sized repositories out of the box might be a deal breaker for you but it's a total non-issue for me.

Re: Vim Creep (2011)

#148

Post by DangitBobby »

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…

Fortunately there's a terminal window baked right in there if you find yourself needing other tools.

Re: Vim Creep (2011)

#149

Post by cyberdelica »

cracksmoka420 wrote: post #146
Privacy846 wrote: post #140

Earlier quoted context omitted.

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

> But you see that’s exactly what you are, because you can’t refactor Java code with what you call “Unix tools”. "refactoring java code" is really not an exceptional task that vim (or emacs) cannot handle. In situations where grep -r is too stupid, ctags exists.

As well as ctags, one can also use the GNU "idutils" suite of programs.

Re: Vim Creep (2011)

#150

Post by pasabagi »

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…

I tried this approach for a while, and the thing I couldn't get my head around, is how do you undo mistakes? Like, you write a messed up sed command - are you supposed to revert your changes to the last git commit? Not make mistakes?

If I could work out a way to make undo as seamless and full featured as undo in, say, vim, then I'd be a total convert. Is there such a way?

Post reply on HN