buzz
buzz copied to clipboard
jonhoo
Specify inboxes
Right now the application searches the entire email account for unread emails. It would be awesome if we could limit that to a list of inboxes, or the other way around, exclude some inboxes. For example, I personally do not need to be notified for things like newsletters.
How we can implement this feature?
imap::Session::select says it can have one inbox selected at a time. and we must use multiple connections to have several parallel open inboxes.
Can we use a multiplexing technique? and do a round robin select on inboxes and check them?
I think we're basically limited to one mailbox at the moment, you're right. This comes directly from the IMAP RFC. We could spin up a thread with a connection for each mailbox though, and that might get you pretty far.
@DanielVoogsgerd I'm not quite sure why you'd get messages from all your inboxes. You should just get notifications from the main inbox folder, which buzz already selects.
OK then. i just wanted to do some open source contributing in this tool that i use. I will find other issues or features needed and try to write them.
It has been a while ago. I don't know exactly what I meant, but I think I mixed up folders and mailboxes. I used to sort newsletters into a separate folder automatically and I think I was annoyed at getting popups from that, but I think I sorted that out by unsubscribing more aggressively :')
Assuming this is the case, something like a list where you can exclude folders would suffice I think.
Since the summer of 2019, I've been too busy to contribute to open source projects, unfortunately, although some times has freed up over the last couple of weeks. However, I think I'd rather work on DanielVoogsgerd/icon-finder-rs to fix the hardcoded icons if I were to dedicate time to this project.
Seems like @hamidrezakp implemented it in #19 🥳
I think what you meant was to specify or exclude some folders, but #19 just let you select one folder. Maybe we should make this issue open again and if anyone else needed this feature, start implementing that.
Sure, I think a good start might be the possibility to specify multiple folders to watch. The exclusion of folders seems like it would be a bit more complex both in design and implementation.
My personal email setup changed and it is not really relevant for me anymore. However, I do have a bit more time on my hands nowadays so I might be able to take a look.
Edit: Thinking about it some more it should be fairly easy to implement multiple folders. Considering the constraint of a single folder per connection, it might be nice to add a new struct along the lines of AccountFolder. And change the folder field in Account from Option<String> to Vec<String>. After deserialisation you can then just split account into multiple AccountFolders and create one thread/connection for each.
The big downside of this change would be that it would be a breaking change in the configuration. And if you're going to do that, you might want to rethink the configuration entirely (e.g. use an array of tables for the account definitions, as this would open up some space for general settings as mentioned in #6).
Edit: Thinking about it some more it should be fairly easy to implement multiple folders. Considering the constraint of a single folder per connection, it might be nice to add a new struct along the lines of AccountFolder. And change the folder field in Account from Option<String> to Vec<String>. After deserialisation you can then just split account into multiple AccountFolders and create one thread/connection for each.
Yeah i was thinking the same. Let me know if you want to do this one, I have some free time in the next week.
I ended up combining the new folders option with the old folder option and defaulting to INBOX when neither option provides a folder. This way we don't break backwards compatiblity and we can deprecate the old folder option (at a later time).
The solution is not the most elegant, but I think it's quite in line with the rest of the code right now. The field by field toml parsing is becoming a bit of a pain. If you venture one layer deeper as we do now with the array of folders the nesting also becomes a bit worse.
Maybe refactoring the entire main.rs and especially the toml parsing might be a good idea soon.
I ended up combining the new folders option with the old folder option and defaulting to INBOX when neither option provides a folder. This way we don't break backwards compatiblity and we can deprecate the old folder option (at a later time).
Great! i like this method.
Maybe refactoring the entire main.rs and especially the toml parsing might be a good idea soon.
Totally agree. Instead of manually parsing, we can use config crate to do the deserialization and parsing for us.