Starting with time-1.10, the iso8601DateFormat function was deprecated
in favour of more sophisticated methods for showing ISO 8601 date
formats—as such, follow the libraries lead.
Sadly, the new functionality was only introduced in time-1.9, meaning
GHC 8.8 and up. Since we still support 8.6, the introduction of some
CPP is necessary.
The links were broken due to:
1. Incorrect quotes (' instead of " for module links and occasionally
vice-versa).
2. Changes in the name of the "target" module not reflected in the
"source" docs.
3. Typos to begin with.
4. Use of `<foo>` in the docs is rendered as just `foo` with a link to
`/foo`.
5. Similarly for `"Foo"` if it starts with a capital letter (and hence
could be a module).
6. Markup inside `@` code blocks still being applied.
e.g. `@M-<arrow-keys>@` is rendered as `M-arrow-keys` with a spurious
hyperlink from arrow-keys to `/arrow-keys`, which is confusing.
Three links from XMonad.Util.Run have been removed outright, since
they're no longer examples of the usage of 'runProcessWithInput'.
WmiiActions has been gone since 2008, while XMonad.Prompt.Directory
and XMonad.Layout.WorkspaceDir haven't been using
'runProcessWithInput' since 2020 and 2012, respectively.
In some cases the `<foo>` were surrounded with @, especially in the
case of key definitions, for consistency. (This wasn't done
everywhere, because it looks ugly in the source.)
MoreManageHelpers has never been in xmonad-contrib. ManageHelpers
seems to fill the expected role.
In the case of the module description for X.H.ManageDebug the quotes
were simply removed because none of the likely options to make the
link work were successful.
This is (i) much simpler to use and (ii) helps us with refiling. Emacs
will ignore todo keywords _that it knows_ when refiling, but when
started in batch-mode it doesn't know a whole lot. One would need to
thread the `todoKeywords' through to `refile' and then set
`org-todo-keywords' or a similar variable, which does not sound like a
good experience. Hence, falling back to showing the todo keyword to the
user when deciding upon a headline sounds acceptable.
This ensures that we always immediately expand the file path upon
constructing an `OrgMode' record. We thus do not have to do this in
`mkOrgPrompt' anymore.
Essentially, whenever the tutorial actually has decent material on the
subject matter. The replacement is roughly done as follows:
- logHook → tutorial
- keybindings → tutorial, as this is thoroughly covered
- manageHook → tutorial + X.D.Extending, as the manageHook stuff the
tutorial talks about is a little bit of an afterthought.
- X.D.Extending (on its own) → tutorial + X.D.Extending
- layoutHook → tutorial + X.D.Extending, as the tutorial, while
talking about layouts, doesn't necessarily have a huge focus there.
- mouse bindings → leave this alone, as the tutorial does not at all
talk about them.
By being a bit less greedy with consuming whitespace in the date/time
parsers, we can make the `prop_{encode,decode}Preservation` properties
well-defined again.
Switch the underlying UnicodeData data type from the current ByteString
implementation to String. This is in order to facilitate descriptions
Unicode descriptions of the Unicode characters themselves. We chose
String instead of Text because it does not incur an extra dependency.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/733
Instead of providing these as default values, as originally planned,
just add a note for users who wish to customise that part of the prompt.
We simply get the user config in mkPassPrompt and so overriding that
with a custom searchPredicate and sorter seems unwise.
Closes: https://github.com/xmonad/xmonad-contrib/issues/746
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.
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.
When there is a directory and a file in $PATH of the same name `foo`, we
display `foo`, as well as `foo/` in the prompt, but selecting either one
of them will invariably run or raise the directory, as this test is done
beforehand.
Since directories already carry a trailing forward slash from the shell
prompt's `getShellCompl`, this is easily disambiguated by incorporating
an additional check.
It is duly noted that the same problem also exists for files in the
current directory. This could be fixed in a similar way (adding a
unique suffix to files and checking for that), but since this would
involve changing `getShellCompl` and no-one has complained about this so
far, it was deemed "not worth it" for now.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/616
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.