[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: decode in mail
From: |
Alain Magloire |
Subject: |
Re: decode in mail |
Date: |
Fri, 27 Jul 2001 10:05:08 -0400 (EDT) |
Bonjour
> > ... msglist is expand
> > will have to be change to return a structure:
> >
> > struct {
> > int msgno;
> > int partno;
> > }
> >
> > Comments?
>
> Yes, it sounds good.
>
> But if the same function (util_expand_msglist) will be used to expand
> lists inside the brackets, care should be taken not to allow more than
> 2 levels of recursion, otherwise a user might issue weird commands like:
>
> print 1[2[3[4]]]
Actually, this is possible(althought unlikely and weird):
MIME allows you to encapsulate a message within a message. I think
the Content-Type is "message/rfc822". So the first message contains
a second rfc822 message which contains a third rfc822 message which
is 4 parts mime message.
>
> Besides, a question of operator precedence arises. If one types:
>
> print 1-3[2]
>
> should it be equivalent to
>
> print 1,2,3[2]
>
> or
>
> print 1[2],2[2],3[2] ?
>
> I would advocate for the latter.
I would vote for the former, it would make life easier.
print 1,2,3[2]
'[]' should be given precedence over the '-'.
To have the effect of the latter, I could see this
print (1-3)[2]
But introducing the '()' operator would probably be overkill 8-).
In the long run, it would be nice to have different expansion schemes,
for example, the wellknown MH (1..3), elm set of utilities selection list,
Berkeley /bin/mail msglist expansion, IMAP4 expansion. Putting
this into a module in mailbox/ makes sense.
> By the way, if `print 1[2]' prints the part 2, `save 1[2] FILE'
> saves it to FILE, then it effectively duplicates the functionality
> of proposed `decode' command. We can then make `print 1[2]' behave
> the way we discussed for `decode', i.e. do some lookup in
> mailcap/mime.types, run appropriate viewer program, etc...
> In this case `decode' is superfluous.
Good rationale. Yes, the [Pp]rint and the [Tt]ype command is meant
for (screen)display, it is probably useless to display pages of
base64 encoding.
>
> Or is it supposed that usual commands print raw contents of the
> message part, whereas `decode' outputs decoded contents?
I think that was Jakob original plan. But I can leave with [Pp]rint
acting smarter when paging messages.
--
alain