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
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
This implements window swallowing on top of SubLayouts; the matched
windows are simply tabbed together instead of one actually being
swallowed. This provides an improved experience for people using
SubLayouts, as the parent window is still accessible.
Done as part of ZuriHac 2021.
Related: https://github.com/xmonad/xmonad-contrib/issues/416#issuecomment-777400194
Before https://github.com/xmonad/xmonad/commit/383ffb7 this would
bind all unbound keys to toggle struts; after it, it would bind no
keys at all. With this commit, it will check for this case and use
the default keybinding instead.
Users who intend no key to be bound should probably use `withSB`
instead, especially in light of aforementioned commit.
Due to differences between random-1.1 and random-1.2, on newer systems
stringToRatio returns numbers outside [0, 1] range, which breaks
colorRangeFromClassName colorizers.
This commit fixes the issue by using randomR to directly generate the random number.
Also this fixes the compilation warning (genRange and next are deprecated in random-1.2).
This adds a new logHook, nsHideOnFocusLoss, that hides the given
scratchpads when they lose focus. This is akin to the functionality
provided by a lot of dropdown terminals.
This exports the `withRecentsIn` function, as it's quite useful when
using X.H.RefocusLast in other modules as a library.
It is already possible (RecentsMap is fully exported) to completely
define this function outside of the module, so we are not exposing any
more internals than we were before.
By deprecating everything except `WSIs` and adding constructors to
logically combine `WSType` values, we can have a more flexible interface.
Adding anything to the old interface would mean going through `WSIs`, and
all old constructors can be implemented of terms of `WSIs`.
When we applied hlint hints in bd5b969d9b,
the definition of desktopLayoutModifiers got (via the hint to eta
reduce) changed from
desktopLayoutModifiers layout = avoidStruts layout
to
desktopLayoutModifiers = avoidStruts
While the former is general enough to infer the type signature
LayoutClass l a => l a -> ModifiedLayout AvoidStruts l a
the latter just sees the usage site of
, layoutHook = desktopLayoutModifiers $ layoutHook def
in the desktopConfig function and thus—through the magic of
MonomorphismRestriction—infers the specialized type
Choose Tall (Choose (Mirror Tall) Full) Window
-> ModifiedLayout AvoidStruts
(Choose Tall (Choose (Mirror Tall) Full)) Window
This obviously completely falls apart once someone wants to change the
layout and still uses desktopLayoutModifiers (unaware that it is just
avoidStruts at the moment). The easy fix is to give things type
signatures, so nothing needs to be inferred.
The _actual_ solution would be, in my opinion, to completely deprecate
X.C.Desktop and remove it in a future release, as well as to completely
rewrite the provided Example.hs. This needs more deliberation though.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/560
Related: bd5b969d9b
This is for disambiguation purposes. Otherwise, there is no way to
decide whether
message +s 17 jul 12
wants to schedule the note for the 17th of july at 12:00, or for
the 17th of july in the year 12. The easiest way around this is to
stipulate that people want to make these notes for the future more
often than not and to simply prohibit note before the year 25 (as that
is where the valid times end).
Instead of trying to find a prefix and then killing the rest of the
word, actually see whether it at least fits the pattern. This means
that
message +s saturated
will no longer parse as a scheduled item for saturday, while
message +s satur
still will.
If we have a URL in the clipboard and we use `orgPromptPrimary`, it
would be nice if
message +s 11 jan 2013
would result in
* TODO [[_URL_][message]]
SCHEDULED: <2013-01-11 Fri>
instead of the current
* TODO message
SCHEDULED: <2013-01-11 Fri>
_URL_
This has the advantage that if one shows scheduled or deadlines items in
the org-agenda, it is possible to immediately follow this link with
`C-c C-o` or similar functionality.
The URL detection is very rudimentary right now. One use `parseURI`
from `network-uri`, but that would be an additional dependency that I
didn't think was worth it.
