I am too scared to use Anki’s add dialog for this reason; I often accidentally tap CapsLock or hit escape key due to muscle memory from vim, and if I do, all my effort editing a card is lost. I have a hacky unenjoyable workflow for adding cards like this:
Open add dialog
Enter something minimal like a title (just so that I can find it later)
Never mind, I managed to make Customize Keyboard Shortcuts do this by remapping "window_browser goto sidebar": "Esc", which is how it should work, in my opinion. Hope this helps somebody.
Please… PLEASE change the ESC key from exiting out without warning so I don’t lose 45 minutes of work and hundreds of flashcards being made all at once… I’m begging you.
Which window are you talking about here, where Escape would do this kind of damage?
Generally I also agree that Esc might not be the best key to close a window. I’ve noticed, that in the Browser, you can also use Ctrl-W for closing the window. Maybe we could use that instead as it’s harder to hit by accident, and it’s also used across other apps with the semantic of “closing”.
When adding cards to a deck, so the Add window I suppose? And since I utilize image occlusion cards, often times 100+ cards occlude parts of a diagram within 1 window. Pressing ESC by accident wipes out all of that effort.
Esc is a standard shortcut to close dialogs - even on macOS things like the Preferences screen of Terminal.app will close when it is pressed.
Anki’s Add screen asks you to confirm if the fields are non-empty, so you don’t lose data accidentally. It sounds like the image occlusion add-on needs to add a similar feature.
I think you could argue the case either way - sometimes users will quickly open the add or edit screens to jot something down, or make a minor edit. When using your persistent editor add-on, not so much.
@hengiesel Since you have already looked into it and know the Anki source better than nearly everyone; I am trying to make the “close window” shortcut configurable (like some others I find it highly annoying to close the window because you press escape once too many). For the browser and add note dialogs themselves it is easy enough, however I can’t figure out from where the QDialog.close() is called when focus is in an AnkiWebView. At first I though that AnkiWebView.onEsc() would be called and that monkey patching would allow overriding the keypress (I also submitted a PR for storing a reference to the QShortcut that maps escape to onEsc) however it doesn’t seem to fire? Is there maybe some other mechanism in the svelte parts?
In the meantime it can be solved by installing an event filter that discards the Escape key press:
works just fine as long as the input focus is not on a WebEngineView (for instance choose deck from the add note dialog but don’t focus the input field).
“Unstoppable escapes” only occur when input focus is inside a WebEngineView. The problem is solved for the moment with the event filter but I am curious either where close() is called from WebEngineView (which doesn’t seem to be onEsc()) or where it is discarded in the other widgets in the browser and add note dialog.