100% deferring to tmux, there. It just adds so many great features, I think it'd be a mistake to re-implement them in Amp. Paired with the fact that Amp is cheap on memory, and has native clipboard integration, this isn't as necessary as you might think; you can still move content between panes! :)

with split panes in vim i can have the same file open at two different places. can't do that with split panes in tmux.

greetings, eMBee.

Ah, you're right; thanks for clarifying!

also, i developed a plugin for vim that compiles code for me and sends the output to a second buffer.

sure i can make that work with tmux. codewise it would even be easier, but only if i can trust the user to put all the pieces together for themselves.

if i want to build an end-user friendly package, the whole thing suddenly becomes a lot more complex:

it's no longer enough to say: load this into vim and you are done, but i need to check that tmux is not only available but that the editor is running inside it as well. and i have to prepare that users will ask me to make this work with screen or any other tmux alternative.

greetings, eMBee.

It's possible to run a command in another tmux pane; I forget the specific syntax but I've tested this in the past and it works. The only thing the editor needs is a task runner (this is a planned feature for Amp); the task that's run is prefixed with the tmux command that triggers it in another pane.

The only thing that's bespoke to tmux is knowing which pane to target; you'd need to collect that from the user on the first run, or allow the value to be configured.

i would split the current pane by default, and allow the user to define the whole tmux command used to splitting. (that way they can even replace tmux with something else that works instead.

Could make do with tmux panes I suppose, but I agree, if you're going to go head to head with Vim that's a big omission.

Why not just rely on tmux panes?

It'd prevent me using the Vim clipboard ('registers') between files. That's bad enough. It'd also prevent me using Vim macros to easily shuttle data between files.

I may also want to ctrl-z Vim to run a few quick commands before resuming Vim with fg. Using tmux panes, I'd only get a small window to run those few commands, which doesn't reflect my intent. (Yes, I could use another tmux window for this, but I like this way.)

I suspect it would also mean more keystrokes.

Amp has native clipboard integration, so content will carry between different instances. Configuring the register => clipboard was something I personally disliked when configuring Vim.

Amp also supports suspending (hit "z" in normal mode) as I use that workflow all the time. As for the small window issue, you can "zoom" a tmux panel with <leader>-z. I get that this is less than ideal if you're used to the suspend action collapsing all panes by default (and expanding them on resume). Workflows are tricky; to each their own, I guess! :)

> Amp has native clipboard integration, so content will carry between different instances

By "native" does that mean an X-server's clipboard? So when you're running it on a machine that has no X-server running (a typical server), there is no clipboard?

Amp has an internal clipboard that it synchronizes to an external/native equivalent, if available. You'd still be able to copy/paste within a single Amp process, but you would lose the ability to do the same between separate processes.

Right, so in the context of this discussion, tmux panes are not a good substitute for vim windows, since you wouldn't be able to copy-paste between them unless what you were copying fit in a single pane-full.

Yes, that's correct. :)

In that scenario, I would compromise by opening both files in the same Amp process and switch between them, but that's not the same as seeing both at the same time.

Not everybody uses tmux for one.