utf8-string isn't needed since d9e3ebf531
(late 2014).
Most of the executable xmonad deps are unnecessary since
307b82a53d (early 2015).
Switch from data-default to data-default-class to avoid bringing in deps
and instances we don't need.
In some shells—like bash—the entire help message is shown in a single
line because a newline is printed as a literal "\n" character when using
echo. Some distributions[1] have /bin/sh linked to bash, and so new
users are likely to run into this at some point.
We could fix this by either removing show and explicitly adding an
escaped quotation symbol before and after the string, or by using printf
instead of echo. The printf solution seems more portable[2] and so I
propose we go with that one.
[1]: f5b9a25cdd/nixos/modules/config/shells-environment.nix (L129-L143)
[2]: https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/#65819
Users who are installing stack on systems like Debian stable or Ubuntu
may get really old version of stack—much older than we currently
support. Thankfully, stack can upgrade itself rather easily with one
single command, so mention that.
Fixes: https://github.com/xmonad/xmonad/issues/303
The `choose` combinator is very general; much more so than the
combination of `switch`, `swap`, and `passOnM`.
We can thus replace most of the implementation with calls to `choose`
and properly put everything related to `JumpToLayout` under one guard.
Plus, we don't need to define any extra functions that would have to be
tested in some way.
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
The functionality of the former are quite handy to have in core and we
can do so with minimal code changes.
The drawbacks of this approach are
1. We can't merge JumpToLayout into ChangeLayout because people may
have imported JumpToLayout(..), which we can't simulate with type
aliases, patterns, and the like.
2. Because the internal structure of X.L.LayoutCombintors.(|||) is a
bit different, this creates a regression for people who used
NextLayoutNoWrap or Wrap in their configs. We could work around
this by creating fake instances of these fields in the new
JumpToLayout constructor and simply not doing anything with them,
but since this seems like quite an advanced and specific use-case,
failing fast and hard (as opposed to adding deprecation messages
and then "silently" not handling these messages) seems preferrable
here.
Related: https://github.com/xmonad/xmonad-contrib/pull/493
Related: https://github.com/xmonad/xmonad-contrib/issues/116
Xrandrint.h says:
/*
* if a configure notify on the root is recieved, or
* an XRRScreenChangeNotify is recieved,
* XRRUpdateConfiguration should be called to update the X library's
* view of the screen configuration; it will also invalidate the cache
* provided by XRRScreenConfig and XRRConfig, and force a round trip
* when next used. Returns invalid status if not an event type
* the library routine understand.
*/
If any user code needs that info/cache to be correct, we need to call
this.
In sendRestart, switch to the new setClientMessageEvent' and pass no
data, as no data are expected. Passing currentTime was confusing, as
it's only interpreted as time in some ClientMessage types.
In killWindow, it's the other way around.
The reference to the freenode matrix channel is deleted for now; though
it may be added back in later-on, as the matrix team is working towards
bridging Libera. We may also link the other matrix channel at some
point.
Related: https://github.com/xmonad/xmonad-web/pull/21
Ever since 322e06eed9c4b23a465d2857df462b8a2d716246 `ppTitleUnfocused`
does not exist anymore, as it was moved to `X.U.Loggers.logTitles`.
This makes the tutorial aware of that.
Since freenode has decided to kick us off because we said that we're
moving to Libera:
Topic for #xmonad is "This channel has moved to ##xmonad. The topic is in violation of freenode policy: https://freenode.net/policies"
Topic set by freenodecom (~com@freenode/staff) on Wed, 26 May 2021 04:59:51
it is high time we change the official channel on the website—even
though we don't even have OP on Libera yet.
Related: https://github.com/xmonad/xmonad-web/pull/26/
Co-authored-by: slotThe <soliditsallgood@mailbox.org>
GitHub Actions writes caches on the first miss and then never updates
them again. If the CI is used frequently, the caches never expire and
as they get old, become less useful.
To avoid this, force refreshing the caches once a month.
Related: 52751f47d0
When building with an LTS version that has exactly the dependencies we
need (X11-1.9.2), stack doesn't need to download the Hackage index. If
GitHub Actions cache locking chooses this job as the one that writes the
cache, then the "stack-pantry-Linux" cache entry stays empty, possibly
forever.
Force Hackage index update to prevent this from happening.
Related: d1a4820b55
"dirs" is used several times in xmonad-contrib as a short for
"directions" and when I tried renaming those uses, I had a really hard
time coming up with something nice/meaningful. Therefore I think it's
best if we rename this instead, "dirs" is a valuable part of the
namespace. :-)
Fixes: 735fb58f6c ("Revise XDG handling")
grabKeys doesn't check that a KeySym is valid before looking up the
KeyCode(s) it's bound to. In particular, KeySym 0 (NoSymbol) gets mapped to every
unbound KeyCode, since that's what XKeycodeToKeysym returns for those.
This can most easily be reproduced using `statusBar` in xmonad-contrib,
with def as the key-mapping function; this unexpectedly invokes the
following instances:
instance Default b => a -> b where def = const def
instance (Default a, Default b) => (a, b) where def = (def, def)
instance Default CInt where def = 0
thus producing a function which binds `toggleStruts` to the (KeyMask,
KeySym) pair (0, 0) (and demonstrating why Default is a dangerous
abstraction). The person who reported this used xmodmap to clear KeySyms
from their numpad keys, and then xmonad would bind strut toggling to the
entire numpad.
Note that it is not reliably possible to override `def` in this
situation (without introducing a new type); the only thing we can do is
try to avoid the aftermath, and I would expect that an inadvertent 0
KeySym is the most common error here anyway.
Fixes: https://github.com/xmonad/xmonad/issues/293
Fixes: 40cb12ce17 ("Grab all keycodes linked to each keysym, not just one")
Co-authored-by: Brandon S Allbery KF8NH <allbery.b@gmail.com>
These past months I've spent a lot of time working on xmonad¹ and I feel
like I've done a lot. This is, however, not sustainable long term. :-(
¹) primarily xmonad-contrib and the community in general
I'd like to try making my GitHub Sponsors profile a bit more visible,
hoping that would allow me to continue dedicating time to xmonad.
I know that the correct approach probably is for the xmonad project to
find a fiscal sponsor like the Software Freedom Conservancy or Open
Collective or something and accept donations as a project, and then
redistribute that to people, but I don't think the project has enough
momentum to do something as complicated as that. :-/
Related: https://github.com/xmonad/xmonad-contrib/pull/544
It's often difficult to make contrib modules work together. When one
depends on a functionality of another, it is often necessary to expose
lots of low-level functions and hooks and have the user combine these
into a complex configuration that works. This is error-prone, and
arguably a bad UX in general.
This commit presents a simple solution to that problem inspired by
"extensible state": extensible config. It allows contrib modules to
store custom configuration values inside XConfig. This lets them create
custom hooks, ensure they hook into xmonad core only once, and possibly
other use cases I haven't thought of yet.
For more, see the related pull request to xmonad-contrib.
Related: https://github.com/xmonad/xmonad-contrib/pull/547
Since actions/virtual-environments#3268, the GHC PPA is no longer
enabled by default. :-(
(It would be better to use the haskell/actions/setup action, but it
insists on doing `cabal update` even if all we need is to install GHC
and Stack, which adds noticeable delay:
https://github.com/haskell/actions/issues/29)
pandoc's API changes often enough that distros like Debian were patching
our GenerateManpage.hs to work with their version of pandoc, and it
doesn't build against any Stackage LTS except the recently released
LTS-17. Also, building pandoc from source takes quite some time and
resources.
But for what benefit? We're not using any special pandoc functionality
whatsoever. It's just that it was all in Haskell and the entire build
was orchestrated by cabal, but is all that complexity and resource
consumption worth it? I think not.
(Frankly, this whole thing was just a massive waste of time as the help
text in Config.hs isn't generated at all, so we still need to do this
manually. And then, the default key-bindings in core are unlikely to
change ever again.)
Let's simplify this:
* drop all dependencies except base and just run it through runhaskell
* add a Makefile and GH Actions workflow that invokes this after push
* only ship the results in release tarball, not the scripts which are
considered our dev infrastructure
Closes: https://github.com/xmonad/xmonad/issues/283
Related: https://github.com/xmonad/xmonad/pull/260
Related: https://github.com/xmonad/xmonad/pull/261
Related: https://github.com/xmonad/xmonad/pull/265
Related: https://github.com/xmonad/xmonad/pull/266
Related: https://github.com/xmonad/xmonad/pull/267
Related: https://github.com/xmonad/xmonad/pull/268
Make it clearer that we in fact do not require implementations for a
minimal complete definition, but that the default implementations have a
certain kind of dependency structure.
