David Levine <[email protected]> writes:
>Norm wrote:
>
>> mh-format constitutes a real barrier to "All power to the user", for
>> all but the most sophisticated of users.
>
>As long as everything works out of the box, I don't think that's
>a problem. At least not a problem that should be addressed by
>adding more options and code. I agree with Ken that providing
>more examples is the way to go.
>
>> The option would be -exec procedure_name, or if you like, -eval
>> procedure_name. If present, then procedure_name would be invoked for
>> each message. procedure_name's stdout would completely replace each
>> scan line.
>
>Why not pipe the output of scan/inc through a program that calls
>procedure_name? For mhshow, replace mhlproc and/or moreproc?
>
>> For each component, comp, of a message, it would define an
>> environment variable, NMH_FORMAT_comp, whose value was the content
>> of that component.
>
>That's a messy interface. Should NMH_FORMAT_Received, for
>example, contain some kind of flattened string array? And
>environment variables are case sensitive, so should that be
>NMH_FORMAT_Received, NMH_FORMAT_received, NMH_FORMAT_RECEIVED,
>or something else? I think this just trades one form of
>messiness for another.
I give up.
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
