In some shells—like bash—the entire help message is shown in a single
line because a newline is printed as a literal "\n" character when using
echo. Some distributions[1] have /bin/sh linked to bash, and so new
users are likely to run into this at some point.
We could fix this by either removing show and explicitly adding an
escaped quotation symbol before and after the string, or by using printf
instead of echo. The printf solution seems more portable[2] and so I
propose we go with that one.
[1]: f5b9a25cdd/nixos/modules/config/shells-environment.nix (L129-L143)
[2]: https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/#65819
pandoc's API changes often enough that distros like Debian were patching
our GenerateManpage.hs to work with their version of pandoc, and it
doesn't build against any Stackage LTS except the recently released
LTS-17. Also, building pandoc from source takes quite some time and
resources.
But for what benefit? We're not using any special pandoc functionality
whatsoever. It's just that it was all in Haskell and the entire build
was orchestrated by cabal, but is all that complexity and resource
consumption worth it? I think not.
(Frankly, this whole thing was just a massive waste of time as the help
text in Config.hs isn't generated at all, so we still need to do this
manually. And then, the default key-bindings in core are unlikely to
change ever again.)
Let's simplify this:
* drop all dependencies except base and just run it through runhaskell
* add a Makefile and GH Actions workflow that invokes this after push
* only ship the results in release tarball, not the scripts which are
considered our dev infrastructure
Closes: https://github.com/xmonad/xmonad/issues/283
Related: https://github.com/xmonad/xmonad/pull/260
Related: https://github.com/xmonad/xmonad/pull/261
Related: https://github.com/xmonad/xmonad/pull/265
Related: https://github.com/xmonad/xmonad/pull/266
Related: https://github.com/xmonad/xmonad/pull/267
Related: https://github.com/xmonad/xmonad/pull/268
We can take advantage of modern Pandoc features to move information like the
release date, the man page section, etc. into the markdown source rather than
having to insert that data during the rendering process. The only thing that
remains to be figured out by this tool is the set of known key bindings.
* All references to darcs have been updated to git
* Most Google Code references have been changed to GitHub
* References to specific issues at code.google.com have been left
alone
* Updated the GenerateManpage.hs to work with the latest version of
pandoc
The intention of adding these files to the data-files
is so that they get included in the upload to hackage:
people might like manpage but not have to install pandoc.
It's not really clear that this is the best solution.
