Open liskin opened 5 months ago
Anyone happens to have an opinion about the API?
This sounds much better than the current situation, but I guess breaking user configs by dropping an argument is always a bit "eh" :/
New API and mark the old one as deprecated? Or just go with "empty list means get it from the event"? Also, do we want to think about this for https://hackage.haskell.org/package/xmonad-contrib-0.18.0/docs/XMonad-Actions-CycleWindows.html#v:cycleRecentWindows?
Also, do we want to think about this for https://hackage.haskell.org/package/xmonad-contrib-0.18.0/docs/XMonad-Actions-CycleWindows.html#v:cycleRecentWindows?
X.A.Repeatable is used in X.A.CycleWindows, and also in X.A.{CycleWorkspaceByScreen,CycleRecentWS,MostRecentlyUsed} so changing the API would result in quite a lot of breaking changes, or at least quite a lot of new function names and lot of deprecations.
I guess going with the "empty list …" option is better then. Or something.
Description
This makes all the cycleSomething key bindings easier to use: users don't need to manually list the KeySyms of modifier keys in addition to specifying the mask for the keybinding itself. We can easily get those KeySyms from the KeyEvent currently being handled with the help of XGetModifierMapping.
This only implements the logic in
X.A.Repeatable
. We need to decide whether to change the API of all the user-facing functions (drop themods
argument), just document that empty list means "auto-detect", or some combination thereof.Checklist
[X] I've read CONTRIBUTING.md
[X] I've considered how to best test these changes (property, unit, manually, ...) and concluded:
seems to work fine for me…
automated testing not feasible
[ ] I updated the
CHANGES.md
file