4 ms·

> Unlike Vim, Amp doesn't provide split panes, and support isn't planned That's a pretty big missing feature that is included in vanilla vim...

MaxBarraclough 8y ago
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.
- fouc 8y ago
  Why not just rely on tmux panes?
  - Narishma 8y ago
    Not everybody uses tmux for one.
  - MaxBarraclough 8y ago
    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.
    - wasted_intel 8y ago
      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! :)
      - jolmg 8y ago
        > 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?
        wasted_intel 8y ago
        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.
        jolmg 8y ago
        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.
        wasted_intel 8y ago
        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.
wasted_intel 8y ago
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 8y ago
  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 8y ago
    Ah, you're right; thanks for clarifying!
    - em-bee 8y ago
      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 8y ago
        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.

MaxBarraclough 8y ago

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.

fouc 8y ago
Why not just rely on tmux panes?
- Narishma 8y ago
  Not everybody uses tmux for one.
- MaxBarraclough 8y ago
  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.
  - wasted_intel 8y ago
    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! :)
    - jolmg 8y ago
      > 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?
      - wasted_intel 8y ago
        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.
        jolmg 8y ago
        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.
        wasted_intel 8y ago
        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.

wasted_intel 8y ago

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 8y ago
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 8y ago
  Ah, you're right; thanks for clarifying!
  - em-bee 8y ago
    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 8y ago
      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.