FR: Swap Ctrl-V and Ctrl-P in the Events Editor

[MjnMixael]

OK, hear me out. Ctrl-V is Paste. We all know it as paste. It makes sense that it's tied to Paste in the Events Editor. For those that don't know, Ctrl-P is print.. er I mean Add Paste. I propose we swap that. Ctrl-V for Add Paste and Ctrl-P for Paste. Here's why.

1. Add Paste is the more common transaction. My evidence is anecdotal, but I definitely add paste way more than just paste. Ctrl-C, Ctrl-P is much more of a stretch than the Ctrl-C, Ctrl-V I use so often in general computing. That's important because the Events Editor is still M&KB required controls. You rarely have both hands on the keyboard.
2. Paste is destructive where Add Paste is not. If you paste over something accidentally, it's gone... with no way to get it back because we don't have Undo in the Events Editor. As an experienced FREDer, I have nightmares about Paste. The easier it is to Add Paste instead of Paste the better.
3. P is for Paste not for Add paste in a sane and sensible universe. (This isn't really a third reason, but it's my FR... I can write what I want.)

[Goober5000]

Strong no on this one. Paste is a standardized operation; Add Paste is not. Intuitively, the standard shortcut should go with the standard operation and the non-standard shortcut with the non-standard operation.

This is also anecdotal, but I use the shortcuts for Paste and Add Paste about the same, and the distinction between the two is clear. Switching the shortcuts would add extra cognitive load to every use of both shortcuts which would take away the advantage of shortcuts in the first place.

Now, one way this could work is if customizable key bindings were added to qtFRED. Then anyone could remap the keys to their heart's content.

[MjnMixael]

Actually. One further thought. You're objectively wrong on paste. In normal operations, I have to select something in order to replace it. Think text. Normal paste with no other input is add paste.

[MjnMixael]

Think files in the OS. Default behavior when copy/pasting copies is to create a duplicate. Not replace. It's always additive.

[Goober5000]

But selecting things is intrinsic to how the event editor works. There's no way to get a paste context without selecting a node.

[EatThePath]

Personally I strongly agree with the request and the reasons for it. If someone is going to on reflex from other software try to copy and paste an event, I think it is most likely that they will want the "add paste" behavior. In fact as a relatively recent newcomer to FRED I occasionally forget even using the right click menu that "Paste" doesn't do what I want it to and end up overwriting usually quite a lot of work as a result. For that reason I'd suggest also renaming the options "Paste Into" and "Paste Over".

Yes, you are technically selecting something and so from a certain perspective it makes sense to overwrite instead of insert, but given that there is no way to 'position' in the events editor I think that's a point without much weight. A new or infrequent fred user is much more likely to absent mindedly or ignorantly use ctrl+v than ctrl+p, so it would be best to have that be the less destructive option.

The only reason I would hesitate to push for it is that anyone who is adept at using those shortcuts now will be thrown off by the change. It's hard to say if that's an acceptable cost or not, surveying all fredders and seeing how much they think it would affect them is probably not practical. That said I think rebindable keys are a must in qtFRED, and sane accessible defaults are also a must. If it can't be implemented in FRED it should definitely be done in qtFRED, probably with a prompt at first startup to choose between new and 'classic' keybinds.

Also ctrl+shift+v would be a much better bind to move "Paste Over" into imo, in part because of the original point 2

[Goober5000]

Paste means "replace my selection with what's in the clipboard". That's a long-established convention, both in FRED and in general. Strictly speaking Add Paste isn't even a Paste at all, because it operates at the child level rather than the level of the cursor. It might be more appropriately called Append, or maybe Add Child From Clipboard.

The main reason the Paste/Add Paste distinction is such point of contention is because the cost of an accidental overwrite. The problem should be fixed at its source: add Undo capability to the Event Editor. It's my understanding that this has either been done or is on the roadmap for qtFRED.

As someone who has used FRED for years, continues to use it, and even fixed keyboard shortcuts for it, changing the shortcuts to do the opposite of what they do now would be a step backward in usability.

[MoerasGrizzly]

The action of "paste" being an insertion rather then an overwrite has been a standard in computers since vi. There's no reason why FRED of all programs should suddenly break this convention.

[Goober5000]

Paste is a replacement, not an insertion, if something is selected.

[EatThePath]

This particular shortcut was added a year or so ago, right? At Mjn's request even, I believe. In which case yes shuffling random shortcut keys that have been there for 20 years would be a costly move, but this is only fighting a year-ish of muscle memory, and I'd wager a lot of fredders haven't noticed the addition yet even. Still not without a cost, but one of a very different magnitude.

[MoerasGrizzly]

Paste is a replacement, not an insertion, if something is selected.

So when I select a folder in Windows Explorer's filetree (the filetree that FRED's event editor is emulating), and I select a folder that contains multiple files, and press CTRL+V, this entire folder is replaced irreversibly by a single file?

No off-course it is not. The file is pasted into the folder I just selected. Since this is how filetrees work. You'd expect FRED to be able to follow that convention since it's very deliberately designed to look like a filetree. And yet it doesn't.

[Goober5000]

@EatThePath The Ctrl+X, Ctrl+C, and Ctrl+V shortcuts should correspond to the standard conventions. But if someone wants to propose an alternate shortcut key for Add Paste, that's certainly an option.

I will say that if this is how Mjn treats people who implement feature requests for him, it really dissuades them from implementing any such requests in the future.

[EatThePath]

FRED event tree editing is an idiosyncratic enough context that I think it's unreasonable to say either form of paste is exactly analogous to the standard behavior, and so while I still lean in the opposite way I don't think it's useful to argue that point into the ground. Though I think @MoerasGrizzly's analogy is a strong one.

Without getting into the weeds of how the interactions were handled in detail, a user experience/quality of life feature has been implemented at a user's request, and then that same user has(albeit after considerable delay) let it be known that the way it was implemented was less then ideal in a way that is relatively trivial(in terms of implementation, not potential user disruption) to address. To my mind that should be given some weight.

[MageKing17]

There may be a legitimate concern about Ctrl+P going from non-destructive to destructive, but in that case, I'd rather change "replace paste" to Ctrl+Shift+V as EatThePath suggested earlier, and still having add paste be Ctrl+V.

[MitoPL]

I usually wouldn't chime in but I guess I can help a bit. I personally agree with the changes suggested. In every text editor I've interacted with, Ctrl+V was non-destructive, unless you actively put in the effort to select a piece of text instead of just moving the cursor to the desired paste location. In a software dev program I'm using a bunch lately, in which you build sequences of conditionals called networks, the paste function always pastes the entire network you have in your clipboard above the network you're selecting a component of. I don't think said program even has the possibility of destructive pasting (unless the modes are switched via Insert key) which has saved me plenty of sanity as its undo feature is absolute garbage that remembers only a single action and errors out half of the time.

So yes, I'm very in support of making Ctrl-V non-destructive and using the aforementioned Ctrl-Shift-V for destructive pasting. That way you get a very intuitive pasting mechanism that also requires a conscious decision to delete things when pasting.

I understand this is a band-aid for the lack of decent Undo function or a modern event editor in general, but it's also a useful interface improvement that will save every user a bunch of annoyance. And I presume this change is easier to make than either of the other two?

[Karajorma]

I'm with the rest on this one. No one expects CTRL-V to do something destructive. If the issue is maintaining CTRL-V as meaning paste we should simply rename the paste option to paste & replace or paste over. Just cause Volition made a mistake when choosing names doesn't mean we should maintain that mistake past the point of logic.

[tomimaki]

Add same thing for QtFRED?

[naomimyselfandi]

Maybe I'm late to the party, but I'd just like to add my support to making Ctrl-V non-destructive. I don't even want to think about how much work I've lost to hitting it when I wanted Add Paste... or my finger slipping when I'm going for Ctrl-C.

[EatThePath]

@naomimyselfandi We've hashed things out and there's an approved pull request right now that makes ctrl+v "add paste" and moves classic paste to ctrl+shift+v. The change will most likely be in the next nightly build.

@tomimaki Propagating the change to QtFRED seems entirely prudent. Hopefully someone handy with QT can pick up the torch for that.