On Saturday, 2018-09-29 at 22:48:38 -03, David Bremner wrote: > David Edmondson <dme@dme.org> writes: > >> +(defun notmuch-crypto--async-key-sentinel (process event) >> + "When the user asks for a GPG key to be retrieved >> +asynchronously, handle completion of that task." >> + (let ((status (process-status process)) >> + (exit-status (process-exit-status process)) >> + (keyid (process-get process :gpg-key-id))) >> + (when (memq status '(exit signal)) >> + (message "Getting the GPG key %s asynchronously...%s." >> + keyid >> + (if (= exit-status 0) >> + "completed" >> + "failed")) >> + ;; If the original buffer is still alive and point didn't move >> + ;; (i.e. the user didn't move on or away), refresh the buffer to >> + ;; show the updated signature status. > > This is a pretty conservative condition for the update. I can live with > the tradeoff to get non-blocking updates, but I think it will surprise > people used to the button updating to have it not do so when they move > the point away. So I guess this behavior should be documented in a more > user visible way? The condition is conservative because the refresh redraws the whole buffer. If it just updated the button directly (which I've been fiddling with, but don't have working well yet) then we might relax the condition. Where would we document the behaviour? dme. -- He caught a fleeting glimpse of a man, moving uphill pursued by a bus. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch