(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.2 (using KDE 2.1.2 ) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.95.3 [FreeBSD] 20010315 (release) OS: FreeBSD 4.3-RELEASE i386 OS/Compiler notes: It would be nice to have some additional delete options. As well as the current "Delete" a "Mark for deletion" option would be valuable. Probably implemented as a special status. 1. It means the thread display wouldn't jump back and forth as messages are deleted which is disorientating. 2. It means that you don't have to hunt through the trash looking for a message you've accidentally deleted. If you have lots of mail folders and delete lots of mail in a session it can be a pain to have to dig through the trash trying to find the message you didn't mean to delete -- seeing the message in the context of its original mail folder could help a lot. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 9. June 2001 20:38 nik@freebsd.org wrote: > It would be nice to have some additional delete options. > > As well as the current "Delete" a "Mark for deletion" option would > be valuable. Probably implemented as a special status. > > 1. It means the thread display wouldn't jump back and forth as > messages are deleted which is disorientating. > > 2. It means that you don't have to hunt through the trash looking > for a message you've accidentally deleted. If you have lots of mail > folders and delete lots of mail in a session it can be a pain to > have to dig through the trash trying to find the message you didn't > mean to delete -- seeing the message in the context of its original > mail folder could help a lot. I don't consider this being useful. Two different delete options will definitely confuse many users. BTW if you accidentally deleted a message you can normally find it very easy if you use the "search message" feature or the various sorting options. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KOT1GnR+RTDgudgRAn/0AKDSZwuURlVdFPUJIEYGGKXT9M6bhQCgtxg+ iduR+TcI80uCoByPDz+hM1k= =gtyf -----END PGP SIGNATURE-----
*** Bug 61370 has been marked as a duplicate of this bug. ***
Please reconsider implementing this behavior! Here are some reasons: - "Mark as deleted" is used by many other mail clients. Therefore, users switching to kmail have it easier when it is implemented. For me, the absence of this feature is the reason not to use kmail :( - Not copying to trash decreases network traffic - It is very useful when handling large folders. You can mark messages deleted without having to read them, if you are using IMAP. - Threaded reading doesn't mess up when you mark a mail deleted. Otherwise, when you delete a mail with several children, all these children will become separate subtrees and spread out. - Undeleting is much easier to do :) I noticed that when I delete an IMAP mail, the mail is briefly displayed as crossed out, and then removed from the display. So the code to show it is already there... Here's how I imagine the implementation: - Add a configuration option "Mark as deleted instead of moving to trash" - If set, "Delete" just marks the mail deleted, the display shows deleted mails, and "mark deleted" is possible in the marking menus. That's all. - I read in another bug that the maildir implementation would have to be rewritten to implement this behavior. If that is still the case, how about just using the old behavior on those folders? Do you think this would be hard to implement? Do you see reasons why it should not be implemented, given that the behavior is configurable? Thanks!!
I'd like to add one more reason why marking mails "deleted" is a good idea: When working with many folders using IMAP (using other clients like mulberry) it sets the IMAP-flag "deleted" and actually deletes mails when its compacting/expunging the folder. This can be done on a _per_ folder basis. The main advantage I see here is that I can mark mails deleted and keep them in this state for many months and expunge a single folder whenever I want. I don't keep mails marked "deleted" for may month, but a few days are quite normal - it should just give you an idea of asynchronous marking and actually deleting mails. It's hard if not impossible to remember which mails can be safely deleted and which ones not if their main context, the folder, is missing. If I deleted 3 mails from 3 different folders and they are moved to a single trash-folder then emptying the trash will remove all mails. Therefore it's not only harder to find deleted mails when using a single trash-folder because their context is missing. It's also harder to control when and which messages are really deleted. I'd also like to support all reasons Wout Mertens listed. This missing feature is the main reason that holds me back from using KMail on a daily basis, because I find it confusing to move deleted mails into one trash folder.
Just like to chime in on this one -- I'm a big fan of this feature, too, having used it for years with ExMH. FWIW, I also like another behaviour of ExMH's -- a "marked for move" state. When you indicate that a message should be moved to another folder, it doesn't move that message straight away -- instead it marks it for moving on "commit". ("commit" is the ExMH option to purge/compact/perform deletions/moves/etc. it usually takes place when you switch to another folder.)
*** Bug 65418 has been marked as a duplicate of this bug. ***
Coming from " http://bugs.kde.org/show_bug.cgi?id=66354 - Kmail reports the wrong number of messages in IMAP folders" here comes my contribution :-) I encountered the problem of appearing and disappearing unread messages using shared mail folders in this environment (cyrus imapd): * SEEN flags handled individually per user, * DELETED flag is handled globally. * only a subgroup of users has the ACL set to apply the DELETED flag to a message. Now, when a ACLed user deletes a mail before I (kmail) could mark it as read (thru reading it), it stays invisible forever and I can NOT flag it read anymore. This leads to the increasing unread number every time I look into another folder, and decreasing to the real number when I return to the respective folder (in the folder pane). Expunge all deleted mails on the folder is no workaround here, because the users may lack the ACL item to do that. Since using the DELETED flag is very common to working with IMAP, I suggest adding it to kmail. As Carsten already said, adding this to kmail is also the only way to get rid of the invisible unseen messages. Important to say, this is imho NO systematic bug in the imapd environment, but only appears because kmail dont handle deleted messages the way the other IMAP clients do. If kmail keeps handling mail items split-brained like now (counting on his own when displaying the folder, using the numbers given by the imapd when not displaying it), it will never be able to consistantly show the right number of unseen messages. By the way, I am not quite sure whether it is unSEEN or unREAD here - but I hope my description of the problem is still understandable. This is extremely important IMHO, as it is just annoying to chase those messages all the time. Please consider fixing this issue soon!
*** Bug 90386 has been marked as a duplicate of this bug. ***
one more comment - after moving message from IMAP folder to "Trash" and selecting "Empty trash" (maybe not correct as I'm using localised version), messages are still on the server and are marked as deleted. however, there's no way to determine such state in KMail, user can only "Compact" every folder which is suspected of holding deleted messages. In some (quite common) IMAP setups, it means tens of folders - that's really annoying and user DOESN'T receive any feedback at all. KMail/1.7, KDE/3.3.0, Gentoo.
On Friday 01 October 2004 18:40, Thomas Zander wrote: > > the only chance to handle this is to mark messages as deleted on the > > client when they're on the server. > > That does not make sense; you are not allowed to change my email-status > when checking for unread email.. You got me wrong. Kmail doesn't support the deleted state currently so deleted mails are always moved to trash. The mentioned problem can be solved by marking mails that are deleted on the server also as deleted on the client but without moving them to trash. So the emails appear as new but also as deleted which is the same state as on the server. So it would like this: You check for new emails, the folder shows that you have one new message, click on that folder and you see a new message which is probably striked through to show that is deleted. But this is a new feature and meanwhile there is unfortunately nothing we can do to work around this. > KMail should detect this state, and if it has to do so by doing a search, > then so be it. Nope, this would not be acceptable for performance. You'd have to select every folder on the server which will takes ages for a large number of folders. > Suggesting KMail change the state of emails on the server is unacceptable. See above, this is not what I meant.
Okay, another year passed since the last comment. Is there any willing to work on this feature? Or is it blocked by current KMail design? Is there a better place to talk about this topic? Why doesn't KMail work as any other common MUA?
Because nobody has implemented it due to higher priorities of other issues.
This is quite an important bug for me. Other mail clients allow you to see messages marked 'deleted' in the index of the folder in which they actually reside -- it's very strange that kmail doesn't. The behaviour when deleting messages is confusing, because the eye expects to track down the list... but the list is changing. Normal behaviour is just to show the message with a line through it. In fact, kmail does do that... but only for a second and then it disappears. It's worse when you accidentally delete a message you didn't mean to. In other mail clients, you simple re-select the message in question and remove the 'deleted' flag. In kmail, ... well, actually in kmail I haven't worked out how to find the 'deleted' messages at all. I just use another email client to remove the 'deleted' flag, instead.
According to one other user there seems to be a difference in manually compacting folders (does purge deleted mails) and doing so via DCOP (does not purge deleted mails) http://lists.kde.org/?l=kde&m=116256397101719&w=2
Wow - is it really more than five years now? HAPPY BIRHDAY #26986!! Please resolve that bug at last. The described behaviour has been visible too long now. We are running several mail sites with shared IMAP folders, where the situation of unseen, but deleted messages occurs frequently due to other users moving the message before one has looked into the folder. People can not escape those "ghost messages", because they are lacking the ACL to expunge the particular folder. Ghost messages appear frequently, because other users delete messages without expunging the folder (which must be explicitly invoked in most imap clients). kmail is the only mail client in my scope of knowledge that does not show a consistent number of unseen messages like that. I suppose there must be a solution out there.. In fact, handling of deleted messages in a "common" way does seem to me as the only option to get rid of this. There is tons of examples how this can be done out there.. Why is it taking so long for kmail? I understand that a fast emerging and huge project like kde does need to set priorities, but I do not understand how this bug can be disregarded so consistently for such a long time. If ext2 would show a wrong file count when files would have been deleted, would you have been using linux prior to reiser/xfs? Please look at the facts from a user's point of view - this is a very annoying and distracting behaviour for people that actually do not care about SELECTs, RECENT numbers and UID flags. As a workaround, I suggest following: On selecting a mailbox, compare the reported number of unseen messages (RECENT) with the number that kmail displays. If it differs, do a search for unseen/unread, but deleted messages and display a dialog explaining the facts and offering to flag those messages as read. Whenever the crossed-out-NASA-technology-feature is ready to go, we can remove that hook and just display unread but deleted mails in the message list.
*** Bug 45232 has been marked as a duplicate of this bug. ***
I thought it was related to my setup (i.e. my workstation and my configuration of Dovecot) and I'd be the first one to report it... and bam... I come across a six-year-old bug that the developers simply ignore. Being a developer myself I know what its like when a user requests a feature you'd rather not see, but I can't find ANY imaginable reason to consider this SHOWSTOPPER as a WISHLIST. Now this makes me deeply disappointed with KMail and Kontact in general. My opinions are just mine, but I won't ever deploy KMail with this flaw, and I bet that there are big guys that do the same thing. And now compare it to the hype around KDE you're trying to create. It's fiction.
Here's the scenario that I seem to run in to quite often: I open my spam folder with 600 messages and I only want to quickly scan the subject lines and delete all of it. What happens is that kmail wants to download each and every one to my local machine. When I connect through a slow link, this is even more problematic. With Thunderbird, I can delete everything and compact the folder and I'm done in seconds.
*** Bug 88423 has been marked as a duplicate of this bug. ***
Sigh. Happy 9th aniversary, wish 26986! Can't believe 9 years have gone by so fast.
it seems still valid for KMail2, switching product to kmail2. Please confirm
Created attachment 75462 [details] Account settings in Thunderbird This is the way Thunderbird handles this: it leaves the decision to the advanced user, with moving to trash as a default. And I think that this is the best way handling this. I use both clients on a regular basis, partly because marking as deleted is a prerequisite for me on an IMAP account I share with my colleagues. Both clients have their strengths and weaknesses, but this is a standard that Kontact really needs to adopt IMHO.
About eleven and a half year. And… since I was using KMail after switching my mail to Linux from YAM (Yet Another Mailer) for AmigaOS and only recently dig into IMAP with Sieve I wasn't even aware that deleting could mean anything else than moving to trashcan unless I had a look at Trojitá. At first I thought how strangely Trojitá handles deleting mail… but now it makes sense. Looks like a nice feature to have. But… I think the bug report is lost in… space. And I suggest bringing this topic to kde-pim developer mailing list. Or even implement it yourself…