When users specify non-existent keys, it seems most intuitive to just
abort the parse and not try to take the "longest" input that still
works. For example, given the "key" `M-10` we should signal a parse
error (by returning `Nothing`) instead of parsing `M-1` and ignoring
the rest of the input. The old EZConfig parser accounted for this but
when the module was rewritten to use X.U.Parser in [1], this was
forgotten about.
Fixes: https://github.com/xmonad/xmonad/issues/361
[1]: 8abeb81fd0
Ever since [1] we allow a second representation for the month (namely,
the numerical one). Since we lose this information during parsing,
pretty printing is now not a proper postinverse of parsing (it still is
a proper preinverse, however).
Thus, we can't simply check for an inverse anymore. However, the
operations still form an inverse semigroup [2], which is something
that's easily checkable. For simplicity, do this in both directions and
completely forget about linearity for now.
[1]: 91f1a0de1e (Fix date parsing issue
for org mode plugin)
[2]: https://en.wikipedia.org/wiki/Inverse_semigroup
There are a lot of times when we could already check for "valid" input
during parsing instead of relaying possibly incorrect dates and times to
`org-mode`. This seems like a sensible thing to do—I don't think anyone
would ever want to schedule anything for 35:90 :)
This patch fixes the date parsing issue currently when an entry like
`todo +d 22 01 2022` is used. I have added tests too which demonstrate
the current issue so that we can prevent future regression.
Hidden windows are now ignored by the layout so that hidden windows in
the stack don't offset position calculations in the layout.
Also in X.H.ManageHelpers: added `isMinimized`
If the user's prompt configuration has a custom `searchPredicate` (e.g.,
`X.P.FuzzyMatch.fuzzyMatch`) the `withWorkspace` prompt should make use
of it (instead of defaulting to an `isPrefixOf`-style matching). For
details see
https://mail.haskell.org/pipermail/xmonad/2021-December/015491.html
Add very basic unit tests for EZConfig to see if it can parse all of the
keys (and key combinations) that it promises to parse.
The long-term goal here should be to write a pretty-printer for EZConfig
and to check whether that's a proper inverse (either in the normal sense
or in the inverse semigroup sense), as the tests for X.P.OrgMode do.
Using X.U.Parser works almost as a drop-in replacement for ReadP here.
In some places (like `parseSpecial`) we need to be a little bit more
careful when constructing the parser, but this is offset a much simpler
`readKeySequence`.
Since we now have an "internal" parser library in xmonad, use it. This
allows us to get rid of some hacks in this module that were needed
because of ReadP's parsing behaviour.
This module provides a parser combinator library based on base's ReadP,
which aims to function more like other popular combinator libraries like
attoparsec and megaparsec.
In particular, the Alternative and Monoid instances are left-biased now,
so combinators like `many` and `optional` from Control.Applicative work
in a more intuitive manner. Further, some functions (like `endBy1`)
only return the "most successful" parse, instead of returning all of
them. We can now get away with providing a single parsing result
instead of ReadP's list of results (as such, parsers need to be
disambiguated earlier instead of trimming the list down after parsing).
This adds basic font-fallback support for X.U.Font, as well as modules
using it, like X.Prompt and X.A.TreeSelect.
In the new system, multiple fonts may be specified with the syntax
"xft:iosevka-11,FontAwesome-9"
Fixes: https://github.com/xmonad/xmonad-contrib/issues/208
Instead of searching for the currently focused window across workspaces,
make it so there is never any window above focus on the Stack that is
given to the modified layout.
Closes#657.
The XS.modify was leaving thunk on the history that the demand analyser
could not prove to be neccesary as they depended on the future user
interaction. This was bad as the time advance there was less and less
neccesity to force such value, so the thunk would be increasing. Since the
datatypes that the `WorkspaceHistory` are really simple, we can just
evaluate and save a good chunk of memory.
updateHistory leaks unfiltered windows from previous states as it is never
forced. The consumer of such data structure is not visible to ghc, so the
demand analysis has to fallback on pure laziness.
We fix this inserting evaluation points on the `historyHook` function. We do
this for two reasons, this is the only function calling `updateHistory`.
Plus we cannot do it clearly at the `updateHistory` function as we operate
inside a continuation on withWindowSet. In respect to the `put`, everything
would be a big thunk.
Update left and right navigation to behave correctly even if the
currently saved position is directly on the edge of the focused window.
This makes the L/R behavior consistent with U/D navigation.
How to reproduce the issue on a 16:9 resolution like 1920x1080:
- configure Grid layout;
- open 4 terminals;
- navigate to the top-right terminal;
- open another terminal;
- immediately close it;
- try navigating left from the currently focused top-right terminal;
- observe navigation being "stuck".
The documentation for this module was lacking, making it significantly
harder to use than the functionality wise very similar
X.A.CycleRecentWS—change that.
