Hi
Would there be a way to move finder selection by using Cmd-X then Cmd-V instead of the native solution to press Command+C, then Option+Command+V
Thank you
Eric
Yes. You could do this by having two Macros, only active in Finder.
The first Macro is triggered with ⌘X
It replicates the copy command
Then it makes the second macro (the paste Macro) Active
When active the second Macro is triggered by ⌘ V
It replicates the key stroke ⌥⌘V
Then it deactivates itself
So, basically selecting something in the Finder and pressing ⌘X initiates the process of cutting rather than copying.
But I wouldn't recommend actually doing this. Things could get messed up if you didn't follow the process through in one go. And it is fighting the way the Mac works. Much better to adapt to the Mac way of doing this when working on a Mac and use the PC method when working on a PC.
1 Like
Thank you!
I did try this but w/o the activation / deactivation process. I’ll try it. The best would be to activate the second macro if there were a selection when triggering the first one.
I understand your point of view, but I rather thing this is a feature that is missing on MacOs where using it on text selection is working well
(I know there is a free tool that emulates the feature. But I would like to avoid too many running app)
You could add that to the first Macro:
The first Macro is triggered with ⌘X
If something is selected in Finder then -
It replicates the copy command
make the second macro (the paste Macro) Active
Otherwise do nothing
EDIT - Ignore all this - there's a much simpler and safer way to do exactly what you want. See my post below.
For the risky reason stated above I would add a timeout to at least reduce the risk.
1 Like
I was just about to add in that timeout to my original solution and then I realised there's a really simple way to get what @Eric007 wants...
⌘X for Cut v02.kmmacros (2.9 KB)
It just uses one Macro and I think it's pretty safe. In fact the sad thing is I think I came up with this same solution a few years back and then forgot...
Isn't that moving a file to the Trash? I wouldn't be comfortable doing that before moving it elsewhere. Or am I not understanding something here?
1 Like
No -- it's a safety feature that it works the way it does, helping prevent accidental file deletion. If you Copy a file then accidentally Copy something else before Pasting, no harm done -- if you Cut it then accidentally Cut/Copy something else...
What you might be able to do is use ⌘X (but only in Finder, and only when Cut isn't an available menu item) to put the current %FinderSelections% into a Global variable and activate your "override ⌘V" macro. Then ⌘V to execute a KM "For Each: Move a File" that moves each item listed in the Global to %FinderInsertionLocation% and then deactivates itself.
You'd still have the problem of the "override ⌘V" macro remaining active if you changed your mind half-way through, though -- and could miss out on other "convenience features" like the OS's handling of name clashes.
1 Like
It's basically doing exactly what ⌘X does when you use that key combination on text of anywhere else where a "cut" is allowed.
It copies the item to the clipboard and then removes the item from where it was. Following that with a normal ⌘V will paste it into the new location (as although it has been deleted it is in the Clipboard).
Interestingly, there is already a "cut" command in Finder but only for text (like a filename).
Thinking about it, this method (copy followed by delete) is safer than the normal "cut" as the item can always be recovered from the Trash if it was "cut" by accident.
But I think best advice is just to get used to the way the Mac handles this with Finder Items, with a "copy" followed by a ⌥⌘V
3 Likes
I think we can also (assuming it is turned on!) make use of KM's Clipboard History. I haven't tested extensively -- does it work if you've emptied the Trash in-between? -- but it worked for quick recovery.
One point that should be made -- if you Copy and Paste a file it is not the same file. The data will be the same and most (if not all) the metadata will remain in place, but it is a new file -- the inode number changes. Compare that with the "normal" Finder move where the inode number remains the same (assuming a move within the same file system) and you're really just changing the path to the file in the file system's database.
That may, or may not, matter 
1 Like
How about another approach, that solves both the safety (no deletion unless successfully moved) and file identifier (no new identifier created) problems? These two macros work together to change how ⌘X and ⌘V work in Finder.
When the user presses ⌘X, the Cut macro kicks in:
Download Macro(s): Move Files- Cut.kmmacros (6.2 KB)
Macro notes
- Macros are always disabled when imported into the Keyboard Maestro Editor.
- The user must ensure the macro is enabled.
- The user must also ensure the macro's parent macro-group is enabled.
System information
- macOS 15.7.1
- Keyboard Maestro v11.0.4
If a Cut menu item is enabled (i.e. text is selected), the macro simply executes the Cut command. But if it's not enabled, then the macro checks if Copy is enabled. If it's not, nothing is selected and the macro exits.
But if Copy is enabled, then there's a file or folder selection, and the macro displays a notification with the list of files (or folders) to be moved, and then runs the Copy command.
The files are copied to the clipboard, and still safely in their starting location. When the user presses ⌘V to paste the files, macro number two kicks in—the Paste macro:
Download Macro(s): Move Files- Paste.kmmacros (6.9 KB)
Macro notes
- Macros are always disabled when imported into the Keyboard Maestro Editor.
- The user must ensure the macro is enabled.
- The user must also ensure the macro's parent macro-group is enabled.
System information
- macOS 15.7.1
- Keyboard Maestro v11.0.4
If there's a "Move (n) Item(s)" menu available, the macro executes it, moving the previously-copied files using the actual macOS command, so the files are moved, not copied and deleted.
If that menu item doesn't exist, but the Paste menu item does, then the macro runs the usual Paste command. If it's not enabled, there's nowhere to paste, so the macro exits.
In my testing, this seems to work quite nicely, with minimal lag. I think I've caught all the possible conditions, but I have not spent hours and hours on this, so there may be edge cases. But because the macro only uses Copy and Move, files should never be in danger of being lost. Still, the usual warning applies...
Use at your own risk, and have a good backup in place! 
-rob.
3 Likes
I’m going to be that guy, but is it SO hard to press Cmd-C Cmd-Opt-V ?
Sure, you’re perfectly right Johns. Let’s say thanks to this post I have learnt a bit more about KM - thank you @griffman, I didn’t known about Semaphore Locking -
BTW, The Command-X app of Sindre Sirhus (➔ Command X — Sindre Sorhus ) is a good alternative but I want to minimize the app being able to access all my files.
I really wouldn't worry about that -- the developer is well-known (for good reasons!) in the Mac community and the app is available from the App Store rather than some shonky download site. I'd have no more worries about allowing Command X full disk access than I would Mail, TextEdit, Keyboard Maestro...