cqexbesd
commented
1 year ago Your "viable solution" suggestion is how I had conceptualised vi mode. I had assumed I was just editing a buffer and not sending anything to stdin straight away. I hadn't realised (probably because I hadn't copied a \n) that things were live. I think there are pros and cons of both systems. I think your viable solution would be nice sometimes but perhaps not that often so I wouldn't prioritise it.
If you did do it, perhaps the buffer could be edited freely, not just with copy and paste - once you are editing the input buffer why restrict yourself? Maybe invoke $EDITOR on it. However while it sounds nice I probably wouldn't actually use the feature that much over just copy and paste so I wouldn't prioritise it particularly (unless others are keen) - certainly not over supporting more forms of yank (I often try e.g. yw, y$, ytx, yi" (though the last two might be from a plugin) and I am stretching my memory on how to quickly yank in the terminal without them - which is the common cause of me pasting something unexpected and wanting undo).
While having given it more thought now, I still want to track this, and I think, iff at all, it's almost impossible to implement due to the side effects of what
paste-action is doing.Pasting clipboard
This is actually reading the system clipboard and writing it to the applications
stdin(wrapped around bracketed paste VT sequences)Undoing this action
I first thought it might be doable, as one could buffer the paste action and delay the actual paste operation until insert mode is activated again. That however is only possible for trivial cases iff we also want to visualize the paste action by having it printed to the screen. However, neither the printout is done by the terminal (unless
ECHOflag is set on the PTY device, but then it's the kernel mandating this echo action) - nor can we "unread" the data that we have previously written to. This becomes more complex (if to be visually ECHO'd) when newlines are implied.The only viable solution maybe is ...
The only viable solution to that problem may be to not visualize the paste at the position where the cursor is, but to simply indicate the number of pastes pending in the indicator status line (which is always visible in normal mode!) and how many paste actions have been done.
This way, we could implement an
undo-action and simply drop from the tail of the pending paste queue when a paste has to be undone.The paste would then be flushed when moving back to insert mode (pressing
i), which I think would not be too unintuitive.I think such an option should probably be configurable because I believe some people might like it and some might not.
Visualization in the indicator status line
We could add a paste-pending indicator to it, some string like
"PASTE PENDING: %d"with%dbeing a positive integer >= 1 indicating how often someone pasted something.paste quantifier
Since one can paste more than once in one go, e.g.
5p, these 5 pastes should be undone with one singleu.