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 -`.)

Every vim/tmux user has created an ad hoc, informally-specified, bug-ridden, admittedly probably quite fast implementation of half of Emacs.

i see a bunch of people saying things like "you can do this in vim or emacs". it's true, you can do fuzzy finding and panes/tabs in an editor. but then you are in a box. anything that involves interacting with the terminal requires either a dedicated plugin or opening another nested terminal emulator (e.g. `:terminal` in vim). one of the things i get from my setup that's not mentioned in this post is that i can hit `git show HEAD` <highlight files and choose one> <tab> and that will put the file name in the command. this works for arbitrary commands, not just git, because it works by doing meta-processing on the terminal.

I really appreciate this method of sharing workflows. Well catered to the audience. Actually was slightly hoping there'd be sound to the vid, too, but reading the list of actions after-the-fact was reasonable. I learned a few things I could do and/or approach differently in my own flows.

You mentioned the arcane keyboard shortcuts of tmux. I'm curious if you or others here have tried/use byobu (which I think of as a wrapper around tmux, basing most commands on the F# row). I was shown it a decade ago and have used it since (after a couple prior years of primitive tmux use).

If you don't want to write a giant regex like this yourself, there are some ready-made tmux plugins that add things like this to copy-mode.

https://github.com/tmux-plugins/tmux-fpp

https://github.com/tmux-plugins/tmux-copycat

https://github.com/Morantron/tmux-fingers

https://github.com/tmux-plugins/tmux-urlview

Any configuration or plugin that leans on the built-ins is probably going to be faster, so consider that w/r/t tmux-copycat.

I also really like tmux-resurrect, which saves and restores sessions for you; tmux-continuum, which runs those automatically; and the tmux-zen plugin for Oh-My-Fish:

https://github.com/tmux-plugins/tmux-resurrect

https://github.com/tmux-plugins/tmux-continuum

https://github.com/sagebind/tmux-zen/tree/master

It's pretty easy to get a very nice tmux setup going!

The one thing pulling me towards VS code, and away from terminal workflows is Copilot and the Agent workflows. Being able to seamlessly chat with AI models and then see/review its code changes is the biggest change to my workflow and productivity in years.

I’m guessing some people already have these capabilities integrated into terminal workflows and I’d love to see a demo/setup.

The entire blog post being in lowercase distracted me more than I thought it would.

terminal scrollback is the only UI we don't treat as queryable state. op's setup shows how much context we're missing away a lot of rg output, file paths, stack traces, build logs they're all already right there in cluttered state.

if shells exposed a scrollback api with line refs and structural tagging, we could annotate paths, link to buffers, diff last two runs, all without re executing anything. that would cut through half the indirection in current workflows. tmux's regex jump is a hack but it hints at a deeper model. scrollback should be its own memory layer

The article title is actually "How I use my terminal"

  sudo !!

It is sad that we have to know how to configure tens of small utilities just to be productive. I ended up using emacs with some packages that I configure minimally, after spending a few hundreds of hours on ricing the shell, file managers, tmux, etc

I do all of this from vim. I have \a bound to repeat my last / search using ripgrep in the current directory, and open the matches in a panel below. I have \gd bound to go to the definition/declaration of a symbol.

Fantastic. Been meaning to put something up like this myself. I feel like I gain so much information from just watching someone work, and having them open themselves up to questions.

> Escape for some reason doesn't get sent as the escape key if it shows up next to any other keys???

Welcome to ANSI escape sequences. The left arrow key, for example, is really just <Esc>[D . You can see this stuff for yourself by running `cat >/dev/null` (cat isn't actually doing anything useful here, it's just allowing you to type without the shell getting in the way and actually, you know, making an attempt to interpret the keys you press). Press backspace to figure out which bytes are represented by 1 and which by 2 characters. 2-character sequences where the first is a caret (^) can be produced by ctrl + the second character, and correspond to the second character in ASCII minus 64. Hence ^A is byte 0x01. The escape key sends ASCII ESC, number 27, and is written ^[ .

https://en.wikipedia.org/wiki/ANSI_escape_code

Software distinguishes between a bare Escape key press and an ANSI escape sequence by waiting a couple of milliseconds and seeing if more bytes arrive. The number of milliseconds is often configurable, with e.g. the 'escape-time' config key in tmux and the 'ttimeoutlen' setting in vim.

I have a similar setup, but most of the functionality is coming from vim: grep/find, quickfix lists and temporary buffers: https://news.ycombinator.com/item?id=44282908

I've shared similar frustrations with VSCode's vim plugin. These days, I often run Neovim from within VSCode's terminal for complex editing tasks where I might need to use macros or use fugitive or whatever.

I miss the console terminal where Alt-F# directly selects a terminal by index. So:

    bind-key -n M-F1 select-window -t :0
    bind-key -n M-F2 select-window -t :1
    bind-key -n M-F3 select-window -t :2
    bind-key -n M-F4 select-window -t :3

    bind-key -n M-F5 select-window -t :4
    bind-key -n M-F6 select-window -t :5
    bind-key -n M-F7 select-window -t :6
    bind-key -n M-F8 select-window -t :7

    bind-key -n M-F9 select-window -t :8
    bind-key -n M-F10 select-window -t :9
    bind-key -n M-F11 select-window -t :10
    bind-key -n M-F12 select-window -t :11

I use my terminal too, but VSCode runs fast enough for me. Maybe it's because I'm a mid 30s year old boomer now, but I figure if it's caching symbol tables then the lag isn't the end of the world.

But for whatever reason, I'd rather vimdiff when I have to resolve conflicts on rebase.

What I really hate about VSCode currently is how huge pylance is though, and how it's all up in my grill when I am trying to manually code.