>> top of the message. However, if you're only interested in To:, From:,
>> CC:, and Subject:, it only shows those, but it shows those fully (and
>> wrapped at screen width.
SL> Great, so we could have a slew of information which, most times, we don't
SL> want or need before we get to the actual body of the message. Well, if
SL> nothing else, it identifies the poorly formed spam faster.
You don't look at any of the headers in any form before reading a
message? Oh, I could see that you just look in the message list to
get some of the info.
Am I correct in assuming that you don't ever care what the full To:
field is, if it's long? I like being able to choose what headers I
see, but TB! only allows me to see them up to a certain length. This
isn't that great, 'cause to get the full header that I'm interested
in, I need to look at ALL of the headers. Why can't there be that
in-between?
>> Agent also solved the attachment issue that we seem to have. Why not
>> just display the attachments inline with icons representing where they
>> are?
SL> Because they aren't the body.
So what? Multipart messages arbitrarily don't have any "body" per se.
I mean, isn't it just as arbitrary to decode the first part as text
and not offer it as an attachment?
I wouldn't vote for a mail reader to display only the attachments and
not make a good guess at what the text content is, but the way
multipart messages are formed, it is not that strange to think of them
as text followed by "other stuff." After all, it is all laid out that
way in plaintext anyway. Anything from "From" to "From" is a message.
Who says what parts are the body or not is just speaking about
preference anyway, but I would imagine that the commonly accepted
definition is "the stuff that's not the headers."
SL> Having the PGP information in the body is bad enough, it really
SL> shouldn't be there.
It'd be nice to see PGP-Headers as opposed to the current way it's
done.
SL> Also in the MIME context there really isn't any positional
SL> information from most clients.
That they don't show it doesn't mean it doesn't exist. Last I knew,
"attachments" in MIME came one after another rather than in parallel.
SL> Mutt can do it. In fact, how you describe is how mutt does things,
SL> but it is a CLI application and some consessions need to be made.
Ok, say you're using a MUA that doesn't support MIME. What does it
show?
Why, all of the sudden does "understanding MIME" mean we shouldn't
show the user something that actually does closely resemble what the
file looks like?
In any event, MIME certainly does *NOT* mandate that "attachments" be
shown as icons on the right of the message, nor on the bottom or along
with the headers. That's an implementation detail, and quite frankly,
*I* would prefer if attachment showed inline simply because of the
fact that I choose not to open them nor do I care that they exist >90%
of the time.
SL> The fact that there is no way to get to the attachment right away. The
SL> information just isn't there.
That's true, since TB!'s message pane is a pita to manipulate. First
have to make sure that the focus is in the right window, then have to
scroll it down, then have to click. Again, I don't care 'cause I
don't open attachments in the general case. However, the left margin
thing ALWAYS irritates me when it pops up.
-tom!
--
Bah, ridiculous thing.
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : [email protected]
