+ 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
So far, when `alwaysHighlight' was enabled and the user selected an item
while not having completely written it out in the prompt, the input
string and not the eventual completion string would be entered into the
prompt history, which is obviously not the desired behaviour. This can
cause the history to clutter up with all these abbreviations, making
subsequent invocations of the prompt tedious to work with.
For example, an input of "xm" would narrow to both "xmonad" and
"xmobar", but thanks to `alwaysHighlight' "xmobar" was selected. If the
user now pressed enter, the prompt would correctly return "xmobar" as
the string to act upon, but "xm" would be entered into the prompt
history!
This is needed because the cache directory is now a part of XConf, which
is calculated once on startup and hence any recalculation would be
fragile.
Some internal functions that are not exposed (like writeHistory) were
also changed to accept that directory as an argument.
Fixes#164.
It's not clear to me why these functions take in XPState as a param only
to then produce some XP () values. It seems like they could just as well
call `get`.
Provide a way to perform case-insensitive file / directory completion.
We're using compgen to generate completion candidates, and this is
case-sensitive by default. We can control this by setting the
completion-ignore-case Readline variable prior to invoking compgen. If
we're running a Bash with Readline support, this works as expected.
Otherwise, it has no effect -- completion candidates are still returned,
but compgen generates them in a case-sensitive manner.
To avoid breaking changes, the signatures and behavior of existing
exported functions are unchanged:
- XMonad.Layout.WorkspaceDir.changeDir
- XMonad.Prompt.Directory.directoryPrompt
- XMonad.Prompt.Shell.getShellCompl
New variations of these functions are provided, allowing the caller
to specify the desired case-sensitivity via a ComplCaseSensitivity
argument:
- XMonad.Layout.WorkspaceDir.changeDir'
- XMonad.Prompt.Directory.directoryPrompt'
- XMonad.Prompt.Shell.getShellCompl'
The XMonad.Prompt.Shell exports a couple new functions:
- compgenDirectories
- compgenFiles
We make use of this in XMonad.Prompt.Directory to avoid duplicating the
compgen code.
