So far, we have used the `D` tuple, as defined in X.Operations, for
these. However, `D` uses `Word32` for its components, which are not
supposed to carry negative values.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/578
Utilise EZConfig's Emacs style syntax for entering the prefix key.
The syntax has been well-established for use in configuration files;
especially in this case it can be a bit awkward having to specify a
function that takes a config just for a single keybinding.
X.D.Extending claims to index all of the contrib library, but this was
not really the case. While most modules where indeed indexed, some
notable ones were missing from this list. Since we're pointing users to
this quite prominently, this is something that needs to be fixed.
* X.A.Search: Update/Remove outdated URLs, add GitHub
- The `codesearch`, `openstreetmap`, and `thesaurus` searches were
using old URLs; update those.
- Remove the now defunct isoHunt serach.
- Add a search for GitHub.
* X.A.Search: Change http to https
- The `codesearch`, `openstreetmap`, and `thesaurus` searches were
using old URLs; update those.
- Remove the now defunct isoHunt serach.
- Add a search for GitHub.
This adds the function `killOthers`, which kills all unfocused windows
on the current workspace.
As discussed in the PR itself [1], the module suffix `WithAll` is not
quite optimal at this point, as we are acting on window _groups_ and not
necessarily just all window on a workspace. However, in order to keep
this commit atomic, this consideration is postponed until another day.
[1]: https://github.com/xmonad/xmonad-contrib/pull/602
Currently when creating an XMonad Prompt one is stuck with "XMonad:" as
the title for the prompt. However, sometimes it is nice to be able to
create a prompt with custom commands that has a particular title.
This changes the internals of X.P.XMonad to facilitate this and adds
xmonadPromptCT as a user facing function.
Users are having trouble with this module all the time. Now that
certain helper functions are undeprecated, we should tell users how they
may use them. It is also worth explaining the scary-looking
`spacingRaw` command a bit further.
Related: https://github.com/xmonad/xmonad-contrib/pull/597
These should be undeprecated for several reasons:
- The suggestion to use spacingRaw is pretty ridiculous; the interface
to spacingRaw is very general and flexible, which is great, but I
think that most people probably do not need all of that flexibility,
and one of these convenience functions may suit their needs better.
- There is precendent for having convenience functions like
these (like X.L.Magnifier)
These were deprecated in a rewrite to make X.L.Spacing support a
non-uniform border length, but from a usability perspective wrappers
should always be preferred to such a general interface with rather shaky
documentation.
Related: https://github.com/xmonad/xmonad-contrib/pull/243 (2c53d507ee)
This works like logTitles, but gets an explicit screen to log the window
titles on. This may be useful when having status bars for each screen
that show all windows on their respective visible workspaces.
It is already possible to "start" from $HOME by specifying a relative
directory (one starting without a starting slash). However, it is often
nice to be explicit about this by writing `~/' directly—support this.
So far, while parsing strings like "<ptn><more-letters>", the `getLast`
function immediately stopped on strings of the form "<ptn><whitespace>".
This may be a bit confusing given the functions name. Strings of
the—perhaps artificial—form
"a +d f 1 +d f 2"
would be cut short and parsed as
Deadline "a" (Time { date = Next Friday, tod = Just 01:00 })
instead of the more intuitive
Deadline "a +d f 1" (Time { date = Next Friday, tod = Just 02:00 }).
This is readily fixed by applying the `go` parser as often as possible,
only returning the longest list, and then pruning eventual leftovers at
the end of the string. Since we were already invoking `dropWhileEnd` to
trim whitespace before, the added `reverse`s should not impact
performance at all.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/584
With "nix build", just the build of xmonad-contrib itself takes 3
minutes (it builds twice, the second build with profiling enabled), so
it ends up being almost 6 minutes in total, making this workflow the
slowest one.
Some people like their mouse pointer to move when changing focus with
the keyboard, other people like their pointer to stay and focus to
follow. xmonad(-contrib) supports both preferences, but imperfectly:
The former requires using the XMonad.Actions.UpdatePointer contrib
module, the latter (focusFollowsMouse) only reacts to CrossingEvent; the
focus isn't updated after changing workspaces or layouts.
This adds an inverse of XMonad.Actions.UpdatePointer.updatePointer that
immediately updates the focus instead.
Fixes: https://github.com/xmonad/xmonad/issues/108
When `runProcessWithInput` is invoked immediately after
`ungrabPointer`/`ungrabKeyboard`, we don't actually ungrab at all
because `runProcessWithInput` blocks and the ungrab requests wait in
Xlib's queue for a requests that needs a queue flush.
Common uses of `unGrab` (before `spawn`) aren't followed by a blocking
action, so the ungrab requests are flushed by xmonad's main loop, and
this is merely a timing issue—fork/exec takes a while and xmonad
probably manages to get back to its main loop in time. Uses of
`runProcessWithInput` in ordinary non-submap key bindings happen to work
because key bindings are passive grabs—the grab is released by the
user's fingers releasing the key itself, even if xmonad's ungrab
requests are stuck in a blocked queue. Submap key bindings, however,
take an active grab and therefore need to ungrab explicitly.
Easy fix—explicit `sync`.
Fixes: https://github.com/xmonad/xmonad/issues/313
