Bug 2939 - make Sort By/Thread Date the default
Summary: make Sort By/Thread Date the default
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Message List (show other bugs)
Version: 3.8.0
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2013-06-08 17:48 CEST by antithesisx
Modified: 2015-09-24 10:00 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description antithesisx 2013-06-08 17:48:15 CEST
The threaded message view is assumed. It seems to me like the sorting options Date and Thread date as accessible from the View menu, have misleading names. When Thread date is chosen, the intuitive behaviour is that the messages are sorted by how old the first message in the thread is - alas, this is what determines the age of the _thread_. When the messages are simply sorted by date, one would assume that threads with new messages get bumped to the top, because the thread is 'fresh' again. However, these two are switched around: Date only looks at the first message's date, and Thread date takes the newest message into account.

I would like to give a suggestion about defaults as well. If only the oldest message in a thread is taken into account, it becomes easy to overlook important mails, because one doesn't usually scroll through the whole list of messages, but rather, people just look at what's on top. That's why I listed this as a major bug. My suggestion is to keep the default sorting option to Date, but give it the appropriate behaviour.
Comment 1 Paul 2013-06-08 21:20:54 CEST
This all works as intended.
Comment 2 antithesisx 2013-06-09 09:58:22 CEST
(In reply to comment #1)
> This all works as intended.

As in the behaviour I described is not the same as how it behaves for you? Or do you not agree that Thread date should only look at the oldest message, and Date should look at the newest message?
Comment 3 Paul 2013-06-09 10:03:31 CEST
The current behaviour, (which is the behaviouir you describe), is how it is intended to work. It's been working this way, (in the case of Date - Thread Date is a more recent addition), for over 10 years.
Comment 4 antithesisx 2013-06-09 10:17:37 CEST
(In reply to comment #3)
> The current behaviour, (which is the behaviouir you describe), is how it is
> intended to work. It's been working this way, (in the case of Date - Thread
> Date is a more recent addition), for over 10 years.

Well, at least make Thread date the default sorting option? Or is it also the intended behaviour, that people overlook important emails because they aren't bumped to the top?
Comment 5 kristoffer.andersson 2014-01-13 08:38:06 CET
I agree with antithesisx@yandex.com that the expected behaviour is that sorting on date moves the thread to the top if a new message is recieved.
Comment 6 Paul 2014-01-13 08:49:26 CET
(In reply to comment #5)
> I agree with antithesisx@yandex.com that the expected behaviour is that
> sorting on date moves the thread to the top if a new message is recieved.

Many, I believe, would see '/View/Sort/By Date' and '/View/Sort/By Thread Date' and expect that from the latter rather than the former.
Comment 7 andré 2014-05-09 09:18:13 CEST
(In reply to comment #3)
> The current behaviour, (which is the behaviouir you describe), is how it is
> intended to work. It's been working this way, (in the case of Date - Thread
> Date is a more recent addition), for over 10 years.

Sorting a thread by the oldest element is a major problem, and if intentional is a major design error.
It doesn't matter if this design error was made over 10 years ago or not.

Many long threads last months, and can last years.
What is the utility of hiding new messages among messages months or more old ?

I've been trying to convert to Claws mail for the mH box storage, but sorry to say, this bug is a show stopper.  I would never be able to find many recent messages, among the hundreds I receive every month on some busy lists.  For these lists, threads are the only way to follow the discussion.

The only logical rationale for keeping the current sort order would be wanting to avoid dealing with longer discussions.

This is clearly not an "enhancement", but a "major" bug.
Comment 8 Albert ARIBAUD 2014-05-09 09:40:56 CEST
Making myself the Devil's advocate here.

How about making both choices available to consider a thread's date to be *either* the first *or* last message, with the default being the current state of affairs so as not to break default behaviour?

This could take the form of two) additional, mutually exclusive, options at the bottom of the view menu (below "Attract by subject"), e.g.:

* /View/Sort/Thread date is oldest message
  /View/Sort/Thread date is newest message

(the dot/asterisk marks the default, install, setting)
Comment 9 Paul 2014-05-09 09:54:25 CEST
(In reply to comment #7)

> Sorting a thread by the oldest element is a major problem, and if
> intentional is a major design error.

When you sort by 'thread date' it is the date of the most recent message in the thread which counts, not the original message of the thread
Comment 10 longlegged.guy 2014-07-01 01:03:40 CEST
Potential new user here, but it seems to me that if you're in not in thread view, the behavior is sensible.

It seems to me that defining a thread date as the date of the newest message in a thread makes sense because when people do a "View->Sort->By thread date" they're going to want threads with recent messages to appear near other threads with recent messages, and generally people want to look at recent messages because those are the ones that usually require replies.

The problem for me is that when I'm in thread view, clicking on the Date column seems to be equivalent to a "View->Sort->By date" which, at least to me, is not a useful sort order for thread view as it does seem to sort by oldest message in a thread.

This is a serious flaw. Of course one can go in and do another "View->Sort->By thread date", but that's a lot of mouse movement just to get back to what I want to be my default view.

If I can configure a couple keystrokes to do a "View->Sort->By thread" I'll probably use Claws anyhow, otherwise I'll have to continue my hunt for a ecent MUA.

Separately my sent messages are appearing in some threads, but not others, but that may have to do with how they were sent and what mailbox they're in and would be a separate bug anyhow even if is Claws is to blame.
Comment 11 Paul 2014-07-01 11:23:27 CEST
(In reply to comment #10)
> This is a serious flaw.

Overstatement!!

> If I can configure a couple keystrokes to do a "View->Sort->By thread" I'll
> probably use Claws anyhow, otherwise I'll have to continue my hunt for a
> ecent MUA.

You can.

Just set whatever keyboard shortcut you like for /view/sort /by thread date (see http://www.claws-mail.org/faq/index.php/Interface#How_can_I_change_the_key-bindings_.28hot-keys.29_in_Claws_Mail.3F)
Comment 12 andré 2014-07-01 20:47:47 CEST
(In reply to comment #11)
> (In reply to comment #10)
> > This is a serious flaw.
> 
> Overstatement!!

It would be REALLY interesting to see the use case for a thread sorted by the oldest date.
It is hard to imagine a sane user of threads wanting anything other than sort by the most recent email in the thread.
Imagine that someone replies to a thread that is a few weeks old, after maybe 50 emails already filtered to the same mailbox.  Never seen, even if it might be urgent to respond to.
It is indeed a major dysfunction.

> 
> > If I can configure a couple keystrokes to do a "View->Sort->By thread" I'll
> > probably use Claws anyhow, otherwise I'll have to continue my hunt for a
> > ecent MUA.
> 
> You can.
> 
> Just set whatever keyboard shortcut you like for /view/sort /by thread date
> (see
> http://www.claws-mail.org/faq/index.php/Interface#How_can_I_change_the_key-
> bindings_.28hot-keys.29_in_Claws_Mail.3F)

Alternately, Claws could be fixed to sort threads by the most recent element.  And avoid the user having to re-sort just because they changed from non-thread to thread view.

Assuming that you want thread users to use Claws, of course ...
Comment 13 Paul 2014-07-01 21:26:52 CEST
(In reply to comment #12)
> It would be REALLY interesting to see the use case for a thread sorted by
> the oldest date.
> It is hard to imagine a sane user of threads wanting anything other than
> sort by the most recent email in the thread.
> Imagine that someone replies to a thread that is a few weeks old, after
> maybe 50 emails already filtered to the same mailbox.  Never seen, even if
> it might be urgent to respond to.
> It is indeed a major dysfunction.

That almost sounds REALLY smart until you realise that by default Claws selects the first new email on entering a folder.
Comment 14 Andreas 2014-07-02 08:16:07 CEST
One problem I have with the default threaded sort order:
On my work email account I like to mark my emails where I still have to do something. Then I use "Sort by Mark", i.e. marked emails are at the bottom (or top when I reverse the sort order).
Now the problem is, that threads get "lost", because the are sorted by the oldest date and not the most recent.
Thus it would be nice if in the threaded view, the default sort order would be by the most recent date, not the other way around.
Even better would be to choose a second sort order.
Comment 15 andré 2014-07-02 16:16:26 CEST
(In reply to comment #13)
> (In reply to comment #12)
> > It would be REALLY interesting to see the use case for a thread sorted by
> > the oldest date.
> > It is hard to imagine a sane user of threads wanting anything other than
> > sort by the most recent email in the thread.
> > Imagine that someone replies to a thread that is a few weeks old, after
> > maybe 50 emails already filtered to the same mailbox.  Never seen, even if
> > it might be urgent to respond to.
> > It is indeed a major dysfunction.
> 
> That almost sounds REALLY smart until you realise that by default Claws
> selects the first new email on entering a folder.

In my tests, I found emails "lost" as I suggested.  Only by total chance did I encounter such emails.  So obviously your "default" can't be relied on.

It still would be interesting to see any use case for sorting threads by the oldest email.  If you can't suggest one, evidently many users would appreciate a revised default thread sort order.
Comment 16 Paul 2014-07-02 16:23:44 CEST
(In reply to comment #15)
> In my tests, I found emails "lost" as I suggested.  Only by total chance did
> I encounter such emails.  So obviously your "default" can't be relied on.

Sorry, but can't accept blame for user error.
Comment 17 Albert ARIBAUD 2014-07-02 16:33:24 CEST
(in reply to comment 14)

I suggested on the mailing list that the "sort by thread date" be removed and replaced with a two-option switch to select whether 'thread date is oldest message date' or "thread date is newest message date' (the latter being the default). This switch could appear in the View / Sort menu, below the "sort by" switch and above the "ascending / descending" switch.

(in reply to comment 15)

Here is an example use case for sorting threads by oldest (initial) e-mail date:

I am a custodian for the U-Boot project. As such, I need to group postings by thread so that I can get all answers to a posted patch close together, and and I want them sorted by initial post date so that the order of threads follows the order of patch submissions.

Amicalement,
Albert.
Comment 18 Paul Rolland 2014-07-02 17:10:46 CEST
(In reply to comment #15)
>
> It still would be interesting to see any use case for sorting threads by the
> oldest email.  If you can't suggest one, evidently many users would
> appreciate a revised default thread sort order.

As this recently appeared with the behavior of the Up key while composing email, I really think that changing the default behavior is a bad idea.

On the other hand, I like have the possibility to sort threads based on "most recent" or "oldest" mails in the thread.

While we are playing with thread, one thing that would be awesome: being able to select that threads should be collapsed, except for parts of the tree leading to a new mail ! That would make long thread so much easier to read (they often have multiple subtrees).
Comment 19 andré 2014-07-03 15:48:22 CEST
(In reply to comment #16)
> (In reply to comment #15)
> > In my tests, I found emails "lost" as I suggested.  Only by total chance did
> > I encounter such emails.  So obviously your "default" can't be relied on.
> 
> Sorry, but can't accept blame for user error.

Apparently you fail to understand that the problem is caused by the dysfunction of the (default) sort order of threads.
As well, your workaround kludge simply does not work.  (Quite possibly because of newer messages in multiple threads.)
In no way related to any actions of the user.

Evidently the "user error" is using threads with claws mail.
Comment 20 Paul 2014-07-04 08:25:37 CEST
(In reply to comment #19)

> Apparently you fail to understand that the problem is caused by the
> dysfunction of the (default) sort order of threads.
> As well, your workaround kludge simply does not work.  (Quite possibly
> because of newer messages in multiple threads.)
> In no way related to any actions of the user.

André, what you call a "workaround kludge" that "does not work" has been working for me for many years. But this must be because I'm not as smart as you, and there's something that I just don't understand, and it's only though my ignorance that it works.

Congratulations André, you win the prize - a conical hat with a big gold star painted on it - for being the smartest kid on the block.
Comment 21 Adam Nielsen 2014-11-06 02:48:18 CET
I just got bitten by this bug too.  I deleted some e-mail and Claws then showed the contents of my Trash in the inbox folder (a bug I sometimes run into) but switching out and into the inbox a few times got it showing my inbox in the inbox folder again, but a few recent messages I had just moved with rules were missing.  I went to check in the destination folder and they weren't there!

Cue research on logging message deletes on the IMAP server because I no longer trust Claws as it deleted some important e-mail without warning.  But then a server-side search found the messages and they were in the correct folder, but Claws wasn't showing them for some reason.  In the end I figured out that because the e-mail thread had been going on since 2011, the new e-mails were half way up the folder in the middle of the 2011 stuff, instead of right at the end with all the other 2014 mail.

It would be really nice if there was an option to pick your favourite sort order and then apply it to all folders.  That would solve the problem and keep everyone happy.  As it stands now, if I forget to change the sort for each of the hundreds of IMAP folders one by one then I can easily get bitten again (this isn't the first time, just the first time it happened with important e-mails.)
Comment 22 Paul 2014-11-06 09:54:18 CET
(In reply to comment #21)

Adam,

> I just got bitten by this bug too.  

For a start, it's not a bug. It's a feature request.

> I deleted some e-mail and Claws then
> showed the contents of my Trash in the inbox folder (a bug I sometimes run
> into) but switching out and into the inbox a few times got it showing my
> inbox in the inbox folder again, but a few recent messages I had just moved
> with rules were missing.  I went to check in the destination folder and they
> weren't there!

Sounds like user error to me, as does...

> Cue research on logging message deletes on the IMAP server because I no
> longer trust Claws as it deleted some important e-mail without warning.

No, it didn't. Total false statement, as you confirm here:

>  But
> then a server-side search found the messages and they were in the correct
> folder, but Claws wasn't showing them for some reason.  In the end I figured
> out that because the e-mail thread had been going on since 2011, the new
> e-mails were half way up the folder in the middle of the 2011 stuff, instead
> of right at the end with all the other 2014 mail.

Please keep comments 'on topic', and don't be reporting PEBCAK as bugs. Thanks!