>Clearly, you need to be more opinionated.  :-)  nmh is already happy to
>inc malformatted, see what I did there, emails, e.g. sortm later
>complains about unparsable dates, and I think that should continue.

So, as long as we're talking about things ... here's my feelings:

- inc should continue to be able to incorporate any sort of random crap
  without failing, like it does now.

- The other utilities should try to "continue" as much as they can, while
  providing reasonable feedback to the user.

>I'd expect and like repl to complain and not present me with a draft to
>edit.  I can then investigate based on the error message.  This suggests
>the failed attempt to parse the To header should ripple back up; longjmp
>FTW.  ;-)
>
>Whether a template that didn't refer to To would spot the problem
>depends on if the existing code parses all interesting headers up front
>or only upon reference.  I wouldn't expect this to change, just be
>documented.

Doing that would require some more smarts to the format engine; that's
possible, we've slowly been making it smarter.  Might have to figure
out how much smarter it needs to be.  But how will that interact with
higher-level front-ends to nmh?

>It's a rare enough occurence that investigation should result, not some
>stab at automated DWIM fixing.  It Outlook starts doing this every
>weekday then we'd have more evidence upon which to do the right thing.

I am wondering what other MUAs do when presented with these messages, though.

--Ken

_______________________________________________
Nmh-workers mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Reply via email to