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 780360abf0
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 780360abf0 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 f2cfaa3398.
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.
This applies for withSB and withEasySB, as well as statusBarProp and
statusBarPropTo, making composability better. statusBarPipe is more
awkward to use now, but that's fine
- XMonad.Hooks.DynamicLog.PP: the pretty-printing abstracion, with the
corresponding utilities
- XMonad.Hooks.StatusBar: A new module to provide a better interface to
manage external status bars.
This more general function subsumes (almost) all previously known
combinators in this library (it is still symmetric with regards to
magnification, as this is what most users want). Also export some
previously internal (but not crucial to the implementation) types to
make this possible.
This ports DynamicIcons to the recently introduced ppRename mechanism,
which means DynamicIcons can now safely be combined with clickablePP,
workspaceNamesPP and marshallPP.
This also fixes DynamicIcons not working properly with urgent workspaces
due to forgotten ppUrgent counterpart in data Icon. Also,
ppVisibleNoWindows wouldn't work properly.
The code is now considerably simpler, but we lost the ability to use
different icons depending on whether the workspace is
visible/hidden/urgent/etc. If anyone needs that, it can be worked around
by using some markup that is later interpreted in
ppVisible/ppHidden/ppUrgent/etc.
Related: https://github.com/xmonad/xmonad-contrib/pull/481
Move all the workspaces and icon generation logic into getWorkspaceIcons
and drop the Maybe which is no longer necessary since we made the
formatting logic configurable.
Related: https://github.com/xmonad/xmonad-contrib/pull/450
