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.
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
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.
This implements whitespace pruning at the end of a sheduled item or
deadline. If we have a message like
This is a message +s today
it is expected that we created a heading of just "This is a message",
without the extra whitespace.
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`.
A new prompt that works like 'safePrompt', but is optimized for the
use-case of a program that needs a file as an argument.
This is necessarily a new function and can't just be achieved by using
the old `safePrompt`, as `getShellCompl'` does not at all filter the
files (compgen already does that based on the input), but only the
available commands. If we start the prompt with a single command then
the chosen `searchPredicate` becomes quite useless and we can't take
advantage of fuzzy matching for file finding. This, however, is quite
useful when having a program that explicitly expects a file as one of
its arguments, e.g. dragon [1].
What we have to do instead of to generate all available files with
compgen and _then_ filter this down to what we want via a given
function. In order to make this change backwards compatible we have to
introduce the rather ugly `shellComplImpl`, which takes a laundry list
of all of the different parameters that we need. Since the function is
not exported, this ugliness does perhaps not matter too much.
[1]: https://github.com/mwh/dragon
Starting with 5240116f3c we only support
GHC versions 8.4.4 and up (more precisely, the GHC version associated
with stackage lts-12 and up). The imports in question are now in
Prelude and need not be imported explicitly.
Parameterizing completion case-sensitivity for single-mode prompts was
possible without making any breaking changes. For multi-mode prompts,
however, the completion function is expressed through the XPrompt
'completionFunction' method. The only argument that method receives is a
Dir value, so parameterizing completion case-sensitivity means adding a
new field to the Dir constructor.
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.
Prompts based on `mkComplFunList` and `mkComplFunList'` were not
taking into account the `searchPredicate` funtion from `XPConfig`.
This was rather confusing.
We fix it by passing `XPConfig` to these functions; although
this is strictly more than they need, it makes the breaking change very
easy to fix and is also more future-proof.
