On Sunday October 18 2020 09:56:04 Peter Lewis wrote: >Then move the entire directory ~/.local/share/akonadi into somewhere safe (~/ >tmp for example) ... >Go make yourself a coffee or tea (according to taste). ... >For me this process, though brutal, has worked and I get a nice fast clean >kmail.
This suggests that akonadi builds up crud over time which bogs it down. Let's assume that this is not just the email content (or indeed even the headers - you can select how long you want to keep cached copies of the email content!). If correct, and this is due to indexing information required for searching, wouldn't it be possible NOT to generate all that information for users who will never need it? I for one would be happy to give up (fast!) content search on the server if it meant KMail became faster and/or more stable overall. NB: this would be all the more useful since KMail does not (AFAIK) have a select-only feature. Every selected message gets downloaded, and I presume indexed in the process. That's a lot of unnecessary work if you're just cleaning up your mailbox, idem if you delete a message and KMail auto-selects another message that you may not want to read at all (and that maybe you want to keep in "unread" status). NB2: that's another gripe of mine. I've been able to add a "select none" setting for the "message select on opening a folder" option to my local build (i.e. I select a folder and no message is opened until I select one). But I've never figured out yet how to prevent KMail from selecting another message after deleting the current message. R
