That's discoverable by holding down Option while the Edit menu is open. This pattern of "revealing" additional functions with modifiers in menus has existed on macOS for a very long time.
> Speaking of pressing [enter] on files, that should open them, not rename them.
> For that matter, pressing [delete] should delete files. You just have to know that the key for that is [cmd+delete], and that deleting things is called moving them to the trash.
Adding a modifier to these functions helps prevent accidental irritating (opening 500 selected files) or potentially destructive (moving selected files to the trash) actions due to fat fingering, which is a particularly likely occurrence on laptops where edge keys like delete and return are easy to accidentally hit just moving around one's laptop. The accidental opening by hitting return one is something I've done several times over the years and it's never not infuriating.
On Windows, deleting it moves it to the Recycle Bin which is functionally equivalent to what macOS does. In fact off the top of my head I don't know of a modern desktop environment that just directly deletes files without recourse.
> It's not clear to me why I can't close Finder by pressing [cmd+q]. Quitting finder is usually all I want to do when it's open.
Because the Finder powers the desktop too and its windows are not separate processes. In fact no application on macOS spawns additional windows as separate processes, that's a Windows/Linux thing.
Ironically, holding down "Option" to see hidden menu items is not discoverable at all. Most people will only ever do it by accident. The point is that anything commonly desired should not be hidden like that.
There's also the 'Help' menu in Finder that has the manual, tips, and menu search functionality.
That Finder and the desktop are a single process is an implementation detail that should be hidden from UI mechanisms like this.
So, not discoverable at all.
I guess I could also question the proposition that Apple doesn't change things people like about Macs. I could list a few examples of them doing that, too.
Thanks for the suggestion that I read a book.
If you want it different, you want Linux or a BSD.
> Search within finder does not search the current context by default, it searches your entire computer. "But you can change this setting!" You shouldn't have to change this setting, and most people don't know it's even there.
The default behavior used to be great, ~10 years ago (extremely snappy search scoped to the current folder). The change to searching the whole computer with significant lag was an absurd and mysterious regression.
It’s like the difference between US vs. UK spelling conventions. A British person saying “Americans are bad at spelling words” is just trolling.
Apologies, but what do you expect to happen to the file in-between the cut and the paste? Cut content exists only on the pasteboard. If I cut a sentence from a document and then cut another sentence, the first sentence is effectively gone (without an additional clipboard manager).
This is why they went with the select-and-copy and select-and-move operations instead, and mapped them onto the copy/paste system. A true 'cut' would be too destructive.
I'd expect that nothing will happen, Cut will wait for paste operation. It's not delete, where content is gone immediately. If no paste will follow, then Cut is not executed. Cut marks file for move operation, if no move is executed, then nothing will be lost.
> If I cut a sentence from a document and then cut another sentence, the first sentence is effectively gone (without an additional clipboard manager).
We're talking about files here, not text. Text behaves differently. I'd argue that Cut operation as it is in text editors, is not logical but it is what it is and people are used to it. For deleting there's Delete operation, Cut should not be equal to Delete in some occasions.
Well, that's exactly how Finder works, isn't it? Cmd+C marks files, Cmd+V copies them, Cmd+Opt+V moves them.
On Windows, the cut file is dimmed out after you press [cmd+x] to indicate something has happened.
In my mind the only advantage the Windows way has is that it belongs to the more popular platform.
* Moving files is unintuitive. It should be [cmd+x] then [cmd+v]. Instead it's [cmd+c] then [option+cmd+v], and this behavior is not afforded in the UI, you just have to look it up somewhere.
* Search within finder does not search the current context by default, it searches your entire computer. "But you can change this setting!" You shouldn't have to change this setting, and most people don't know it's even there.
* Renaming multiple files is a chore. You expect to rename a file, then press tab to highlight the next file, and begin typing. Instead, you... do some combination of enter, tab, then enter again, except it never quite works the way you expect, and sometimes the file moves because the sorting changes after you pressed enter the first time, and for some reason pressing tab actually moves you to the next folder.
* Speaking of pressing [enter] on files, that should open them, not rename them.
* For that matter, pressing [delete] should delete files. You just have to know that the key for that is [cmd+delete], and that deleting things is called moving them to the trash.
* In general, the number of contextual commands you just have to discover by trial and error, or by looking them up on the internet, because they are hidden in the UI. Even the right-click menu doesn't list things like "open in slideshow", because the right click menu has a secret menu of its own which you have to press [cmd] to see.
* There is no preview panel visible by default, that's another option you have to turn on, like showing the file path. This stuff should all be on by default.
* You have to view file info in a separate window.
* It's not clear to me why I can't close Finder by pressing [cmd+q]. Quitting finder is usually all I want to do when it's open.