Essentially a duplicate of the revived #3278

That wasn't what I was talking about.  I was talking about the extra 
space to the left of these lines for these kind of threads.  But this 
was due to the thread link code and has been fixed by your revert.



BTW, I agree with Jan about the threads - after all I was the one who 
created that display in the first place :)  To this day, nobody else 
has provided a way to represent this kind of thread - with multiple 
bottom-level messages - any better.

You both convinced me, I reverted it.
No, I have always seen this too. But as I already said, I got used to 
it and for me it now makes sense, because you still easily spot 
threads even if there isn't a single common parent message. You can't 
identify threads with messages on the same level otherwise.

I would prefer this didn't go into 4.2 either - if just because I have 
plans to totally redo how we handle threading in future (5.0).  So 
having a feature that may only be in a single point release before 
disappearing again may not be the best.



As far as chuck's issue - I have *never* seen that issue before.  All 
of my threads with multiple top-level messages always appear 
completely left justified.  Is this something that has recently 
appeared with jan's changes?

If you look at the screenshot here, what I was talking about is the 
thread about Text_reST - both messages have the same indent level as 
the reply to the Turba address book thread.
Because threads with the link-to-thread image have a different indent 
level than either of the above possibilities. Also, you can see that 
the Text_reST thread has no link image, so that's a new inconsistency.
It is relatively unobtrusive, but it does catch the eye a little - 
also I would have no idea what it meant if I didn't know the code or 
use the mouseover, but icons are hard like that in general.



I think it's a half measure, but not bad enough to completely veto it. 
You did ask what others thought, so, my thoughts are on the table. :)

I had to get used to that too, but now I find it rather intuitive and 
actually more consistent  than the old behavior. Did I get something 
wrong?
Why does it introduce a variation? It's the same for any thread and 
this little icon is the least intrusive solution I could come up with 
without rewriting the whole mailbox rendering which is out of the 
question at this moment. But of course I'm open for better UI ideas.
Yeah, that would be the ultimate goal, but is this intermediate 
solution really that bad? I'm not attached to exactly this 
implementation, but I really want this feature, and I want to get it 
in before the RC1.

I'm pretty unhappy with this. I was already bugged by the 
inconsistency of indenting threaded messages (when there are multiple 
top-level messages in a thread, they both have the same indenting as a 
reply in another thread); this introduces another variation. And I 
still really think that if we're going to do something like this we 
should take the cue from Gmail and show only one message in the list, 
with a link to the full thread.



I know there are technical challenges to doing that, but I think 
that's the way to go here.

I committed some initial version to CVS, what do folks think?

My initial thoughts were to have an icon over by the message status 
(attachment, high prioirity, etc) that would be clickable to open the 
whole thread, but that doesn't seem to really fit in with the purpose 
of those icons.  Maybe an icon just before the subject field and 
before the dotted line that ties the threaded messages together?   
Perhaps that would only show up when viewing the mailbox in threaded 
view so it wouldn't be too obnoxious for people not viewing it as such.

I want this too. The only issue that kept me from implementing this so 
far is, that I have no idea how to do it UI-wise.

If you are viewing a mailbox in thread view, I would like opening a 
message to open the entire thread, not just the single message.  That 
would save me another click to choose the thread view at that point.



I can see that not everyone would want this, so I would suggest this 
be turned on optionally in the configuration.