Created attachment 2137 [details] The clawsrc settings file to help reproduce the bug After a move operation on (say) message A, the selector in the message list jumps to another message B, but the message window still shows the text of A. This is confusing at best, and it could be embarrassing, e.g. if the user should fail to notice this and sends a reply, thinking it is to A, but in reality it is to B. To reproduce: * Go to /Configuration/Preferences/Display/Summaries, and then to the 'Message List' tab. * In the "Open message when selected" group, uncheck the "When deleting or moving messages" checkbox. * Further down, uncheck "Execute immediately when moving or deleting messages". There may be more setting that are involved in this, so I have attached my clawsrc file for easy reproduction. Once the settings are done: 1. Select a message in the summary list. Its text appears in the window below. 2. Delete the message. The cursor (selector) in the list jumps to another message, and the message window is now empty. That's OK. So far, so good. Now: 3. Select another message. 4. Move it (e.g. to trash). The cursor (selector) in the list jumps to another message, as before, but the message window still shows the text of the moved message. So the summary view and the detail view now have different information - i.e. they are out of sync. It may not be a big deal, but it is definitely a bug.
Here the message view is cleared when doing 3 and 4.
Correction to comment #1: I didn't uncheck "Execute immediately when moving or deleting messages". When I do that the selection doesn't change, though.
Strange. I have to say that I didn't see anything obvious in the code either (hence no patch). So we're down to "find the differences". Could you try the attached clawsrc for the settings, or just do a diff with yours? Alternatively, could you send me yours? Offline is OK. It wouldn't make a difference that I'm still on GTK+ 2, would it? Of course I'm not familiar with the code, so a pointer to the relevant part of the sources would be useful, too. I looked in summaryview.c, respectively summary_delete() and summary_move_selected_to(), for code that clears the message window. If it's there, I must have missed it. Any other places where the fun could be happening? Or a function (e.g. in messageview.c) where I could insert a debug statement?
OK, using the sledgehammer approach, I added a call to messageview_clear() and that "solves" the problem. I'll see if that can be done in a more elegant way. And I'd still like to know what is going on.
Created attachment 2138 [details] Proposed patch to clear messageview How about this patch? If it doesn't help, it shouldn't hurt either, I suppose (didn't test with different settings from mine). But it still doesn't explain why I'm seeing it and you're not...
The options around the message list, what gets selected and when, and what gets opened and when are many. It seeks to satisfy as many different users with as many different requirements as possible. This makes the way the options play together necessarily complicated. Your patch breaks at least one behaviour. With keyboard navigation we can use the cursor keys to move up and down through the list and press Enter when we want a msg to be displayed. With your patch, when all the 'Open message when selected' options turned off, if the user moves up the display gets cleared, the user presses Enter on a new message and it displays, which is fine. However, if the user moves up and then moves back down to the previously displayed message without displayed any other messages, and then presses Enter to display the previously displayed message again nothing happens. The previously displayed message can never be displayed again with the Enter key unless another message is displayed first. As for "definitely a bug", you specifically unchecked the 'When deleting or moving messages' checkbox in the 'Open message when selected' group when this particular option is directly the one you want to use to avoid this apparent bug. Therefore I conclude that this is not a bug and am closing it as INVALID.
Well, I did say that the proposed patch was not tested with different settings, so if you say that it breaks things, I won't argue with that - even though I don't think (note: "think") that the "enter" problem is caused by clearing the message view. I wouldn't have argued either if you had closed the bug report with "works for me". In that case I'd have tried to diagnose it further at this end. Now that you closed it with "invalid", it's a little different. It is entirely possible that I don't fully understand your explanation about my requirement being invalid, i.e. why I should not expect that the views stay in sync after a "move" (as they do with "delete"), but I do understand that you're saying that this requirement can't and won't be satisfied by Claws Mail. So I take note and rest my case. That doesn't mean I don't appreciate that you took some time to look into it, and regret that you were not able to immediately reproduce it. NB: I hope that this comment doesn't accidentally change the status of this bug report. If it does, it is certainly not intentional.
I didn't mark your explanation of your requirement being "invalid", but only this bug report being "invalid", as in claws-mail behaves as it should and therefore it is not a bug. > why I should not expect that the views stay in sync after a > "move" (as they do with "delete") Do you mean that you would prefer "when deleting or moving messages" split into "when deleting messages" and "when moving messages", or at least are questioning the wisdom of treating these two as one and the same?
Re "invalid": yes, that's how I understood it. "Invalid" as in "Working as designed". That's fine with me, no offense taken. No software product can be all things to all people. And no, I most certainly do not question the wisdom of treating them as one and the same. Quite to the contrary: they are conceptually identical to me. In both cases the message is gone from the folder. If I would be questioning anything, it would precisely be the "wisdom" of treating them differently, i.e. by clearing the message view after a delete but not after a move. That is what I am seeing anyway, and that is what I was reporting. But again: I am not questioning anything anymore, I rest my case.