This is a RFE is originated from Debian bug #889867. Original reporter states the following problem: > Most importantly, as I have some folders sorted ascending, some sorted > descending depending on a custom and the usage practice, there is > still no way to get consistent behaviour of focusing after deletion > even while using the "next_on_delete" setting. And proposes this solution: > I think it would be nice to have a more extended general property, such as: > > focus_on_delete: > a) next message by date > b) previous message by date > c) always message above > d) always message below > > Prior Claws-mail versions were always behaving as "d)"; > > In the current versions using the next_on_delete setting we can only choose > between "a)" and "b)" . Full report here: https://bugs.debian.org/889867 Thanks in advance,
Created attachment 1951 [details] prefs: add option "Ignore sort direction / Make sort order aware" If I may, I believe this issue is indeed about the so-called "sort order awareness" (SOA) feature, as described on the original bug report -- Although I would disagree with the statement made there that anything was fixed, and obviously so would the original reporter. Indeed the SOA means that "next" means either the next or previous message on the list, depending on its current sort order (direction really). Which might (at least to some) result in counter-intuitive and/or inconsistent behaviors as described; For instance, if one is using some folders sorted asc and others desc, as is the case here. Clearly there's no solution for it currently in claws, though allow me to share a previously shared patch that does add an option so one can opt out of this SOA, which I believe would result in what is being needed here. HTH,
(In reply to comment #1) > Indeed the SOA means that "next" means either the next or previous message > on the list No, next means next. It's simple. No linguistic contortion necessary. sort top to bottom - the next received msg is added at the bottom sort from bottom to top - the next received msg is added at the top the next msg never becomes the previous msg, and vice versa.
(In reply to comment #2) > (In reply to comment #1) > > sort top to bottom - the next received msg is added at the bottom > sort from bottom to top - the next received msg is added at the top Well, you seem to have this view of things indeed, that a list sorted asc has the first item on top and the last on bottom, but a list sorted desc has the first item at the bottom and the last item on top. Fine, I get that, but that's not the common view. Usually one would say the first item on the list is always on top, and it's whether that item is the smallest or biggest/oldest or newest/etc that depends on the sort order (direction) used. So within that view/mindset/whatever you call it, it's always first on top, next goes down and last at the bottom. That is how things works traditionally, that is indeed how things work in the code, which is why your SOA have all the functions to e.g. get the next message be something along the lines of: function get_next_msg() { if (sort_order == ASC) return get_next_item(msg_list); else return get_prev_item(msg_list); } Now you may question whether it is common or not if you'd like, but clearly such a view exists (even beyond me -- see other times this issue came up, or the original reporter here), and if you can understand what is meant by it, you can see there's no way to achieve it currently, despite it being a completely valid & consistent behavior, whereas it would be possible (for those so inclined) with the option to disable the SOA.