also sprach David Champion <d...@bikeshed.us> [2016-01-30 11:31 +1300]: > I'm guessing you use kz on one machine and real mutt on the other. Not > showing what features are added beyond stock mutt is, I'm afraid, a kz > issue.
Your analysis is spot-on.
It's a shame to hear that Karel doesn't do his work within the
community. mutt-kz is a nice piece of work and why not provide an
officially experimental mutt?
> Otherwise... you could strings the binary I guess? Or run mutt against a
> -F config file containing sidebar config options, and see if it errors
> out to test for feature presence?
Using -F would be nice, except I can't figure out a way to make this
check-only and non-interactive. I tried
mutt -F .mutt/sidebar </dev/null
but that exits '1' (also) due to "No recipients were specified." The
strings method works. Thanks.
I still wonder if this isn't something mutt could learn. There are
a few approaches to consider:
1. Something like "if_has_var sidebar_width { … }" to allow parts
of the config to be applied conditionally;
2. Something like "sidebar_width = 30 || :" to inform mutt that
failure to set this variable isn't critical;
3. Something like "knownvar sidebar_width" to let mutt know that
this is a valid variable, even if it doesn't know about it.
I quite like the last approach…
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
to err is human - to moo, bovine
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
