Created attachment 2140 [details] Patch to add a "deselect_on_delete" preference The issue ========= After a move or delete of a message from the summary list, Claws Mail jumps either to the next or the previous message, depending on the setting of the (hidden) “next_on_delete” preference. While it is nice that you can configure CM to not open that newly-selected message automatically, some people still find it annoying that you can't prevent the selector from moving at all. The proposed solution ===================== The attached patch gives those “some people” a new preference to do just that. Yes, yet another preference, but I didn't want to modify the semantics of “next_on_delete” and break compatibility for just about everybody else, Hence the new preference, tentatively called “deselect_on_delete”. How it works ============ The default is “0”, meaning “do not deselect”, being a double negation for “DO select (something)”, meaning that the current behavior is not affected in any way. If “deselect_on_delete” is set to “1”, no other message will be selected, and the “next_on_delete” preference will be effectively ignored. The cursor (selector) in the summary list will remain on the message that was just deleted/moved, and from there you can use the arrow keys to select what *you* think is the next one to handle – not the one that CM thinks you need to handle. Current Claws Mail users probably don't mind the hand-holding, but personally, I find it very annoying. And I am definitely not the only one, as can be seen from the popularity of a Thunderbird add-on that prevents similar behavior over there (just search the web for “deselect on delete” and “Thunderbird”). And in fact the name "deselect_on_delete" was inspired by that TB add-on. GUI === The current patch does not (yet) make this new preference accessible in the GUI. Personally, I don't need that, but if this would be the only objection against its adoption, I am willing to give it a try. In that case I'd also suggest to “unhide” the “next_on_delete” preference, and combine the two settings into three radio buttons, grouped as “Message to select after move or delete”, with button labels “Previous”, “Next”, “None”. Note on testing =============== Of course I am submitting the patch in the hope that it will be reviewed, but I'd like to ask that the developers look at the code first, to see if it would break things for *existing* users. Next, I'd like to know if it makes sense, code-wise, to do what the patch does for “deselect_on_delete = 1”. The last step would be to see what happens on the screen in both cases. I am asking (requesting) this because, with my settings, I am seeing some things that are not quite right (mainly related to focus). They are not easily reproducibly, but to the best of my knowledge they are present without the patch as well. Unfortunately, if people apply the patch AND modify some other settings to see what happens, it would be difficult to tell which of these two changes is the cause.
> I'd like to ask that the developers look at the code first That made me laugh - do you really think we accept patches without looking at the code and testing them first?
But I was afraid that you guys might have just a quick look at the code, to make sure it doesn't wipe your disk or something, and then go about applying and testing it. A thorough code review could come last, if it doesn't segfault, behaves as advertised etc. That would be a natural thing to do, especially for those of us who don't have a time machine on hand of the kind that generates some extra hours in a day...
Oops, it seems the dog ate my first sentence. That was supposed to be: "I'd hope not <g>".
A major problem with your patch is that it breaks keyboard navigation. The cursor keys can't be used to move upwards or downwards from the previous position.
Let me clarify comment #4: That is, when 'execute immediately' is turned on, and your new option is activated.
Created attachment 2142 [details] New version of "deselect_on_delete" patch Yes, good catch, thanks. That makes sense, kind of. If the deleted message is gone, the selector has no place to sit on anymore. Maybe I could convince it to nestle itself in between the prev and next messages, but even then it would not be visible, hence confusing. Attached is a new version of the patch (same file name, hope that's no problem). When "immediate_execution" is set to "1", the new option is simply ignored and things keep working as before.