Cutting files is a broken abstraction

Part 1: cutting files is a lie[]

I’ve written before in detail on how the clipboard works: when I copy something that program announces to others “I have something for you to paste”, and when you paste on another program, that one says “gimme that copied data”. (this oversimplifies, see linked article if you want the full details)

So what happens when we cut?

In a text editor, cutting just copies something and removes it from the text file immediately. It’s a “copy and delete” action really. The same applies for image editors, and for most other “editors”. A browser’s text field also counts as a “text editor” in this case.

So what happens when we cut a file?

When cutting a file in a file-manager, it will just copy the file, and internally track that it was cut. If you paste into another location using that same file-manager, it’ll move the file instead of pasting. But if you paste into some other program, like an instant messaging client, the file is pasted as a usual copy-paste: the original one remains in place!

Deleting the file when pasting into another application would be risky in this case. What if I press Esc on my instant messenger? Now sending is cancelled but the file is also gone?

Moreover, the deletion typically happens when copying in the source application (e.g.: text is deleted when I copy it, not when I paste it). But for file-manager cut-and-paste, deletion is done when pasting, not when copying.

The truth is, cutting files doesn’t work across applications, and there’s no way to make an abstraction that would be simple to reason about.

Part 2: abstractions that work[]

Last time I used macOS, I noticed that you can’t cut a file: you can only copy. But pasting have two forms: “copy here” and “move here”.

I admit I was pissed at the time and thought it was a stupid divergence from the usual copy-paste semantics — but the design actually makes a lot of sense.

NextStep had a “shelf” metaphor, a really cool one which I’d love to see on Wayland someday (hint: we have all the necessary support for implementing one). A shelf is a small visual area on the side of the screen where you drag files or objects. They aren’t moved anywhere, the shelf just has a reference to them — similar to the clipboard. You can then move items out of the shelf and into another location.

If you want to move a few files from different locations into a common one, you find them one by one, drag them into the shelf, then navigate to the final target, and finally drag them from the shelf into their destination.

Shelves would actually be really cool for touch-based devices with small screens. They need more refinement for keyboard-centric workflows.

1. If menus still showed their key bindings like in the old days, I would have known that ⌘ +⎇+v does a “move-paste”, which would have been very useful.