Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format

[Ken Hornstein]

>  | 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