> I try Zed and VSCode and I always come back to this setup.

I have Ctrl+` set to switch focus between the editor and the terminal panes in VSCode, so I can toggle between them pretty easily as this is also my workflow

If anyone's wondering, here's what I have in my keybindings.json

    {
        "key": "ctrl+`",
        "command": "workbench.action.terminal.focus"
    },
    {
        "key": "ctrl+`",
        "command": "workbench.action.focusActiveEditorGroup",
        "when": "terminalFocus"
    },

ctr+` is the default behavior on VS Code I use it all the time and I didn’t set it up and I’m sure as hell neither did my co workers.

It’s a nice short cut if you have a keyboard with backtick to the left of 1 in the numeral row. If you’re from a country where keyboards have a different key there, I would recommend setting up a short cut manually.

It only opens the terminal by default. The key binding is to use the same shortcut to focus back to the editor.

It does that by default too.

It didn't when I set it up, but I haven't removed the keybindings to test if this has changed recently.

Nope. It minimizes the terminal by default, at least on macOS. These keybinds leave the terminal / lower bar open and just shift focus back to the editor.

I can’t tell if Ctrl-` is portable. Anyone know if it’s representable on terminals?

I've always just closed vim to use the terminal, and started it up again to go back to editing. I find it difficult to operate any other way.

I know people who use ^Z to suspend vim and then foreground it again.

> I've always just closed vim to use the terminal

You don't mind losing all your editor state? If you don't like working with multiple terminal windows, why not open a term within vim with `:term`?

I don't lose any editor state, at least nothing I care about.

In my configuration vim will save (among other things):

- Cursor position

- Undo history

- Register state

:term is clunky for me, mainly because my muscle memory is to just :wq

I got it working as seamlessly as I could once just in an attempt to use it but I stopped pretty quickly.

What editor state are you losing when you leave vim?

I run a pretty light vanilla vimrc (60 lines maybe) and with two lines you can enable vim undofiles and returning the cursor to the last location upom reopening a file. For me, quitting vim is functionally equivalent to ^Z?

You may lose LSP state like rust-analyzer's which takes a while to restore. You may lose opened buffers and positions within them (unless you have some session restore logic which may also take time), window layout, copy buffers, edit history and lots of other state.

Ah I don't run any LSPs so that's fair.

Retaining positions, buffers, and edit history between sessions is all straightforward in vanilla vim though. Unless you run an autolinter or formatter that edits your target file and wipes the history.

For that there is ra-multiplex (to which I contributed sockets support).

I don't use any other LSPs which have a long warmup time, but if I did then they can also be used behind ra-multiplex.

You lose the open windows/tabs. Apart from trivial one-off scripts I basically never have only a single tab open.

I don't use tabs, sometimes I use split windows (usually only when vim-diffing), mostly I use multiple terminal windows in a tiling WM. I do use multiple buffers but I usually don't care about editing more than one or two at a time and it's easy to re-open these whenever I need to.

That's true for me too but usually my tabs and windows are managed one level higher, by the terminal emulator, or I'm opening vim with -o/-O to open a split window directly.

I’ve definitely done the ^Z thing. The catch is to remember you did it if you get distracted in the terminal. Nothing like finding some vim job in the background and you can’t remember what it was.

For me it only works because I never reuse a single terminal for unrelated things. Additionally, I have my virtual desktops grid set up so that different types of tasks are always in certain places, so if the switcher shows a terminal somewhere, I know roughly what it's for even without going to look at it. So I can't "lose" a terminal.

So it's fine for X11 terminals, but not for /dev/tty2

Don't forget you can just :!some-shell-command though - not just in vim but in lots of programs even.

Another (neo)vim+tmuxer chiming in. One major missing feature (compared to vscode) is opening file links from the terminal back in vim. It was such a major pain to me, so I ended up writing a tmux plugin to solve it. I thought you might find it useful - https://github.com/artemave/tmux_super_fingers

Yeah the tmux / vim combo is so hard for me to beat with other editors still. I used Zed exclusively last month thinking the LLM integrations would be a compelling enough reason to finally switch. Like the post author, I'm a little fatigued with config / plugin churn since I switch languages frequently and it always takes some customizing to make vim work well when I do that.

As the author describes though, I found myself copy-pasting a lot between LLM chat and editing buffers. In tmux, I have a really simple function that copies select panes (using tmux capture-pane) into my prompt, or I can give it full files for context. Most of the time though, I can do something like `llm -t 0 -t 1 'what is this libSSL error indicating? here's my code', where -t 0 gives it my vim pane and -t 1 gives it the terminal I'm running things in. I've been surprised that this somewhat rudimentary approach has felt far more effective than the more sophisticated editors I've been trying.

Is this just me? Does it seem to others that the LLM-enabled editors coming out these days still require a lot of copy-pasting of context that can be easily provided with just a dump of tmux output?

Everything-is-just-text might be crude but dang does it make quick and dirty LLM integrations a snap!

I use tmux and neovim along with the copilot plugin[0]. I prefer it over the VSCode copilot integration, to me it feels less obtrusive and out of the way, which is what I want. You're also not dealing with API costs since it uses the regular Copilot subscription.

[0] https://github.com/github/copilot.vim

codecompanion.nvim has some pretty nice ways to get context into the llm chat without copying and pasting.

have you tried cursor?

i had the same workflow but now i use zed w/ tmux (tmux inside the zed terminal)