4 ms·

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

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.

chrisseaton 6y ago
> 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 6y ago
  It does change the Edit menu in Finder on Big Sur.
  - chrisseaton 6y ago
    Well doesn't for me - strange. It does change 'copy' to 'copy as pathname' though.
oneeyedpigeon 6y ago
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?
- carlosrg 6y ago
  >the existing convention It is the existing convention, the Mac Finder convention. And yes, it's effectively the same as cut and paste.
  - oneeyedpigeon 6y ago
    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?
    - deleted 6y ago
      [deleted]
    - pseudalopex 6y ago
      I think it's terrible UX for cut to mean different things in Explorer and Word.
  - chrisseaton 6y ago
    > 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!
    - carlosrg 6y ago
      If you mean cut text and so on, it doesn't match because they're not the same thing. When editing a text document, if you cut some part, it actually goes away. If you saved the document at that point, that selection would be gone. On files, if you cut a file on Windows for example, nothing happens. Until you paste, no operation is done. So it's not the same thing, and I think the way Finder handles it makes more sense.
- spideymans 6y ago
  >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
  - chrisseaton 6y ago
    > 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.
    - spideymans 6y ago
      If I accidentally cut-and-paste from a text document, the absolute worst case scenario is that I lose the contents of the text in that document. It's a bad situation, but the damage is limited and contained. If I accidentally cut-and-paste a file or directory, the damage could be immense. Years worth of important documents, records, photos, etc... could be gone, because the user's finger slipped and pressed CTRL+X, rather than CTRL+C. Whether or not the operating system should be protecting users in this manner is fully debatable and a matter of opinion, but Apple's approach here is definitely safer (at the cost of being a bit more annoying)
- pseudalopex 6y ago
  macOS came first. Other file managers don't really cut and paste. They have a weird modified cut that doesn't exist anywhere else.

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.

chrisseaton 6y ago

> 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 6y ago
It does change the Edit menu in Finder on Big Sur.
- chrisseaton 6y ago
  Well doesn't for me - strange. It does change 'copy' to 'copy as pathname' though.

oneeyedpigeon 6y ago

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?

carlosrg 6y ago
>the existing convention It is the existing convention, the Mac Finder convention. And yes, it's effectively the same as cut and paste.
- oneeyedpigeon 6y ago
  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?
  - deleted 6y ago
    [deleted]
  - pseudalopex 6y ago
    I think it's terrible UX for cut to mean different things in Explorer and Word.
- chrisseaton 6y ago
  > 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!
  - carlosrg 6y ago
    If you mean cut text and so on, it doesn't match because they're not the same thing. When editing a text document, if you cut some part, it actually goes away. If you saved the document at that point, that selection would be gone. On files, if you cut a file on Windows for example, nothing happens. Until you paste, no operation is done. So it's not the same thing, and I think the way Finder handles it makes more sense.
spideymans 6y ago
>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
- chrisseaton 6y ago
  > 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.
  - spideymans 6y ago
    If I accidentally cut-and-paste from a text document, the absolute worst case scenario is that I lose the contents of the text in that document. It's a bad situation, but the damage is limited and contained. If I accidentally cut-and-paste a file or directory, the damage could be immense. Years worth of important documents, records, photos, etc... could be gone, because the user's finger slipped and pressed CTRL+X, rather than CTRL+C. Whether or not the operating system should be protecting users in this manner is fully debatable and a matter of opinion, but Apple's approach here is definitely safer (at the cost of being a bit more annoying)
pseudalopex 6y ago
macOS came first. Other file managers don't really cut and paste. They have a weird modified cut that doesn't exist anywhere else.