Ralph pointed out earlier that with the proliferation of RFC 2047-encoded
headers, pick is much less useful.
I'm wondering ... would it make sense to simply have pick run the RFC 2047
decoder on headers before matching them? As far as I can tell we can
decode all headers except for Received:
+1. Anything that works in terms of lines is outdated at this point.
Ken Hornstein k...@pobox.com wrote:
Ralph pointed out earlier that with the proliferation of RFC
2047-encoded
headers, pick is much less useful.
I'm wondering ... would it make sense to simply have pick run the RFC
2047
+1 too.
Anything that works in terms of lines is outdated at this point.
Eek! (Squealing like a mouse in the inside.)
steve
--
On Sat, Nov 24 2012 at 9:40am PST, P Vixie p...@redbarn.org wrote:
+1. Anything that works in terms of lines is outdated at this point.
Ken Hornstein
Ken Hornstein k...@pobox.com writes:
Ralph pointed out earlier that with the proliferation of RFC 2047-encoded
headers, pick is much less useful.
I'm wondering ... would it make sense to simply have pick run the RFC 2047
decoder on headers before matching them? As far as I can tell we can
Ken wrote:
I'm wondering ... would it make sense to simply have pick run the
RFC 2047 decoder on headers before matching them? As far as I can
tell we can decode all headers except for Received: headers.
Thoughts?
Definitely. Though I'm not sure we want to try to decode a
non-MIME header.
On 24 November 2012 at 9:52, Bill Wohler woh...@newt.com wrote:
Ken Hornstein k...@pobox.com writes:
Ralph pointed out earlier that with the proliferation of RFC 2047-encoded
headers, pick is much less useful.
I'm wondering ... would it make sense to simply have pick run the RFC 2047
FWIW, I scripted a multi-folder pick, which I call pickf. If pick
is going to be altered, then being able to specify multiple folders
would be a nice feature addition, at least for me.
I guess I just suggested a boat load of work. Sorry 'bout that.
That's fine ... I look forward to your
Header fields should be RFC 2047-decoded before any MH operation that
considers the content of the message, including pick, shouldn't they?
Is that a rhetorical question? :-)
In a perfect world, yes, that would happen. But RFC 2047 support wasn't
integral to MH; it got grafted on after MH
I tried the quick proof of concept below and it worked, though it
might not be the best way to do things. I had originally wanted
to use fmt_compile()/fmt_scan(), but quickly got over that :-/
Hrm. As I read it this will also try to decode the body of a
message, right? Not sure if that's a
Ken wrote:
Hrm. As I read it this will also try to decode the body of a
message, right? Not sure if that's a good idea. Fixing that might
require some more surgery to pick, though.
pick quits once it reaches the body, except with -search,
so not a problem:
if (body n-n_header)
With -search, it will try to decode and fail, but I don't
think that's worth inhibiting. It would be nice to decode
message parts, some day.
Yeah, but we wouldn't be decoding them with decode_rfc2047(), that's
my point.
Couldn't we just do
+ if (body == 0 decode_rfc2047 (linebuf,
Ken wrote:
Couldn't we just do
+if (body == 0 decode_rfc2047 (linebuf, decoded_linebuf, sizeof
decoded_linebuf)) {
Yup, that'll work.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Ken wrote:
Couldn't we just do
+if (body == 0 decode_rfc2047 (linebuf, decoded_linebuf, sizeof
decoded_linebuf)) {
Yup, that'll work.
Except for the last header. body gets set before breaking
out of the loop.
David
___
Nmh-workers
Ken wrote:
Couldn't we just do
+if (body == 0 decode_rfc2047 (linebuf, decoded_linebuf, sizeof
decoded_linebuf)) {
Yup, that'll work.
Except for the last header. body gets set before breaking
out of the loop.
(body == 0 || lf 0) takes care of that.
David
Except for the last header. body gets set before breaking
out of the loop.
(body == 0 || lf 0) takes care of that.
... I'll take your word on it, because I've squinted at that code for a little
bit now and I still can't figure out what it's doing :-/
--Ken
15 matches
Mail list logo
