Bug 21705

Summary:	M6 Claws-mail behaves badly deleting a message from a list
Product:	Mageia	Reporter:	Lewis Smith <lewyssmith>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	cae
Version:	6
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Lewis Smith 2017-09-13 22:26:04 CEST

Description of problem:
When deleting a message (other than the first) from a folder list, the next message selected is that *before* the deleted one; rather than the following one, as was the case in Mageia 5. This means that you have to additionally down-arrow to the next message, each time. Worse, if you delete the first message of a list, it reverts to the *last* one; meaning that you have to page up to the head of the list each time.
This is all very inconvenient.

Version-Release number of selected component (if applicable):
Magei 6

How reproducible:
Always.

Steps to Reproduce:
As described.

Comment 1 Charles Edwards 2017-09-13 22:56:30 CEST

Sorry Lewis but this is not a bug.

It is an upstream change in claws-mail and is configurable in the "hidden preferences" settings that can be accessed using clawsker or by manually 
editing ~./claws-mail/clawsrc 

You want to change "next_on_delete=0" to "next_on_delete=1"

Additional info on the "hidden preferences" is provided in section 6.9 of the claws-mail manual. 



This bug should be closed as Resolved/Invalid

CC: (none) => cae

Comment 2 Lewis Smith 2017-09-14 20:30:34 CEST

(In reply to Charles Edwards from comment #1)
Thank you for your comment.

> Sorry Lewis but this is not a bug.
I am please to learn it.

> It is an upstream change in claws-mail and is configurable in the "hidden
> preferences" settings that can be accessed using clawsker or by manually 
> editing ~./claws-mail/clawsrc 
> You want to change "next_on_delete=0" to "next_on_delete=1"
Will do. Who would guess (Mr Average User)? For habituees it certianly appears as a regression. Never mind.

> This bug should be closed as Resolved/Invalid
Am doing.

Resolution: (none) => INVALID
Status: NEW => RESOLVED