Aquamail doesn't display a portion of the Subject

[StR]

Under certain circumstances, Aquamail removes a portion of the Subject.

I suspect that this is actually a "feature, not a bug", but I thought I'd mention it here.
When I am in the message view,  with the headers "minimized" (i.e. multiple recipients are collapsed, Aquamail strips away the portions of the Subject such as [SPAM].
In the case, instead of
[SPAM] Some text here,
It shows as:
Some text here.

While I can guess what was the motivation in implementing this feature, it is confusing, as it removes the information about the message. I didn't test, - but I suspect it might be removing some similarly-looking e-mail list inserted portion, such as in
"Subject: [mail-list-name] Something interesting".

I'd rather have the tail of the Subject to be obscured then the head of it disappearing.
Otherwise, I have to either unfold the recipients' list (and then fold it back), or to get out, to the message list, to check for the information contained in the square brackets (in this case if it was already recognized by SpamAssassing as SPAM, or not yet).

[StR]

>> I didn't test, - but I suspect it might be removing some similarly-looking e-mail list inserted portion, such as in
"Subject: [mail-list-name] Something interesting".

I can confirm: brackets and words between them are removed, in shrinked title of message view.

"one [two] three four five six seven eight nine ten eleven twelve" appears:
"one three four five six seven eight nine ten eleven twelve"

Thank you, Paris Geek!

I expected that, and that's why I thought it was happening "by design", rather than by accident.
What's interesting from your test, is that those don't have to be in the beginning, but can be in the middle of the subject.
I guess it was written that way to work around subjects like
"Re: [mail-list] real subject", which would show as
"Re: real subject"

Kostya:
While I might guess (and in a way understand) the rational behind this behavior, it is not something that I'd expect from a mail program, as it removes the information that is important to me. The square brackets aren't always originated by a mail-list server, but are sometimes used in other ways: "[SPAM]" is just on example. (In my case, if it marked like that, I know that the spam-filters detected it, and if it is not marked, I save it into the spam, so that the SpamAssassin can learn from that message.)
And besides this, there are other uses for the square brackets. Sometimes I put some information in square brackets to distinguish it from the rest of the Subject.

To summarize, since there is no standard on their use in the subjects, it is not convenient that the mail program chooses to not display a portion of the subject in the message view, with the header portion collapsed.

[Kostya Vasilyev]

The rationale, use case, is primarily for mailing lists -- e.g. "[android-developers]" is kind of long, or some "[ubuntu-discussion]" or what not -- to show the more meaningful parts of the subject.

This is only done in "short" message header view -- if you need to see the subject intact, just tap the message header area and it'll switch.

---

"mail program chooses"

A mail program already makes all sorts of choices, like parsing malformed messages, filling in missing charset headers, trying to connect using both IPv4 and IPv6 to make up for operating system bugs, etc. etc. etc.

This is just another one of those things.

[StR]

Kostya,

I am not sure why this topic was so touchy for you, but I am sorry that I "pushed a wrong button",  provoking such a reaction.
I do recognize that Aquamail does a lot of things behind the scene that aren't according to any RFC or other standard. And I perfectly understand it is doing this due to your choice. And I think that the success of Aquamail is in large part attributed to the smart choices you've made about this app's functionality.

My comment was also based on a use case: messages that contain text in square brackets that is not a designation of a mailing list.

It is great that a message has an easy way of switching between a short header view and a long one. I typically keep it in a short header view mode, as otherwise some long lists of recipient takes over large portion of the screen. Yes, it is possible to switch to the long view to look for the entire header, and that's what I've been doing (not the most ergonomic way, but it's acceptable, - that's why I had not mentioned this earlier).
The problem occurs when there is text that is hidden by Aquamail (especially when you get to the message directly from the notifications panel) and you don't know there might be some text there; so you don't know you need to look for it. You don't check message headers just in case they contain some information that was cleansed away by the mail program.
I've head a situation like that where the information was missed for that reason, and I didn't even suspect it was there.
You may say that those cases are rare. I agree, - but it is because they are rare, one wouldn't routinely check for the full version of the subject.

So, I'd suggest that maybe an option (yes, I know you already have a gazillion of options) to do that or not to do that would be helpful. Even if very few users would choose it, it would make people aware that this could happen.

[Kostya Vasilyev]

I'm just trying to understand -- what's wrong with tapping the message header to show all the data, if you know that you rely on such markers?

The message list view, btw, will shorten long markers, but won't remove them completely.

Maybe this is the middle ground -- do the same for short message view header mode? Can you take a look at message list view?

This is what it look like (attached). The actual marker is "[android-developers]".

(ignore the green line, that's debug code)

[Kostya Vasilyev]

Code: [Select]

$ hg help graft
hg graft [OPTION]... [-r] REV...

copy changes from other branches onto the current branch

    This command uses Mercurial's merge logic to copy individual changes from
    other branches without merging branches in the history graph. This is
    sometimes known as 'backporting' or 'cherry-picking'. By default, graft
    will copy user, date, and description from the source changesets.

    Changesets that are ancestors of the current revision, that have already
    been grafted, or that are merges will be skipped.


[mikeone]

That was before dev6.2
The new build enhanced the display, and was uploaded while I was posting the screenshots...

This is real time improvement

Kostya:
I'm impressed.
Thank you very much for this lightning-fast adjustment.

[StR]

Kostya,

If I understood the ultimate changes correctly (i.e. the way you had it implemented in the list view), - that's great, makes good sense!
Great! Thank you!

BTW, while looking at my messages on the phone today, I thought of one possible improvement:
In the "long" header view of the message, you have two lines allocated for the sender, - to the right of the square (that can be filled in with the photo if one exists in contacts, I guess).
If the sender information is taking only one line, then the second line is empty. Do you think that using it by the line "To: me" would be too confusing?
(In my case, - I am not using photos in contacts, and I switched off Gmail-like letters, so, it's an empty generic square on the left anyway, which by itself is taking up the space, but I understood, that many people use that feature. As for me, I'd eliminate that photo placeholder completely [and even more so, if the photos is empty].)
In any case, - this is not a big deal, - after all, it's only one line...