Created attachment 1894 [details] screenshot of first folder version 3.16.0git241 STR: 1. Send a message to myself (test 1) 2. Receive the message 3. Repeat 1-2 (test 2) 4. Mark sent messages in black and received in red and put them in the same folder 5. Make sure sorting is by date EXPECTED: test 1 - black test 1 - red test 2 - black test 2 - red ACTUAL: test 1 - black test 1 - red test 2 - red test 2 - black i.e. for test 2 the received message appears before the sent one (incorrect). 7. Move all 4 messages to a new empty folder EXPECTED: (same as above). Additionally I expect at least the wrong actual sorting to be preserved. ACTUAL: test 1 - red test 1 - black test 2 - black test 2 - red i.e. the order has changed and now for test 1 the sent message shows before the received one (incorrect) and for test 2 the sorting is correct. Additionally: the attachment icons on red messages are missing (mentioned in bug#3307)
Created attachment 1895 [details] screenshot of second folder (after the move)
Note: moving messages back to the first folder restores the sorting: test 1 - black test 1 - red test 2 - red test 2 - black
I'd expect sorting of messages by date within a folder to be based only on the date field of the message itself. Given that the red/black pairs are really copies of the same message (with the same date value), I see no reason whatsoever why Claws Mail should prefer any order within such a pair. Or, looking at it another way: You suggest that, when sorting messages with equal date field values, some constraints should be placed on the sort order (either some additional data, like the order in which the messages showed up in the client, or preserving the order when moving between folders). This would be an "enhancement", but one which I, at least, would object to, as such constraints could make the sorting in general slower, and the situation they improve is, in my view, a fringe use-case.
> Given that the red/black pairs are really copies of > the same message (with the same date value), I see > no reason whatsoever why Claws Mail should prefer > any order within such a pair. Also there is no reason why CM should prefer showing an event in the future (received message) before an event happened in the past (sent message) or changing that by just moving the pair to another folder. > Or, looking at it another way: You suggest that, > when sorting messages with equal date field values, > some constraints should be placed on the sort order > (either some additional data, like the order in > which the messages showed up in the client, or > preserving the order when moving between folders). I don't know what is the proper way to fix this. > This would be an "enhancement", but one which I, at > least, would object to, as such constraints could > make the sorting in general slower, and the > situation they improve is, in my view, a fringe > use-case. Well, it can be argued that achieving a quick but wrong result is not really a gain. And of course you can argue back that sorting a message sent to oneself doesn't have any value as it is unusual and would never be an actual issue. But the fact remains - the sorting is wrong, so I thought I should report it.
(In reply to comment #4) > > Given that the red/black pairs are really copies of > > the same message (with the same date value), I see > > no reason whatsoever why Claws Mail should prefer > > any order within such a pair. > > Also there is no reason why CM should prefer showing > an event in the future (received message) before an > event happened in the past (sent message) or changing > that by just moving the pair to another folder. > I must have been unclear in my earlier comment. When I said "I see no reason whatsoever why Claws Mail should prefer any order within such a pair", I meant that either order is OK and CM should be free to pick the order it sees fit. > > Well, it can be argued that achieving a quick but > wrong result is not really a gain. My point, to be perfectly clear: The results you have seen are not wrong. To explain it even more: Suppose I send you a message at 14:00, but for some reason, it takes two hours to arrive. I also send you another message at 15:00, and for some (other) reason, that one takes only two minutes to arrive. When you have received both messages, and sort the folder by date, the 14:00 message should show first, although it arrived later -- because it is dated earlier. "Sorting by date" should not take into account the order of network events, but just the date as it shows in the message. And thus, if you have two messages with the exact same date (like in your examples), you should not expect any specific ordering between them.
> When I said "I see no reason whatsoever why Claws > Mail should prefer any order within such a pair", I > meant that either order is OK and CM should be free > to pick the order it sees fit. I know what you meant but it is still wrong. CM should not "be free" but should do what we need = correct sorting. How exactly this should be achieved - I really don't know but it is wrong to see a future event appear earlier than a past one. Whether it would be a matter of involving additional checks in the sorting algorithm or something else on the computer side, the human expectation is that the past is before the future. Expecting the user to be an expert who would understand why things work wrongly and based on that accept the wrong behavior is also a wrong expectation. I hope that clarifies. > My point, to be perfectly clear: The results you > have seen are not wrong. Based on what was explained and demonstrated: Not only they are wrong but also inconsistent. > To explain it even more: [...] if you have two > messages with the exact same date (like in your > examples), you should not expect any specific > ordering between them. I understand your logic but it still doesn't explain the inconsistency observed when moving the message pairs between different folders.
the pairs of messages have the same date, both orders are correct.
Paul, Why is there inconsistency when moving between folders? And what determines which message with the same date should be before the other?
I don't see anything about this that is odd or "wrong". In the world of record retrieval, records are selected and the output ordered, by the criteria provided. If the criteria match exactly across all the retrieved records the output order is generally referred to as "arbitrary", and is determined by deeper issues. In the case of a database, it's often record id or index order. With files it's generally inode. This means that if you copy records/files from one location to another these lower-level items will likely change, so the output order will change too. So, if you have 2 or more records where the user-visible Date: (message creation date/time) field is identical, and that's the field you are selecting and sorting on, then the output order is what it is and may well be different if the same messages are moved to a different location. With a database, the output can well vary from one record retrieval and display to the next due to underlying index optimization. I have often wished that I could use more than one criteria for the sort of records on output (something that is basic to true database output), but these types of displays, which are common across most current UIs of all types, don't support that. It would be a nice enhancement.