Ken wrote: > I was more thinking about preserving MH's historic flexibility. I guess > my point was I'd prefer something like this (all are aliases to 'repl') > > calaccept: -typearg text/calendar accept > calreject: -typearg text/calendar reject > > Rather than: > > calaccept: -calendar accept > calreject: -calendar reject > > Does that make sense? I don't really like the name 'typearg', I was just > trying to make the point that I'd like the options to repl be able to be > used for any MIME type.
I like the idea. And agree that we need a better name. This doesn't necessarily have to be tied to MIME types. For example, I might want to pass some particular kind of plain text notification through a special filter for reply. We'd need to have a convention on how to determine how many arguments there are. Fix at two, the type indicator and one more argument? Other possiblities (a count at the beginning, a termination indicator, or constraining the order of switches and non-switches) are messy. And it could suggest the form of the pseudoheader, e.g., Nmh-text/calendar: accept; filename Any back-end nmh program could use what it needs from that. filename is the full path to the message/file. It does what $mhaltmsg now does, but avoids passing data through environment variables and doesn't rely on whatnow to set it. Or to really simplify things, we could grab filename from the context, assuming that's always set before it's needed. David _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
