deprecate XMonad.Util.Ungrab
#843
Conversation
| @@ -31,7 +31,6 @@ module XMonad.Config.Mate ( | |||
| import XMonad | |||
| import XMonad.Config.Desktop | |||
| import XMonad.Util.Run (safeSpawn) | |||
| import XMonad.Util.Ungrab | |||
There was a problem hiding this comment.
This will result in a build failure related to this. I'm not sure it's worth bumping our bounds over, so we should probably be a bit more tame here as well
There was a problem hiding this comment.
What I found is that if I don't remove this line, the compiler will complain about an ambiguous reference in the new version. Because unGrab will be defined both in XMonad.Operations (which is imported into this file from import XMonad) and XMonad.Util.Ungrab.
But thinking about it again. I could probably just do import XMonad hiding (unGrab). Would that be preferrable?
There was a problem hiding this comment.
Yes, I was thinking about hiding the function from the XMonad import and perhaps adding a {-# OPTIONS_GHC -Wno-dodgy-imports #-} at the top of the file, to pacify the compiler when this is compiled against xmonad HEAD
There was a problem hiding this comment.
I'd be in favor of bumping xmonad and having #if MIN_VERSION_xmonad(0, 17, 9) in X.U.Ungrab so that users following the stable releases don't get the Ambiguous occurrence ‘unGrab’ error when compiling their configs, and just get a deprecaton warning.
There was a problem hiding this comment.
(Note that for that to work, we can't have unGrab = Operations.unGrab but must reexport the import.)
There was a problem hiding this comment.
I'd be in favor of bumping xmonad and having
#if MIN_VERSION_xmonad(0, 17, 9)in X.U.Ungrab so that users following the stable releases don't get theAmbiguous occurrence ‘unGrab’error when compiling their configs, and just get a deprecaton warning.
Right now users compiling against xmonad-0.17.2 should not get an error (as evidenced by the CI), since we're hiding (the possible non-existent) unGrab from the XMonad import. Still, bumping might not be such a bad idea
There was a problem hiding this comment.
I wasn't talking about compiling xmonad-contrib itself, but about compiling the xmonad.hs config. Anyone who imports both XMonad and XMonad.Util.Ungrab and uses unGrab will start getting errors. I mean, yeah, it is mentioned in "Breaking Changes", but I don't think it should actually be a Breaking Change when we can turn it into just a deprecation warning.
There was a problem hiding this comment.
(liskin/xmonad@5c6c3d4 & liskin@8526d93 are one way to solve this, if we want an ifdef)
There was a problem hiding this comment.
Oh, right, that might indeed be an issue. The ifdef sounds fine in that case; thanks for spotting this!
There was a problem hiding this comment.
Okay, I pushed the two commits then.
|
Thanks! |
Description
Deprecate
XMonad.Util.Ungrabas it is going to be moved toXMonad.Operationsin xmonad/xmonad#479Checklist
I've read CONTRIBUTING.md
I've considered how to best test these changes (property, unit,
manually, ...) and concluded: Tested manually with a config that uses unGrab and removed the XMonad.Util.Ungrab import.
I updated the
CHANGES.mdfile