How I use my terminal

I love this, I've been iterating on workflows like this for something like a decade now. Over time I've tried to peel back as many of my custom layers as possible, because all of those layers have a maintenance cost.

Stock Vim (without `tmux`) can actually do most of what's shared in this post with `rg --vimgrep restore_tool | vim -c cb -` (`vim -c cb -` is my favorite feature in Vim; I find it strange that it's so rarely used or talked about).

(Since re-running the `rg` search can be undesirable, and I often like to analyze results in a terminal before opening them in Vim. I use a custom `tmux` command to copy the output of the last command [using this trick that involves adding a Unicode character to your prompt https://ianthehenry.com/posts/tmux-copy-last-command/], then I send that into Vim with e.g., `tmux saveb - | vim -c cb -`.)

> (`vim -c cb -` is my favorite feature in Vim; I find it strange that it's so rarely used or talked about).

Care to explain what it does? Trying `ls | vim -` and `ls | vim -c cb -` I don't immediately see a difference.

Ten years ago I threw out my massive multi-file, multi-package vim config and have been slowly building up a much simpler vimrc about 1-2 lines a year. I completely agree, defaults in old software are almost always there for a reason and you should try to understand that before changing them.

`cb[uffer]` processes the current buffer as a compile buffer, which will find `grep` format matching lines (i.e., at a minimum starting with `<path>:<line-number>:<column-number>`) and populate the quickfix list with them, and jump to the first match.

E.g., your example doesn't do anything because `ls` doesn't output `grep` format lines. So try piping the output of `grep` (you'll need flags for the line number and column number with `grep`, hence the `--vimgrep` flag above) matching the above format (or you could try `ls | sed 's/$/:0:0/' | vim -c cb -`, which will hack `ls` output to grep, and is occasionally useful).

(Note that the above hints at another useful tip, `grep` parsing is only part of what `cb[uffer]` does, it can also parse compile output, e.g., something like `gcc foo.c | vim -c cb -` will jump to the first compile error in your program and put the rest of the errors in the quickfix list).

I also find creating my own little shortcuts to be super satisfying and of course very transferable since they work out of the box.

```some examples " Quick access to commonly edited config files (and a directory for my Shell scripts!) map <leader>v :e ~/.vimrc<cr> map <leader>V :source ~/.vimrc<cr> map <leader>w :e ~/Workspace/myCo/tmuxp-session.yaml<cr> map <leader>W :e ~/.tmux.conf<cr> map <leader>z :e ~/Shell<cr>

" Super simple in editor note setup, amazing map <leader>x :vs<cr>:e ~/Documents/notepad.txt<cr> map <leader>X :vs<cr>:e ~/Documents/notes<cr>

" Quick terminal pane map <leader>t :vs<cr><c-w>l:term<cr><c-w>j:q<cr> " Pull file path into clipboard nmap <leader>b :let @+ = expand("%")<cr> " Pull current line into clipboard nmap <leader>B "*yy ```

Quick disposable terminals, tons of short cuts to get me into the config files that make it all happen (vimrc, zshrc, tmux.conf, a tmuxp session file) and to reload them, and super quick access to a well organized directory of notes are all huge boons during my workday.

You get similar buffer behavior if you use :make inside Vim and Vim as your build terminal. Despite being named :make it isn't hardcoded to just make as build tool (there's a bunch of out-of-the box settings you can pick with :compiler or you can update individual settings like makeprg).

Similar behavior with :grep inside Vim which you can change your grepprg to rg if you like.

I've got a feeling the `| vim -c cd -` isn't as commonly known because the Vim-initiated versions are somewhat more commonly known. It's handy to know that vim can do it in both "directions" (initiated from the external shell / initiated to the internal shell support).

I haven't had to in a while as I've lapsed into IDE usage as of late, but my vimrc is something I committed to memory a long time ago.

  set tabstop=4
  set shiftwidth=4
  set expandtab
  set showmatch
  set nohlsearch

  set background=dark
  syntax on

Typing that config into a file is emotionally associated with a system feeling "ready" for me. "ah, now I can _do_ things".

Is this the same/similar to 'vim -q <(ripgrep --vimgrep restore_tool)'?

Similar enough, minor semantic differences (e.g., I don't think `-q` creates a buffer containing the matches)

A wise elder once advised me that if I learned to work quickly and comfortably with an application’s defaults, I would be just as quick and comfortable on any system I would likely encounter. Very zen. Great advice.

… why `memory commit` what you can `git commit` and then just `git clone`.

(I keep most of my dotfiles in a repository called "dotfiles".)

I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor.

Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.

spoken like someone who has never had to operate on someone else's machine that they provisioned for you on an isolated network

No accounting for taste, but my similarly terse vim config includes relativenumber and number. Relativenumber is just so damn useful for doing things to larger chunks of code without having to count lines or anything.

I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to.

Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc.

Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there.

I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.

Is it? I should just purposefully bind myself?

Seems like using a tool to its fullest potential to get more work done is better advice.

> I would be just as quick and comfortable on any system I would likely encounter.

How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.)

But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.

I would love a generative llm script that looks at my command history (or something comparable), and adds a new zsh config (or other dotfile) every day, explaining itself via a reliable motd-type screen that flashes on-screen during the first session of the day, explaining what was added and allowing me to play with it and decide to keep it or not by the end of the day :)

Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once

I see it more as like understanding how to use a hammer even if most of the time in your job you use a nailgun.

For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.

Isn't the author likely to know the tool's potential best? I get that there are special cases but those should be few and ones you know well enough to memorize the exceptions for.

Operate yeah. But write lots of code?

This is cool, I learned about `:cb` today (populate quickfix from current buffer)

I find that if I’m already piping into a buffer, I just leave it as a buffer. Vim’s gf and gf keybindings let me jump to the filename under the cursor, and it being a buffer makes it easier for me to edit (reorganize, group, further filter, etc).

I do think people undervalue the quickfix buffer though!

Closest thing you'll find, I think, would be some creative use of ShellGPT features...

I mean there is a middle ground. LSP is good for coding a project. But I do agree with your point. What I generally do (as nvim user) reduces plugins to the bare minimum and try as much as possible to do progressive enhancement (atleast I try). Maybe as nvim improves LSP, I hope the diff between LSP and native methods are close enough that they both work.

That would be true if you had universally great designers back then, which wasn't the case, thus the defaults are universally bad, so it's a bad heuristic to stick to them and force a waste in trying to understand them.

For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.

That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad.

To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.

> and touch typists end up having the movement keys under their right hand’s resting fingers.

This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)!

Or don't and use this obvious principle directly and change keybinds to jkl;

Or go with the muscle memory of inverted T and use ijkl

But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)

Some defaults suck massively, emacs in tmux basically doesn't work due to hijacking C-b. The one that catches me every time is whatsapp that hijacks C-p.

and then we have C-n C-p of emacs. it should come with a health hazard warning.

Haha, yeah, that's way more atrocious, the ergonomic reaper of bad mnemonics of next/previous line sweeping again...

The fact that the tools have survived and are still used today is at least somewhat indicative of their quality though. A lot of worse designs have likely been selected away due to nobody even bothering to use them.

P(old thing being good | old thing still being used after N years) is pretty high. Certainly higher than the base rate of P(new design fad being good).

"rg --vimgrep restore_tool | vim -c cb -" looks like I want to use it. However, it doesn't work for me. vim says it had errors while processing, and says I haven't saved the buffer. I get the rg result displayed, but how do I navigate to a place?

Yep. Some orgs require it.

I'm not arguing for it, just saying I've seen it at multiple billion-dollar+-a-quarter companies.

Use `cb!` instead of `cb`:

    rg --vimgrep restore_tool | vim -c cb! -

You might also wanna open the quickfix list by default:

    rg --vimgrep restore_tool | vim -c cb! -c copen -

You can learn more about how to navigate it using `:h quickfix`.

As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.

I had never heard of the quickfix list! Thanks a lot!

> defaults in old software are almost always there for a reason

Keeping your fingers on the home row is great design for keyboard-first navigation.

All software design is historically contingent so you do have a point but assuming that old design = bad design is just wrong. Some things haven't changed.

> Keeping your fingers on the home row is great design for keyboard-first navigation.

Except you've just made that reason up since vim's defaults don't follow this logic. For example, the most frequent commands of going back/forward by word are not on the home row, they follow a different principle of name-based mnemonics.

Strictly speaking, this isn't even true for hjkl, that was due to the fact that arrows were drawn there, not because the designer followed some good design principles (granted, at least the physical arrows were likely driven by that principle, though there is still a mistery of moving off resting/home keys, which might be related to the fact that cutoff ASCII H code is backspace https://news.ycombinator.com/item?id=3684763).

> Some things haven't changed.

Indeed, and that universal fundamental thing that hasn't changed is that a few random people doing design blindly can't universally create a world of good design!

It makes a lot of sense as they are on the home row... Via this argument you could suggest moving it to `jkl;` in order to minimise movement further.

For me personally is the J/K direction still feels swapped and I always have to remind myself they are in fact the other way round. Even (especially) for touch typists, I would really expect [k] to point down and [j] up. In our writing system from the top left to bottom right my intuition would really be to stick ↑ with ← together and vice versa ↓ with →.

    ← ↓ ↑ →

makes a little sense to me.

    ← ↑ ↓ →

would be way better, IMO.

Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.

Honestly, I wouldn't even mind having them spread across two rows, like U I J K

    ↑  ↓
    ←  →

or something. (Personally, I have global WASD-like arrow mapping bound to IJKL through capslock combo in AutoHotkey, since sometimes cursor keys are really inconveniently far away when typing.)

I use fish and neovim, thanks to the thread, created the following alias:

   nvim -q (rg --vimgrep needle --color=never | psub) -c copen

Can someone sell vim to me?

I can't help but see it as the tiling window manager of text editors.

Even with plugins it's less featureful than Kate or Jetbrains IDEs. And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.

If I need to edit text via the terminal, micro has mouse support and keybindings that match what you'd expect in any OS.

I don't like the idea of thinking people who use vim are insane, it obviously has value and people who use it have good reasons for using it, but I can't see it as more than a niche nerd thing a la tiling window managers.

Lets go one level deeper: What's the reason that the vim disgners keyboards had hjkl as arrow keys? Because it made sense for it to be the home row. I still use arrow keys though

Vim has it’s advantages:

- Fast and precise navigation (jumping to files and jumping to some point in the file)

- Fast editing command (there’s no need to select first, and when you need to selection is fast due to the above)

- Easy extensibility (either custom commands which you can bind to keys, or hooking some logic to editor’s event)

- Integration with external tooling (using the text as input, collecting the output, intepret the output to find location to jump to)

All of these are first citizen in Vim, whereas in some editors, it can only be done with plugins.

I use both (neovim instead of vim, i3 as wm) and you got me thinking. I think the point of both is actually not having to use the mouse. But the mouse is not the problem per se, probably is the spatial/visual interaction paradigm. I don't care where the window exactly goes, I just want it right/on top/minimized. I don't want to search visually for a button that does what I want, I know what I want, I can just "tell" the computer. It's not about keybindings as shortcuts to do something, it's talking to the computer via keyboard using my language center without the intermediary of the gesture/spatial metaphor. Maybe? I just thought of this sorry.

I like the bindings, because I move vertically more than I move, so I want my strongest (other than the thumb) there. And I move to the right more than I do to the left. So I don’t mind moving my finger to do the latter.

I don’t mind it, because I don’t use it that much. And when I do, I move my whole hand to use the index fingers. I mostly use isearch and imenu.

I think the sort of person who likes it values the "test of time" aspect of it and trust that vim will still be there in the next three decades, just as it was there for the last three. It's super easy to install, and is indeed preinstalled on almost every Linux installation. So people can learn its ins and outs and do extremely fine-grained customization to their desire. People who get annoyed by tiny details and don't want to put up with it. The downside is that you need to carry around your config files and if you sit at a colleague's computer you don't get the same standard experience. And the fragmentation.

There's of course also the "hacker street cred" aspect of it, to feel like a real serious developer. Or simply being fed up with churn and saying "I'm too old for this shit". JetBrains IDEs might change next year due to some new design fad. Or they may go bankrupt.

In my opinion, valuing boring old tech is good, but you shouldn't make a crusade of it. I choose to put up with some churn and inevitable tool changes for practicality. Yeah, some things have to be relearned this way, some changes seem pointless, but the overall effort may be less if you just learn to be flexible and say "ok if JetBrains goes bankrupt, I'll just learn the next popular IDE like everyone else and be done with it" instead of prepping in my bunker with my vim config files.

Yes, they are not in the resting position on the home row, but they are close enough for a command you will be executing often. Crating a key-map is an optimization problem between memorability and ergonomics.

Vim command layout is not perfect, the worst offender in my opinion is $ (move cursor to the end of the line), which is commonly needed, but somewhat hard to reach.

HOWEVER - when you start to use an surviving piece of still used old software, a bit of humility goes a long way. Not because software or designers were necessarily better in the past, but the reason that the software is still in use is probably because there are some benefits to it. So learn the defaults first, modify later when you understand them.

> they are close enough for a command you will be executing often

Right, just like w/b are "close enough" outside the home row completely

> but the reason that the software is still in use is probably because there are some benefits to it.

You forgot to connect this principle to this discussion. How does it make the defaults good to support your faulty conclusion that you need to learn them first?

vim and tmux both have mouse support as well, it's nice to be able to resize vim splits and tmux windows with the mouse.

> Why were the arrow keys on those particular keys? Who put them there?

They were placed on those particular keys by Lear Siegler who made the ADM-3A terminal Bill Joy was using at the time he made vi. End of story.

> Right, just like w/b are "close enough" outside the home row completely

Yes, they are close enough, and w/b are executed often.

> How does it make the defaults good to support your faulty conclusion that you need to learn them first?

You need to at least study them because assuming a priori that they are either good or "universally bad" is a faulty conclusion - and some stuff doesn't become obvious until you use them for some time.

When you start learning VIM, you will be faster with arrow keys, because you are used to them from other programs. When you get enough muscle memory, you may discover that there is some value in having somewhere near where your fingers rest on the keyboard - or maybe you will still find that you are faster with arrow keys - whatever the conclusion, it can not be made objectively before you have enough proficiency with both.

It may be different based for others based on hand anatomy, but at least for me the index finger is so much stronger than the little finger, that it feels more comfortable moving it one space to the left, especially on keyboards with heavy keys (like model M).

Vim and related vi-based editors have a built-in 'grammar' for editing text that is concise:

https://stackoverflow.com/questions/1218390/what-is-your-mos...

With a bit of practice, vim/vi-style editing can be developed into muscle memory which makes it incredibly fast to use.

There is a reason why most popular text editors and IDEs have a vim plugins.

Oh that sucks.

This is amazing! Thank you!!

The quickfix window is so small, so I added the "-c only" option to make it the only window that first pops up. Then made it a function so it's easier to call:

``` vgrep() { rg --vimgrep "$1" | vim -c cb! -c copen -c only - } ```

$> vgrep "restore_tool"

That is absolutely not a faulty conclusion in any objective sense!

Now, you get to say it is faulty, and when one thinks about it for a minute, that idea packs a whole lot less punch.

Just want to dilute some unnecessary implied authority out of this otherwise interesting discussion.

Frankly, I always learn the defaults for the high value idea of reducing my overall configuration and maintenance workload!

Secondly, when I communicate workload to others, I don't have to do as much because the defaults are in place and useful.

These days, I tend to run defaults everywhere I can. Doing this means I do not have to a ton of configuration when setting up new environments.

I have also found those defaults do make a lot of sense. Maybe not the absolute peak sense, but more than enough.

I end up able to move and do a lot very reasonably quickly.

I also find my skills do not need to refresh as often too.

In any case there is plenty of room to disagree here, sans the idea of someone's conclusion being " faulty.

> And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.

There was likely something wrong with your configuration. It's really hard to be faster than vanilla vim, but you can get weird performance issues from external plugins sometimes.

> and when one thinks about it for a minute

... one still can't correct the fault. You haven't answered the question of the original disconnect in arguments.

Your new arguments aren't relevant either since they're also NOT connected to the original re. bad defaults. You can have bad defaults that aren't there for any good reason and still think that reducing maintenance is more valuable! Fine, but that's a different argument!

As a touch typist that learned decades before learning vi, with Emacs in the middle, I can definitively say your blanket statement is false. And as a recovering Emacs user, I can also say the little finger thing for a repetitive key is a dangerous proposition with real potential health drawbacks.

I am not sure we are always talking about bad defaults.

That needs evaluation, and that need to be done in context.

In many cases, the defaults are not bad. One finds that out by working with them.

Really, I just don't feel "faulty" makes any sense.

If anything, it is more establishing a baseline.

Whether someone bothers with defeats first is debatable. I am on the work with them first side for what should be obvious reasons.

Passersby can arrive at their own conclusions and life carries on.

Re: still think reducing config and maintenance...

Yup. I have shown it many times. This also depends on context. For most of my career, no brainer.

I will admit that I had never considered things like this (there's a couple of you making a similar point). It's a decent argument. Maybe I'll revert to the default and see if I can handle the change.

I used some Vim IDE plugins and I assume the bottleneck was there.

The problem is without some IDE-like features, I don't have a need for a text editor. Micro supports LSP servers by default and that gets me pretty far, before jumping to Kate or a real IDE.

It's this. I make the analogy to playing a game with a controller. At some point you stop thinking what combination of physical button presses and holds you need to have your character go from a running start to a crouch-jump, you just think in terms of goals for you want your character to accomplish. vim motions put you in the same sort of connection with the text you're editing.

I definitely get that, I feel the same way about Bash. It's stood the test of time, is everywhere and will be everywhere for the foreseeable future.

Thanks for the perspective.

I've done it. It was terrible. I'm glad the project ended.

There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)

The question is which plugins you used. My neovim configuration gives me "IDE-like features", yet it's noticeably faster than VS Code and others. Also, neovim has native support for LSP too.

I think the current system is the way it is in order so that the most used direction (down) uses your strongest finger, the index finger.

I don't know what your mean by "Not only because the most used used direction (↓) would be closer to my "neutral" finger position" - what is your neutral finger position?

I also got lost in the sentence about "back" and "forwards" - what is back and forwards?

I tried searching how to open the quickfix window in a vertical split, but found nothing. Any ideas?

which even then is horrendous ergonomics.

got it

    find "$1" -name "$2"  | vim -c cb! -c "vert 40copen" -

40 means open at 40 column.

Can you recommend any plugins that you find useful?

> what is back and forwards?

Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.

> strongest finger, the index finger.

Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)

> what is your neutral finger position?

Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)

Vim existed before Jetbrains IDEs. It’s also much more general. I use Vim to write literary works and manage my knowledge base. There was also a guy who was using Vim as his IRC client. Vim can be the only program you need for editing text, which turns out is most of what we do on a computer. It’s nice to have a single tool for this, that never resists when you try to adapt it. Vim is actually a great example of the practicality of a good philosophy.

Edit: I doubt there’s any feature in the more specialised editors, which you can’t also get from Vim.

Isn't `rg --vimgrep restore_tool | vim -q -` better though ?

    -q [errorfile] QuickFix mode.  The file with the name [errorfile] is read
  and the first error is displayed.  See |quickfix|.
  If [errorfile] is not given, the 'errorfile' option is used
  for the file name.  See 'errorfile' for the default value.

If you wish to automatically also open the quickfix list

    rg --vimgrep restore_tool | vim -q - -c 'copen'