| and that decoding may require some sort of user interaction,
Doing almost anything with e-mail requires some sort of user interaction,
that's what nmh is all about - the means of interacting. Parsing scan
listings to decide what to do for something automated is entirely the
wrong approach - anything doing that should be looking at the actual
messages, not the extract made by scan.
Sigh. You KNOW what I mean. I mean that if you want to run
"pick -search hello" on encrypted email, you're going to have to decrypt
it, which very well might require you to enter in a PIN to unlock a
smartcard or a password to unlock a GPG key, or something that requires
a UI interaction that is not required today.
And I guess I don't see fundamentally what is wrong with a user deciding
to perform some operation automatically based on the otuput of scan(1);
I thought shell-accessable email tools was the very reason MH exists.
Now if your issue is with the DEFAULT scan output, then fine, I can
understand that concern.
| It's fair to point out that we don't know what a potential %(encrypted)
| function escape should necessarily do just yet; I am just thinking ahead.
Sure, but it is more than what it does, but what it affects. Sticking
in an empty function, and then using it as if it was a "does this field
exist" predicate (though not looking in the header for the info) might
turn out to be counter productive. Better to design the function first
(if we ever need one) and then use it appropriately later.
Fair enough. Both you and Ralph make the point that it would be better
to determine what the function should DO rather than put a placeholder that
does nothing. I'll remove the %{encrypted} entries from the included
scan formats, and I'll remove the vestiges of that support in scansbr.c
because I cannot for the life of me figure out what it is supposed to
do anyway.
ps: in MH land, it would be really nice if we could use the terminology
correctly, and remember that e-mail has exactly one header, which contains
several fields (some mandatory, some optional) and use the correct terms
when referring to each.
Sigh. I hear you, but we haven't always been so wonderful about that
ourselves. MH documentation refers to what RFC 5322 calls "fields" as
"components". And people who cannot quote RFC 5322 from memory often look
askance when you refer to "fields".
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers