It looks like h,j,k,l,u were added as review shortcuts in 2.1.63. I’ve since been getting an insane amount of reports from people that their hint shortcuts are not working anymore. H was associated with revealing hints due to the hint hotkeys add-on and I have that set to reveal all hints in all of my anking note types, IO one by one types, and it even toggles the occlusions in image occlusion with the hint hotkeys installed. Beyond this, most users were adjusted to jkl; via many addons, including the custom shortcuts add-on (I can cite multiple sources for this if you need). I would suggest using j,k,l,; for the review shortcuts
(I haven’t researched enough to know what u does?)
In the future, if you’re going to modify default keyboard shortcuts in an add-on, use gui_hooks.state_shortcuts_will_change and make sure there are no duplicate shortcuts (for example, by filtering them through a dictionary).
Yes, I just searched the names. One of the add-ons mentioned is by glutanimate. I think the reason it doesn’t work in the current anki version is because it adds new shortcuts on top of default shortcuts, but forgets to remove/replace the default shortcuts first.
Hint hotkeys you mean? Perhaps @glutanimate will need to look into that. I stopped recommending it and built it into my note types but it’s useful for people making their own note types unless you want to build a shortcut like that into Anki itself
For what it’s worth, I’ve long recommended that the custom shortcuts addon be built into Anki. I think it would make sense to be in the preferences screen
Many anki add-ons seem to follow this pattern: they extend the list that contains the default shortcuts. Defaults always win over custom shortcuts, unless an add-on removes the defaults first.
Instead of forcing all add-ons to update (which won’t happpen, realistically), we can add a small tweak to Anki itself that will filter the shortcuts every time after the state_shortcuts_will_change hook runs.
I created this short pull request. It should fix any affected addons. It should also cancel any worries about the u key, as well as any new keys that might be added in the future versions.
Can you confirm that Hint Hotkeys work now?
The change looks good, but the issue is that Qt treats letter keys case-insensitively, so this won’t work for Hint Hotkeys, which has upper-case H as its default shortcut. I would suggest modifying the filter to something like this (edited):
shortcuts = list(
dict(
(key.lower(), func)
if isinstance(key, str) and len(key) == 1 and key.isalpha()
else (key, func)
for key, func in shortcuts
).items()
)
Edit
Unfortunately this is a bit more involved:
Contrary to the type annotations, shortcuts tuples can also contain Qt Key types in their first field when in the Reviewer state, so this necessitates the runtime type check.
We can’t lower-case keyboard modifiers like Ctrl. Right now, the solution above just retains them as is, but to handle all cases, ideally you’d want an implementation that splits composite shortcuts (e.g. Ctrl+Alt+E) and normalizes them (e.g. Ctrl+Alt+e).
Alternatively, and probably the better approach, you could move the key filtering to applyShortcuts and check key uniqueness via QKeySequence objects, as e.g. QKeySequence("Ctrl+a") == QKeySequence("Ctrl+A")
Configurable review shortcuts are a great addition (thanks @tatsumoto). However, I feel like just dipping our toes into key customizability instead of going the full way by centralizing all shortcut definitions, introducing conflict handling, and making them user-customizable (which could all be iterative steps) might continue producing issues and confusion for users.
E.g. with 2.1.64 users will be able freely assign their review shortcuts to other Anki-reserved single-key shortcuts in the Reviewer, without being able to reassign the latter. Same with add-ons that hard-code their shortcuts. And templates are of course another story altogether as elaborated by @AnKingMed.
All in all, I wonder if we kind of lifted the lid on something here that we didn’t necessarily want to open up just yet.
I agree that a full shortcuts project is needed. It’s been needed for a while, but it’s a project that should be well thought out and try to address the many issues you noted above. It certainly would be a nice addition and it makes sense to include within Anki and not rely on addons for customizing Anki’s base shortcuts
Well, yes I would have preferred we had a better game plan before any shortcut customization was introduced, but the shortcuts introduced in 2.1.63 broke more than originally anticipated, and making them customizable solved the breakages, and answered the people who were asking for alternate shortcuts. They’re probably the most frequently-used shortcuts in the app, which is an another argument for their inclusion. Before we add any more though, I’d like to have a system that can better handle things like conflicting keys.
