[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: decode in mail
From: |
Sergey Poznyakoff |
Subject: |
Re: decode in mail |
Date: |
Fri, 27 Jul 2001 17:38:29 +0300 |
> Actually, this is possible(althought unlikely and weird):
> MIME allows you to encapsulate a message within a message. I think
Oops, yes, I've forgotten. But then `struct { int msgno; int partno; }'
scheme doesn't work. To represent, say `print 1[2[3[4]]]' we need
three levels of indirection, so the structure becomes
struct msg_part {
int msgno;
struct msg_part *msgpart;
};
or even
struct msg_part {
int msgno;
struct msg_part **msgpart;
};
if we take into account the possibility of `print 1[1[2[3]],2[2[3]]]'.
This seems to complicate things beyond any limits :^). From the other
hand, it is unlikely that somebody would issue such comands, but `mail'
should either allow or disallow them. I'd propose to stick with the
`struct { int msgno; int partno; }' scheme and limit expansion to 2
levels.
> I would vote for the former, it would make life easier.
OK.
> But introducing the '()' operator would probably be overkill 8-).
It seems necessary, nevertheless. By the way, returning to the
first topic, it would make it possible to issue such awful constructs
as:
print 1[(1-8)[2[3]],2[(2-5)[3]]]
I've almost lost count of the brackets while typing this :^)
> 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.
Sure. It is a good idea.
> I think that was Jakob original plan. But I can leave with [Pp]rint
> acting smarter when paging messages.
Me too :^)
-Sergey