When a message list is set to sort in reverse date order, the 'P', 'N' and spacebar keys navigate the wrong way. This is particularly noticeable when the list also shows a threaded view. Pressing the 'N' key for example will move to the previous message in the thread, not the next, and the spacebar key fails to work at all because the "next" (in fact preceding) messages have already been read. Message lists work correctly when sorted in reverse date order with claws-mail-3.14.1 and earlier (I've not tested claws-mail-3.15.0, and claws-mail-3.15.1 won't compile for me because of libical issues).
When the message list is sorted in reverse date order the P (previous) and N (next) are also reversed. If you sort from bottom to top N moves up, P moves down. When you sort from top to bottom N move down, P moves up.
Some one has marked this as invalid. I have re-opened it as it is obviously not invalid. You cannot navigate the message list when sorted in reverse date order in thread view correctly.
Created attachment 1864 [details] Patch for message lists sorted in reverse date order Attached is a patch which restores message lists sorted in reverse date order so as to behave in the way they did in previous versions of claws-mail. With claws-mail-3.16.0, you cannot properly navigate a message list sorted in reverse date order when in thread view. Pressing 'N' goes to the previous message in the thread, and 'P' operates vice versa. When in thread view, the space bar does not operate at all (it should read the next unread message in the thread) because the previous message in the thread has already been read. The patch corrects this. Arguably, when the end of a thread has been reached, pressing the 'N' or spacebar key should move "upwards" in the way that claws-mail-3.16 intends, but that would require a much more complicated patch. As mentioned, this patch restores the behavior of claws-mail so it works in the same way as version-3.14.1 (I have not tested 3.15 to see how that behaves). The patch applies to claws-mail-3.16.0.
This makes no sense. I'm all for reverting to the old behavior.
(In reply to comment #4) > This makes no sense. If you are referring to comment #3, then I agree that it makes no sense at all, because comment #3 is in error as to how it works.
No, I was referring (surprise!!) to the new nonsensical behavior of claws-mail, and you know it. But you prefer bullying users. If you think that the "next unread message" in a thread is one that is both older and visually higher up in the summary than the current message...well, it's probably useless to continue arguing (not that I thought otherwise anyway). And you don't even offer an option to let the user choose. Good job!
(In reply to comment #6) > No, I was referring (surprise!!) to the new nonsensical behavior of > claws-mail, and you know it. But you prefer bullying users. > If you think that the "next unread message" in a thread is one that is both > older and visually higher up in the summary than the current message...well, > it's probably useless to continue arguing (not that I thought otherwise > anyway). > And you don't even offer an option to let the user choose. > Good job! No, "next unread message" is (if sorting by date) a newer message. If older messages are higher up then the movement is downwards; if older messages are lower down the movement is upwards. This has been the case for 7 releases, over 2+ years. As for the option, there wasn't one before either. It is not my intention to bully users, and I don't feel that I am.
(In reply to comment #4) If claws-mail has changed since my bug report so as to behave in the way you now describe, then I am pleased to hear it - your "WONTFIX" has, if you are right, become "FIXED". (I don't use claws-mail any more.) However my comment #3 was correct as regards claws-mail-3.16.0, and your comment #4 is childish in the extreme, as was your peremptory closure of the bug report a year ago. (Probably not "bullying" as alleged, but certainly "pathetic". Maybe "misleading" also because if the behaviour has been corrected it certainly wasn't 2+ years ago as you say.)
Sorry when I referred to comment #4 I meant comment #5
(In reply to comment #8) > (In reply to comment #4) > > If claws-mail has changed since my bug report so as to behave in the way you > now describe, then I am pleased to hear it - your "WONTFIX" has, if you are > right, become "FIXED". (I don't use claws-mail any more.) > > However my comment #3 was correct as regards claws-mail-3.16.0, and your > comment #4 is childish in the extreme, as was your peremptory closure of the > bug report a year ago. (Probably not "bullying" as alleged, but certainly > "pathetic". Maybe "misleading" also because if the behaviour has been > corrected it certainly wasn't 2+ years ago as you say.) I'll eat "childish" and "pathetic". This change went in at version 3.15.0, which was released 26th March 2017. Quite simply, if you want 'previous' to act like 'next' and 'next to act like 'previous', instead of using 'next' use 'previous and vice versa. There's not much more to say. This change came about because of comments/requests by users and it never was like you say in comment #3.
(In reply to comment #10) No, you are mistaken: claws-mail-1.14.1, which I once used, did _not_ have the problem I reported in my bug report. claws-mail-4.16.0 _did_ have the problem. If it didn't, I would not have made the bug report. I have no idea how claws-mail-4.15 behaved - all I can say is that the problem was first introduced in claws-mail-4.15 or claws-mail-4.16. claws-mail-4.16.0 was the current version in April 2018 at the time of my bug report. If it was fixed in version 4.17.0, that was 10 months ago, not 2+ years ago as you state. Incidentally you closed it "WONTFIX", not already "FIXED". For some reason you were deliberately taking an attitude on the point. There is no point in your continuing to argue about this with your "facts". Install claws-mail-1.16.0 and see for yourself. Possibly you are just confused and the problem has not been corrected at all. In any event, in claws-mail-1.16.0 it is the case that with a message list sorted in reverse date order when in thread view, pressing 'N' goes to the previous message in the thread, and 'P' operates vice versa, and when in thread view, the space bar does not operate at all.
On reviewing this report from the beginning again, I now think you are being deliberately misleading. I think you agree with me that, as I reported in my bug report, with claws-mail-4.16.0 onwards "with a message list sorted in reverse date order when in thread view, pressing 'N' goes to the previous message in the thread, and 'P' operates vice versa, and when in thread view, the space bar does not operate at all". So when you made your childish remark that "If you are referring to comment #3, then I agree that it makes no sense at all, because comment #3 is in error as to how it works", what you really meant was comment #3 is _correct_ about how it works, but it is how you think it should work. In which case I think the remarks made by the poster in comment #4 and #6 are fully justified. Anyway, because of your attitude I have moved to a mail reader that works the way I want it to.
In the interests of calming the discussion a bit, I've run an independent test. I run claws 3.16.0 (the version from the openSUSE Leap 15.0 distro repositories to be exact). I don't understand the references by Chris to version 4.16; is that a typo? I normally run with sort from top-to-bottom (i.e. oldest at the top) but I just changed it to sort from bottom-to-top and then I marked some messages as unread, went to another folder and hit shift+N. I'll attach an image showing the summary window at this point. You'll notice that by and large newer posts are at the top but something seems a little odd with the threading, where the earliest in the thread is above everything else. So at the state as shown in the image, I press shift+N. The cursor goes up one row. I press shift+N again and the cursor goes back down to the already read message. Again and it goes up two rows to the last item in that thread. Again and it goes up to the first post in the thread, and then next up one to the 21:44 post in the 4006 thread. It doesn't move if I press shift+N again. So the behaviour I see is not as described by anybody here. IIRC, that's why I run with the opposite sort order.
Created attachment 1992 [details] image of summary window
Comment #13: Sorry, yes by 1.14.1, and 4.15.*, 4.16.* and 4.17.* I meant 3.14.1, 3.15.* and so on. I have not used claws-mail for a year so I don't know how current versions work. It sounds as if they are now doubly wrong as regards message lists sorted in reverse date order.
(In reply to comment #7) > (In reply to comment #6) > > No, I was referring (surprise!!) to the new nonsensical behavior of > > claws-mail, and you know it. But you prefer bullying users. > > If you think that the "next unread message" in a thread is one that is both > > older and visually higher up in the summary than the current message...well, > > it's probably useless to continue arguing (not that I thought otherwise > > anyway). > > And you don't even offer an option to let the user choose. > > Good job! > > No, "next unread message" is (if sorting by date) a newer message. If older > messages are higher up then the movement is downwards; if older messages are > lower down the movement is upwards. Did you even try it? If you sort by reverse date but preserve threads, "n" moves backwards in threads, meaning it selects the last (visually lowest, and perhaps chronologically newest) message in thread, and "n" moves to the the previous, which is visually higher and chronologically older. All very clearly explained by the OP in the very first bug comment. > This has been the case for 7 releases, over 2+ years. You changed a default behavior (which is questionable by itself), and without giving an option to users who wanted the keep old behavior. > As for the option, there wasn't one before either. Of course there wasn't one, before it wasn't needed.
(In reply to comment #16) Against my better judgement, and at risk of further personal insults, I'll repsond again... > Did you even try it? Is this a serious question? Of course I did. > All very clearly explained by the OP in the very first bug comment. And, I think, clearly answered in comment #1. > You changed a default behavior (which is questionable by itself), and > without giving an option to users who wanted the keep old behavior. Quite simply, if you want 'previous' to act like 'next' and 'next' to act like 'previous', instead of using 'next' use 'previous' and vice versa. > > As for the option, there wasn't one before either. > > Of course there wasn't one, before it wasn't needed. On the contrary, just like you think an option is needed for you, one could use the opposite point of view to say that an option was needed for those users who didn't want the previous behaviour. This was instigated, remember, by user requests and comments.
(In reply to comment #17) > (In reply to comment #16) > > Against my better judgement, and at risk of further personal insults If you stop being condescending, doing selective quoting and being misleading, nobody will insult you. > > Did you even try it? > > Is this a serious question? Of course I did. Then you'll see that: - the way "n" and "p" worked changed - the new behavior is that selecting the next unread message may navigate backwards (in space and time), which means if one uses "next unread message" to navigate a thread, the thread is read backwards Did you notice that? You surely did, if you tried it. > > All very clearly explained by the OP in the very first bug comment. > > And, I think, clearly answered in comment #1. Nope. You said nothing specifically about the problem the OP was mentioning (that is, default behavior change). You just said "you can do this and that". > > You changed a default behavior (which is questionable by itself), and > > without giving an option to users who wanted the keep old behavior. > > Quite simply, if you want 'previous' to act like 'next' and 'next' to act > like 'previous', instead of using 'next' use 'previous' and vice versa. Again, you're not answering. At this point everyone knows what these keys do, and how to get the desired behavior. IF you keep repeating that, you start looking as if you either don't get the point, or you're deliberately being misleading. You single-handedly forced a *change in default behavior* on all users, without giving an option to opt out. > > > As for the option, there wasn't one before either. > > > > Of course there wasn't one, before it wasn't needed. > > On the contrary, just like you think an option is needed for you, one could > use the opposite point of view to say that an option was needed for those > users who didn't want the previous behaviour. This was instigated, remember, > by user requests and comments. Again, stick to the point: before there was a default (good or bad, I'm not going into that. Good IMHO, but that's not the point). People were using that, some even were relying on that. The need for an option came the moment you changed that default, breaking claws behavior in an incompatible way (in fact, reversing the previous behavior). You could have made that as opt-in, so nothing would break for old user. Instead, you not only forced that change on all users, but provided no opt-out.