This contains a breaking change for readHistory, writeHistory,
historyCompletion, and historyCompletionP to take an XPConfig, so they
are aware of this choice. While the latter two are exported, it seems
unlikely to affect many users.
It might be that the keypress does not have a valid stroke associated to
it, but is still bound to an action (e.g., xK_Left an friends). In this
case, we still want to execute it.
Closes: https://github.com/xmonad/xmonad-contrib/issues/845
+ Add a new prevCompletionKey to XPConfig, in order to cycle backwards.
Bound to S-<Tab> by default.
+ Already handle null keystrings (times when only a modifier was
pressed) in handleMain, such that completions aren't cleared
prematurely.
+ Augment nextComplIndex (now computeComplIndex) with the ability to go
in an arbitrary 1-dimensional direction. As a result, that function,
as well as handleCompletion and handleCompletionMain now take an
additional Direction1D argument.
Based on: https://github.com/solomon-b/xmonad-contrib/tree/feature/scrolling-prompt-completions
Fixes: https://github.com/xmonad/xmonad-contrib/issues/831
Co-authored-by: Solomon Bothwell <ssbothwell@gmail.com>
This changes KeyPress handling in these modules to behave much closer to
how xmonad core itself handles keypresses. The primary difference lies
in that xmonad reads raw KeyCode and then converts it to unmodified
KeySym, while these modules used `lookupString` to find the actual
keysyms. As a consequence, key definitions like `(shiftMap, xK_Tab)`
didn't work on many layouts because an actual KeySym for `Shift-Tab` is
commonly `ISO_LEFT_TAB`, and not `Tab`.
Closes: https://github.com/xmonad/xmonad-contrib/pull/590
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
This replaces the custom `cleanMask` extension in these modules—which
only filtered out XKB group bits and Button5Mask¹—with the new
`cleanKeyMask` which additionally filters out all mouse buttons, as
these aren't relevant for key bindings.
¹) Filtering out Button5Mask was probably an off-by-one mistake.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
At the moment, we re-calculate the prompt width every time we want
to (re)draw the prompt window. This is unnecessary, as the screen
dimensions or the preferred position changing _while the prompt is
active_ is extremely unlikely.
This now calculates the desired width at the start of the prompts event
loop and threads it through to the places that need it.
While it is true that we need an IORef complWin in case of an exception,
so the window can be destroyed correctly, we do not need its non-IORef
counterpart at all.
When we need to access the complWin it's undoubtably when we want to do
_something_ with regards to window management; these things naturally
live in `XP ()` and so there's not loss of purity with this change.
This is a convenience module in order to have less import noise. It
re-exports the following:
a) Commonly used modules in full (Data.Foldable, Data.Applicative, and
so on); though only those that play nicely with each other, so that
XMonad.Prelude can be imported unqualified without any problems.
This prevents things like `Prelude.(.)` and `Control.Category.(.)`
fighting with each other.
b) Helper functions that don't necessarily fit in any other module;
e.g., the often used abbreviation `fi = fromIntegral`.
When `alwaysHighlight` is enabled and one immediately presses (by
default) Return after opening the prompt (because the highlighted
completion is what one wants) then the selection will not enter the
prompt history. Instead, an empty string will be entered because there
hasn't been any input yet and hence the `highlightedCompl` field has not
yet been filled in.
The fix is simply checking whether `alwaysHighlight` is set during
startup and, if yes, already setting the highlighted completion to the
first suggestion.
This builds upon the idea of 780360abf078d47908c446941bc0c0bae6b8664d
but it fixes the issue in a bit of a nicer way; instead of throwing an
exception and closing the prompt, we simply check if there is only a
single completion available inside `hlComplete` directly.
While what 780360abf078d47908c446941bc0c0bae6b8664d said is true insofar
that we have incomplete information when inside `hlComplete`, this does
not actually matter in this case. We have access to the complete user
input (possibly consisting of things not from this round of completion),
which is enough here.
Fixes a bug introduced in f2cfaa33980061f4fb39b689403701d36babe33f.
The changes there allowed the prompt to cycle through its input; it now
becomes necessary to single out the case of only having a single
suggestion that's also highlighted. Otherwise, `hlComplete` (condition:
`alwaysHighlight` is enabled) will loop forever. This case can't be
handled from within hlComplete, as we are giving it incomplete
information to start with (by only calling it with the last word of the
current completion in `handleCompletion`), which is necessary for things
like completing arguments.
The silent error `user error (createFontSet)` would break certain
modules (like the prompt) by simply not showing anything.
Pango 1.44 dropped support for FreeType in favor of HarfBuzz, losing
support for traditional BDF/PCF bitmap fonts. Hence, some distributions
don't ship `xorg-fonts-misc` anymore.
Fixes https://github.com/xmonad/xmonad-contrib/issues/348
526336ecec98aa2fe1cc98521473372b0664e19d introduced a bug where
tab-completion has an issue when a completion contains spaces; it only
deletes the last word of that completion, causing the next TAB to again
select the current selection and add it to the command. In this way,
the prompt can get "stuck" on an item, endlessly adding all but the
first word to the command every time TAB is pressed.
C.f. xmonad/xmonad-contrib/issues/455
Just because there are some completions doesn't mean that the given
index may not still be too big.
Incidentally, this now allows every prompt to cycle through its items in
a nice way.
If this is not done, trying to select another window with the mouse when
the prompt is up, the X server executes a pointer/keyboard grab until
`allowEvents' is called; which it never is and so both remain frozen
indefinitely.
C.f.:
- xmonad/xmonad/issues/116
- xmonad/xmonad-contrib/issues/445
