Version: 1.8 (using KDE 3.4.0, Debian Package 4:3.4.0-0pre4 (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-12) OS: Linux (i686) release 2.6.11-chistera.06 Hi, I will do my best to explain the feature I'd like to see implemented, and the motivation behind it. For a person familiar with the Mutt mail reader, all the following can be summarized as: "I would like in KMail the equivalent of Mutt's 'set nomark_old'". So, there we go: currently, when one enters a folder, there can be two types of unread messages: new (red in the default color scheme), and old (blue); obviously, the new ones are those that were delivered since the last time the user entered that folder. When leaving the folder, KMail will move all new messages to state old, so that the next time the user enters, the messages marked as new are those delivered since, and not a mixture. The rationale behind this is that if the user enters a folder, the new messages there are no longer "unseen", so they are old. What I'd like is that KMail offered the possibility to prevent such automatic conversion upon leaving (i.e., a configurable option defaulting to the present behavior). My rationale for this is that for e.g. big folders, that a user enters a folder doesn't actually mean that he gets to "see" all the new messages, thus marking them as old means loosing important bits of information. (In other words, myself and other people like the "new" status not to be transient, and that a message never gets out of that state automatically. In this scheme, a message marked as "new" implies that it still needs attention, and a message marked as "old" implies the opposite, since it was put in such state by hand.) I know that all the above is not relevant at all for the average user, but when reading big amounts of mail it really can make a difference, specially if used to that scheme via some other MUA. Thanks for considering.
In other words, you'd like new messages to be marked as "unread" (blue), is that it? Since the only difference between new and unread is exactly what you're asking to be removed...
> In other words, you'd like new messages to be marked as "unread" > (blue), is that it? Uhm, no. Sorry if I didn't make myself clear, I will try to explain with an example now. SEQUENCE OF ACTIONS =================== 1. Folder 'foo' contains a read message with subject "Test 1". 2. Mail with subject "Test 2" is delivered to folder 'foo'. 3. User visits folder 'foo'. (To make the example work, let's say he has configured "When entering folder: Jump to last selected message", so when he enters, "Test 1" is selected.) 4. User visits some other folder. 5. Mail with subject "Test 3" is delivered to folder 'foo'. 6. User visits folder 'foo'. WHAT KMAIL DOES NOW =================== At (3), "Test 2" is new (red). At (6), "Test 2" is old (blue), and "Test 3" is new (red). [This is of course because KMail changed "Test 2" from new to old between steps #3 and #4.] WHAT I WOULD LIKE A CONFIGURATION OPTION FOR ============================================ At (3), "Test 2" is new (red). [The same as above.] At (6), both "Test 2" and "Test 3" are new (red). [That is, KMail did nothing to "Test 2" upon leaving 'foo', i.e. between steps #3 and #4.] The whole point of this is: KMail can be configured so that no message goes from new to old (red to blue) automatically, because there are mail reading schemes which rely on such transition always being done by hand (which other MUAs allow). Thanks for the follow-up.
The question is rather, what is the workflow that necessitates that? Since unread is implied by new, using the unread status wherever you have so far used the new status should give you exactly the behavior you describe. As Thiago noted, the only implimentational difference between the two is the automatic new -> unread transition. New is simply an additional property that you don't need to care about, if you don't need it.
Created attachment 11066 [details] Patch for this bug Well, I'm not sure if this bug needs to be fixed or you're going to mark it as wontfix, but I provide a patch for it anyway :P Best regards
BTW, I don't fully understand why this "feature" is useful, but I've already found several mutt users asking me about it.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.