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" (using fzf, substitute 'edit' with your editor of choice; the history gymnastics is to basically pretend that you typed it in manually for purposes of bash history)
- and of course, for german keyboard layout devs, rebinding capslock to alt-gr.
There should be. I think `curl cheat.sh/programming+question` does that. There might also be a way to do that with surfraw. I just use DuckDuckGo, it almost always pops up an Stack Exchange answer in the sidebar when I search for something relevant to an SE.
"How can I have a shortcut that I type, then enter a search query and have the first result open automatically?"
I use https://github.com/samtay/so, which lets you search any stack exchange site (SO by default). It's fully terminal-based.
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. :)
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.
... for cd ../..
....
.....
They compose naturally too, ..../targetDir
I use these so frequently and naturally that I forget that they aren’t built-in to my shell.
Also, a shortcut to jump between the last 5 or working directories. Print them with `dirs` and cd to a directory by invoking its number.
alias dirs='dirs -v'
alias '1'='cd -'
alias '2'='cd -2'
alias '3'='cd -3'
Doesn't seem like it would make a big difference, but it's very fluid and adopts well to whatever "you happen to working on in the moment."
- 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)".
So if you want to edit a file from inside a directory easily, you can do:
vim $(find | fzf)
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:
1. Remote file editing on other computers.
2. Rectangular/columnar text edits and manipulations.
3. Essentially infinite kill ring, i.e, a very easy to use copy-paste history: This I find is very useful, one becomes acustomed to building, blocks of text by assembling things from the kill ring. Also plays nice with point 4, easy macro record/replay.
4. Easy macro record/replay of even complicated edit sequences.
5.Inbuilt calculator, with both rpn and algebraic modes.
6. The Dir-ed mode provides a very convenient file manager.
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.
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 @").
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.
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 you the same thing, but faster and more flexible (if your mind is wired that way, I suppose).
Edited to complete fragment...
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.
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.
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.
"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.
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?
If you could undo stuff easily, suddenly the 'brutal, unforgiving' part goes away, and it would enable a much more relaxing, explorative atmosphere, while also meaning people don't have to do stuff like 'alias rm=mv -t ~/.Trash' or whatever.
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 independent. He watched as I did everything he did but with point-tools instead of a huge IDE. Rather than switching between files, I started a new terminal window and ran Vim. Other windows were for the build-run-crash loop, analyzers, note-taking, etc. Often I would do Vim tricks like doing a calculation by writing a formula on a line in Vim and piping the line to "bc" (`!!bc RETURN`). In fact, many of his IDE features I would access by calling out to external programs.
I had to hold back a laugh when he said:
"Oh my God! Linux IS your IDE!"
Well, duh. Isn't that's what Ken and Dennis created in the 1970s? Unix started out as the ultimate development environment! It just also happens to run everything else now.