Re: [PATCH] Add wl-biff-new-mail-functions hook to wl-biff-notify

On Fri, 19 Aug 2016 11:52:39 +0200,
Pascal Haakmat wrote:
> 
> On Sat, 30 Jul 2016 06:18:45 +0200,
> Kazuhiro Ito wrote:
> 
> > > The hooks are only called when the state changes:
> > > `wl-biff-notify-hook' gets called the first time new mail arrives, but
> > > then it is not called again until the state changes to "no new mail".
> > > 
> > > This makes it impossible to perform functions on the most recent
> > > arrival of new mail, for example updating the Summary buffer.
> > 
> > If you update summary, new mail should not be treated as new mail
> > anymore and the state should be change to "no new mail".  So, it would
> > seem that calling a function which updates summary and
> > wl-modeline-biff-status from wl-biff-notify-hook is enough for your
> > purpose.
> > 
> > (add-hook 'wl-biff-notify-hook
> > 	  FUNCTION-update-summary-and-wl-modeline-biff-status)
> 
> If new mail arrives and then the wl-biff-notify-hook changes the
> status to read "no new mail", then there is no indication that new
> mail has arrived when the users returns to Emacs after some time of
> absence.

This is an old mail but perhaps it was not clear. What I mean is that
wl-modeline-biff-status is set *after* the hooks are called, so the
status cannot be reset in the hooks:

(defsubst wl-biff-notify (new-mails notify-minibuf)
  (when (and (not wl-modeline-biff-status) (> new-mails 0))
    (run-hooks 'wl-biff-notify-hook))
  (when (and wl-modeline-biff-status (eq new-mails 0))
    (run-hooks 'wl-biff-unnotify-hook))
  (setq wl-modeline-biff-status (> new-mails 0))
  (force-mode-line-update t)
  (when notify-minibuf
    (cond ((zerop new-mails) (message "No mail."))
	  ((= 1 new-mails) (message "You have a new mail."))
	  (t (message "You have %d new mails." new-mails)))))

If my previous suggestion to add a wl-biff-new-mail-functions hook is
not acceptable, I would like to suggest moving the line:

  (setq wl-modeline-biff-status (> new-mails 0))

so it happens *before* calling the hooks. (although this still leaves
the problem that hooks called later don't see the correct status).

Thanks,
Pascal