* On 27 Jan 2015, Yoshiki Vazquez Baeza wrote: > Hello, > > This patch adds a new setting that you can configure to execute a > command every time new mail is found in your current mailbox.
I've had a couple of patches in progress for a while that are related. I wanted to mention it mainly because I've already done most of that work, and it should not be seen as a comment on your code -- just two different but related approaches to the same problem, which can coexist. I wanted to propose it for discussion, but now that your patch is here the discussion has begun without the code. :) So this message is for Yoshiki to respond to, but also for general community response to a design idea for mail notification. My first patch reworks the notification mechanism a bit to add "biff" and "unbiff" commands. These configure notifications generally, without regard to how the notification service is implemented. A single call-out function implements the interface, and mutt can in principle have several of these, for different notification services. The biff command associates a "signal name" with a pattern, title, and message. Examples: biff myNewMail "~A" "Hey, new mail!" "You got mail from %f" biff bossMail "~f boss" "Mail from the boss" "The boss wrote: %s" biff replyMail "~p ~s re:" "Reply from %f" "%f replied to your message: %s" That is, you can configure any number of notifications based on different pattern selections. Each notification gets a user-defined name. The second patch implements dbus support, and then adds the call-out function so that mutt can issue notification events as defined by "biff" to dbus. (This was initially posted with no comment in 2012: https://www.mail-archive.com/[email protected]/msg07862.html . Layering it on top of biff is a newer idea.) Your patch could be another notification alternative, also depending on the biff configuration above. In principle dbus could handle your notification needs as well, but I'm not keen to make all notifications rely on dbus support, so it's a compile-time option. Yours does not need to be optional. Assuming the biff stuff is interesting enough to commit, we can do this in either order: 1. we add your code here (mostly) as it is, and I'll do the integration work when I add mine. This comes with some user-facing disruption: anyone using your code right away (e.g. you) would need to adjust configuration a little. But on the plus side, if my patch is not sufficiently interesting, yours is still there. 2. we wait for a review and commit of my patch, then you rebase your patch onto that and resend. This is less disruptive but puts more work on you. I'm fine with either approach, I just want to make sure you get credit for and control over your work. :) My patches are not quite ready to send but unless this whole idea is roundly despised I will send soon for deeper comment. -- David Champion • [email protected]
