[wasted_intel]

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! :)

[em-bee]

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.

[wasted_intel]

Ah, you're right; thanks for clarifying!

[em-bee]

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.

[wasted_intel]

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.

[em-bee]

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.