Re: automatic decode mime in repl
[2022-02-13 13:09] David Levine > Thank you for submitting your patch, Philipp. I have these > reservations with it: > > 2. For existing users, it may require changes to their existing nmh >environments. As I explained, for most cases this is not true, even if this is enabled by default. For users with the convertargs workaround this don't affect them because they use mhl.replywithoutbody. For other workarounds this will akt like a mail with no Content-Transfer-Encodin. So I don't see a risk of breaking good workarounds. Some may break, but then I would suspect the workaround will also break in some cases without my patch. If you still have conserns, the switch can also be disabled by default. I still belive there is no requirement for a switch at all, but I don't realy care. > 3. It does not add new functionality to nmh. Its functionality is a >proper subset of a pre-existing feature. > > 4. Given 3, if implemented within nmh, an alternative could be to >internally simply wrap a suitable use of the pre-existing feature. >From the user point of view, the result would be the same. I think you miss the point of my patch[0]. The functionality is there it has just no easy way to use it. My patch adds the easy way to use it. Think the idea forward this could allow to remove the convertargs switch of repl and the convert interface of mhbuild. Because all convertargs can do, can also be done by mhshow. As you said it so beautiful: From the user point of view, the result would be the same. > I have additional though lesser concerns, such as the name of the > switch The name of the switch is not importend to me, it was just the first think that come in my mind. So feel free to suggest a better name. > and the support effort required, In order to reduce the overall support effort required you could drop convertargs and the convert interface. This would reduce the overall code size, make the codeflow better to understand and help users and developers to better understand how repl works. And before you acuse me of want to break user setup, I realy don't care if you want to keep convertargs. This is only how I see what would be the best way to reduce support effort. Philipp [0] Aktuall I belive you full understand this and the implication
Problem with mhl.format
I am not sure where I messed up, but suddenly nmh seems to be ignoring the mhl.format file, specifically the "ignores" line. This is a basic mhl.format file with no editing or alterations on my part. If anyone could offer suggestions I would appreciate it. Thanks
Re: mhfixmsg character set conversion
Steven writes: > >we could decode ASCII because 1) we've seen it in the wild, 2) it seems as > >harmless as it is pointless to encode ASCII as ASCII, assuming no NULs, > >and 3) it's a proper subset of UTF-8 so it doesn't interfere with the > >semantics of the "-decodeheaderfieldbodies utf8" switch. > > That also makes sense. Ok, I'll add support for it to mhfixmsg -decodeheaderfieldbodies utf8. > >This line is too long, I'm not sure if that is related or if it's a > >separate issue: > > It's probably related. I can't prove that, but in general, shorter subject > lines appear to be passed through without encoding. > > Regardless, this kind of thing is exactly what I'm trying to eliminate in > my saved messages. I just realized that my decode_headers program doesn't > detect the second encoded string in the same header, but I'm about to go > fix that. :-) When I look at the message in the lists.nongnu.org archive [1], the line isn't too long. But it's not folded, either. The continuation is on separate line with no leading whitespace. So I would expect some message parsers, including nmh's, to not detect it. David [1] https://lists.nongnu.org/archive/html/nmh-workers/2022-02/msg00122.html
Re: mhfixmsg character set conversion
>>[ regarding decoding of encoded ASCII in headers] > >Ok, I'll add support for it to mhfixmsg -decodeheaderfieldbodies utf8. Thank you! >When I look at the message in the lists.nongnu.org archive [1], the >line isn't too long. But it's not folded, either. The continuation >is on separate line with no leading whitespace. Something got lost in translation. In the original message (as saved by procmail before being munged in any way), it was one long line, with exactly one space between the end of the first encoded portion and the beginning of the second one. The relevant excerpt (with parts elided to keep the whole short enough here for purposes of illustration) is Subject: =?US-ASCII?Q?Using_[...]_to_mak?= =?US-ASCII?Q?e_text_[...]?= - Steven -- ___ Steven Winikoff | Montreal, QC, Canada | "/Earth is 98%% full. Please delete anyone s...@smwonline.ca | you can." http://smwonline.ca | | - fortune(6)
