[therealmarv]

My biggest complaint: Normal Copy and Paste does not work. My mother is used to Copy and Paste and it would work in Linux but not in macOS finder because of: think different

Also why are folders sometimes cluttered all over the place and shorts cuts so weird?

Well I fixed it all with Forklift but I also grew up with Norton Commander ;)

[Klonoar]

What about copy and paste doesn't work...? I use that feature daily.

And for the clutter, you can configure Finder to be more militant in how it displays/orders things.

The only gripe I have with Finder is needing to set up a million QLPreview things to do better spacebar peeking. Otherwise, it's fine - it "just works" and isn't fancy.

[spideymans]

Can you elaborate? Copy and Paste works exactly as I'd expect in Finder.

[chrisseaton]

I think they possibly mis-spoke and mean cut-and-paste, which does appear to be intentionally permanently disabled in Finder via the menu or shortcut. But you can drag so it's not a huge issue to me. Copy-and-paste works a-ok.

[carlosrg]

Cut-and-paste on Finder works perfectly fine too. It's Cmd-C and then Option-Cmd-V on the destination instead of Cmd-V.

Alternatively hold Option when opening the Edit menu.

[oneeyedpigeon]

That's not cut-and-paste. That's copy and some weird modified paste that, as far as I'm aware, doesn't exist anywhere else. Why completely break the existing convention?

[spideymans]

>Why completely break the existing convention?

Because cutting-and-pasting is a destructive action that can lead to data loss.

Under the conventional implementation of cut-and-paste, it's easy for a user to inadvertently cut-and-paste a file, when they meant to copy-and-paste said file, either through a misclick or, by hitting the wrong keyboard combination. This is because:

1. The menu option for cut is right above the menu option for copy

2. The keyboard shortcut for cut (command-c) is just one key away from the keyboard shortcut for copy (command-c) on a QWERTY keyboard

Cutting and pasting deletes the file from its original directory, however under a traditional cut-and-paste operation, the system does not ask for confirmation. Consequently, if a user mistakenly cuts a file or directory without immediately noticing their mistake, their files could be rendered unrecoverable (and keep in mind that there's no particular reason why they would notice... the UI provides no special indication when a file or directory is deleted via cut-and-paste). This is arguably a very bad user experience.

The equivalent action to cutting-and-pasting on OS X is copying, pasting and then deleting the original file. By adding in this extra step, the UI has forced users to acknowledge that their action is potentially destructive and unrecoverable.

Also notice that the command-x shortcut in Finder copies a file. It does not cut the file. Again, this protects the user from inadvertent data loss if they use the wrong keyboard shortcut.

It's a rather unusual move Apple has made here by breaking convention, but I think they've made a wise wager that users would rather be annoyed by a small extra step, then be faced with the loss of important data.

Thinking about this design choice, I now wonder how many times I've had files mysteriously go missing on Windows and other operating systems simply because I used CTRL+X when I meant to use CTRL+C

[yyyk]

>Thinking about this design choice, I now wonder how many times I've had files mysteriously go missing on Windows and other operating systems simply because I used CTRL+X when I meant to use CTRL+C

Zero. If one CTRL+Xs accidentally, Windows and most Linux Desktop pickers change the highlight colour before the copy. At worst you can CTRL+Z it after or copy it back. It's not a 'destructive' operation since you always have one copy of the file.

It's a typical case of Apple deciding users are stupid and therefore should be limited, combined with the typical 'just everything Apple does' syndrome.

[oneeyedpigeon]

I take your point. I can't be certain why, because it's been so long since I used Windows, but I never found this to be a problem in practice — maybe I was just lucky. I guess you could make the same argument about cut in any context, except:

a) you could argue that cutting text isn't as destructive as deleting a file, although they could be one and the same if you happen to have an entire file's text selected

b) mechanisms for undo'ing text operations tend to be more sophisticated than undo'ing filesystem operations; I might argue that's a separate problem to be resolved

I'd be perfectly happy if this were an option, buried in some obscure preference panel somewhere, labelled "yes, I really want to shoot myself in the foot" but, as it stands, I don't even get that.

[chrisseaton]

> Because cutting-and-pasting is a destructive action that can lead to data loss.

Isn't this the same for all cut-and-paste? It's expected.

What's special about files that mean they need special protection?

Pop them in the Bin until they're pasted if you want.

It's not as unfathomable as you make out.

[carlosrg]

>the existing convention

It is the existing convention, the Mac Finder convention. And yes, it's effectively the same as cut and paste.

[oneeyedpigeon]

Do you not think that it's terrible UX, to have cmd+x followed by cmd+v for cut and paste in some places and cmd+c followed by option+cmd+v for cut and paste in others?

[chrisseaton]

> It is the existing convention, the Mac Finder convention.

I think the point is this doesn't match the convention in the rest of the macOS. A convention of one is a poor convention!

[pseudalopex]

macOS came first.

Other file managers don't really cut and paste. They have a weird modified cut that doesn't exist anywhere else.

[chrisseaton]

> Alternatively hold Option when opening the Edit menu.

This doesn't change the Edit menu for me. Does it work for you today on latest macOS?

[Kwpolska]

It does change the Edit menu in Finder on Big Sur.

[chrisseaton]

Well doesn't for me - strange. It does change 'copy' to 'copy as pathname' though.

[saagarjha]

It's not permanently disabled, it enables itself when you are editing text (for example, if you're renaming a file).

[chrisseaton]

I think we're talking about copying-and-pasting files in this thread, rather than text in input boxes, as you're thinking.

[saagarjha]

No, I know that. I'm just providing insight as to why that menu item is there and when it enables itself.

[oneeyedpigeon]

I think they mean cut+paste to move a file.

[therealmarv]

I meant the standard cut and paste and short cuts. Sorry.

[sercand]

Copy, Cut, and Paste works just fine. I use the following default shortcuts:

Cmd+C: Put file to Clipboard

Cmd+V: Copy file in Clipboard

Cmd+Option+V: Move file in Clipboard (aka Cut)

[Teever]

I actually filed a bug report with Apple in 2005 regarding the inability to cut and paste files in Finder.

They actually responded a few years later and said that this is the intended functionality.

Maddening.

[Zarel]

They do support copy and move, which I think is clearer that the file doesn't get deleted if you don't "paste" it (and safer than if it did).

It's probably annoying to learn a new paradigm, but you could make the argument that it's worth it to learn something that isn't lying to you.