Re: [Nmh-workers] nmh architecture discussion: format engine character set
- For _display_, try to convert all of the characters to the native character set (yes, using the locale, dammit!). OK. Is that using POSIX, or does it require something extra? POSIX includes iconv(), which is adequate. If the Unicode library we need to use has a charset conversion API that is better, we should use that (my beef with iconv() is that you cannot give a substitution character, which requires some awkward handling for dealing with substitution characters). - Reconvert such messages to 'canonical' standard while sending. Well, I think just for addresses; leaving everything else as an encoded word might not be harmful. But I'd have to think about it. The only thing I can think of is if something somewhere suggests a preferred format when multiple are valid, like an ASCII subject should be just the subject. Kind of like how it's annoying Android base64s bodies IIRC. AFAIK, this shouldn't be a concern; we already have a fair amount of code that produces the 'minimal' encoding (e.g., we don't use base64 or q-p unless it's a requirement). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh architecture discussion: format engine character set
On Wed, Aug 12, 2015 at 8:55 PM, Ken Hornstein wrote: - Handle everything internally as UTF-8. - For _display_, try to convert all of the characters to the native character set (yes, using the locale, dammit!). - For things like _replies_, if we are not in an UTF-8 locale then downgrade things like the addresses using RFC 6587 rules (well, the subject as well ... I think the way it would work is the format engine would do the encoding for you behind the scenes for all components). - Reconvert such messages to 'canonical' standard while sending. Well, I think just for addresses; leaving everything else as an encoded word might not be harmful. But I'd have to think about it. - But this also makes it clear that the thoughts of having an 'external' decoder stage will simply not work; you need to know too much about each header, because they're all handled differently. Sorry for late reply... The above looks reasonable to me. The 'external' encoder/decoder is more of a pie-in-the-sky idea of allowing the encoder system being abstracted so one could plug in different engines if needed. Basically, using pipes into and out of it whenever an encoding/decoding operation is required. However, if the level of effort to achieve such an abstraction is not worth any potential benefit, do not bother with it. Note, there may be some benefit in providing some level of abstraction for the encoder if there is a concern of nmh getting locked-in code-wise to a specific library. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Add a -sendmail switch to post(8) and send(1)
Hello to the entire nmh community! Sometimes I find handy to specify a custom sendmail program without affecting the default one or editing mts.conf. While there are $MHMTSCONF and $MHMTSUSERCONF sometimes I would like to select a sendmail program during whatnow(1) session just via: send -sendmail ~/bin/foobarbaz-sendmail I will attach trivial patches that will add this feature. If you find them useful can you please review them? If they can be imported please let me know and I will also take care to update the man pages! Looks great! Please send patches that include man page updates and I'll make sure it gets in there. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
