These (and the `*MD` functions apart from `literalMD`) are now no-ops
in nixpkgs and serve no purpose other than to add additional noise and
potentially mislead people into thinking unmarked DocBook documentation
will still be accepted.
Note that if backporting changes including documentation to 23.05,
the `mdDoc` calls will need to be re-added.
To reproduce this commit, run:
$ NIX_PATH=nixpkgs=flake:nixpkgs/e7e69199f0372364a6106a1e735f68604f4c5a25 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run -- github:emilazy/nix-doc-munge/98dadf1f77351c2ba5dcb709a2a171d655f15099 \
--strip {} +
$ ./format
This process was automated by [my fork of `nix-doc-munge`]. All
conversions were automatically checked to produce the same DocBook
result when converted back, modulo minor typographical/formatting
differences on the acceptable-to-desirable spectrum.
To reproduce this commit, run:
$ NIX_PATH=nixpkgs=flake:nixpkgs/e7e69199f0372364a6106a1e735f68604f4c5a25 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run -- github:emilazy/nix-doc-munge/98dadf1f77351c2ba5dcb709a2a171d655f15099 \
{} +
$ ./format
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge/tree/home-manager
The NixOS variant of Markdown doesn't make a distinction between
`<code>` and `<literal>` or `<quote>` and... quotes, and doesn't
support `<parameter>` or `<replaceable>`. These are infrequently used
(apart from `<code>`) and don't add much, so just convert them to
simpler forms to allow the options containing them to be converted
to Markdown automatically.
A few minor syntactic adjustments were also made to make
`nix-doc-munge`'s job easier.
The Markdown options processor cannot handle rendering tables
to DocBook. This could be fixed, but as we won't be using the
DocBook output for long I just removed them for now in the interest
of expediency; they were all well-suited to being description lists
showing option types anyway, apart from one awkward case in the form
of trayer, which also had ad-hoc syntax for enumerating acceptable
values in the documentation. Since the types aren't actually used for
option processing anyway, I changed them to use `enum` and similar to
give a single description of the acceptable values without a big table.
`nix-doc-munge` can't handle these, which is understandable as I can
barely handle them either. There are a few infelicities here: the
current processor can't handle multiple terms to one description in
a description list so they get comma-separated in one case, and one
case that should ideally render as a `<figure>` with a `<figcaption>`
in HTML is reduced to a paragraph with some `<strong>` text. (Which, in
fairness, is how it rendered in practice with the DocBook anyway.) The
docs generator has since been updated to handle figures, but we can't
use it until moving off DocBook output.
These files all have options that trip up the `nix-doc-munge`
conversion tool for one reason or another (syntax that clashes with
Markdown, options that were already using Markdown syntax despite not
being marked that way, output that differs slightly after conversion,
syntax too elaborate to convert with some cheap regular expressions,
...). Translate them manually and do a little copyediting to options
in the vicinity while we're at it.
Previously, lines in .zshrc were added with quotes in keys
(e.g. ZSH_HIGHLIGHT_STYLES['comment']='fg=#6c6c6c'). However, zsh
considered these quotes to be part of the key, so the "comment" key
remained unchanged.
* aerc: fix per-account extraConfig section names
The aerc configuration file `aerc.conf` can contain 10 different
sections, but only the UI section supports what the aerc manual calls
contextual configuration. This works by appending to the section heading
either `:account=name` or `:folder=bar`.
The aerc-accounts module, however, applied `mkAccountConfig` to each
section heading declared in
`config.accounts.email.accounts.<name>.aerc.extraConfig.*`. This means
home-manager will generate files with `[general:account=default]` and
the options will not be recognized by aerc.
To address this, and since it doesn't make sense for other sections to
only be under a single account's scope, an assertion has been added
to confirm that only sectons that support contextual config (i.e.,
only the UI section) is declared.
This also addresses confusions like declaring
`accounts.email.accounts.*.aerc.extraConfig.general.unsafe-accounts-conf
= true` and triggering a warning message because
`programs.aerc.extraConfig.general.unsafe-accounts-conf` was unset.
This commit also updated documentation throughout the aerc modules to
be in line with this change, and fixed minor typos/formatting therein.
Co-authored-by: Genevieve <genevieve@sunlashed.garden>
* aerc: make assertion plaintext and add test case
This commit adds a test case to check both the warning on unset
`unsafe-accounts-conf = true` when aerc accounts are configured
with Nix, and the new assertion when per-account configuration
contains unsupported subsections (i.e. general).
It also fixes minor formatting issues and typos.
Nushell has the option to source from the login.nu file in the case
that nushell is used as a login shell. This commit adds the login file
alongside the existing config and env files as another configuration
option.
Previously, IMAP was preferred over notmuch, even if notmuch was
configured, causing problems with setting account flavor (which
automatically sets IMAP settings). The new backend order is:
notmuch > IMAP > maildir
This also fixes the notmuch DB path being set to the wrong location.
The notmuch DB is located at the maildir base path, not in each
account's maildir.
The current `lla` alias, together with the `total-size` option try to get
the size of the `..` directory, and for this has to recursively open all
sibling folders. This may be super slow if some of those siblings
contain too many files, and raise a ton of useless errors if some of
those siblings contains non-readable files.
I'm suggesting to use `-A` instead, which will skip the obvious `.` and
`..` folders.
While here, I think we could also add `llt`.
Many of the terminals supported inside emacs work perfectly fine with STARSHIP.
The TERM=dumb case already handles the tramp and eterm cases, so as far as I can
tell, this is basically just a check for the benefit of OLD versions of
term-mode (see
emacswiki.org/emacs/AnsiTerm#:~:text=Historically%2C%20'M%2Dx%20ansi%2Dterm,the%20older%20'C%2Dc'%20binding.,
which indicates that it also now handles colors).
PR #3747 renamed the option wayland.windowManager.sway.systemdIntegration
to wayland.windowManager.sway.systemd.enable.
This commit simply updates documentation to reference the new format.
Starship has an advanced, experimental feature where fancy stuff in the
prompt can be replaced with something more simple after the command is
ran. This is very helpful for copy and pasting shell history somewhere
else.
docs: https://starship.rs/advanced-config/#transientprompt-and-transientrightprompt-in-fish
Fish is currently the only shell as far as I can tell that both
home-manager and starship support for this feature. Since the function
has to be called after starship is loaded, this seems like the best
place to put it.
format
* aerc: add space after definitions
* aerc: only generate files, if options were set
* aerc: improve file permission warning
* aerc: remove redundant access to builtins
* aerc: allow overwriting of derived values
the order of merging the config subsets did not allow the user to specify
outgoing, source and password command values,
if they were previously derived from the SMTP, IMAP, Maildir etc config.
The values from `account.<name>.extraAccounts` now have the highest precedence.
Appropriate tests were added as well.
* aerc: write primary account first
* Add infrastructure for contacts and calendars
This also adds the modules
- programs.vdirsyncer,
- programs.khal, and
- services.vdirsyncer
that integrate with the new infrastructure.
Co-authored-by: Andrew Scott <3648487+ayyjayess@users.noreply.github.com>
Co-authored-by: Sebastian Zivota <sebastian.zivota@mailbox.org>
wip
* vdirsyncer: allow option userName, disallow userNameCommand
1. account option `userName` is now allowed by `programs.vdirsyncer`
2. The commented out account option `userNameCommand` was required to be set
by `programs.vdirsyncer` (e.g. as `null`).
It is now disallowed (commented out) by vdirsyncer.
* khal: added options 'color' and 'priority'
* Apply nixfmt
---------
Co-authored-by: Sebastian Zivota <sebastian.zivota@mailbox.org>
Co-authored-by: Johannes Rosenberger <johannes.rosenberger@jorsn.eu>
Co-authored-by: Johannes Rosenberger <johannes@jorsn.eu>
Co-authored-by: Robert Helgesson <robert@rycee.net>
