From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 026226DE0260 for ; Mon, 1 Oct 2018 02:48:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[AWL=-0.147, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.211, SPF_NEUTRAL=0.652, UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mffUyceHiyA for ; Mon, 1 Oct 2018 02:48:50 -0700 (PDT) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by arlo.cworth.org (Postfix) with ESMTPS id E7D9F6DE025F for ; Mon, 1 Oct 2018 02:48:49 -0700 (PDT) Received: by mail-wr1-f68.google.com with SMTP id a13-v6so2449730wrt.5 for ; Mon, 01 Oct 2018 02:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dme-org.20150623.gappssmtp.com; s=20150623; h=to:subject:in-reply-to:references:from:date:message-id:mime-version; bh=nVq+Z14zSoMPnXGSxR8dxEFZ21ogsfyWqFvXxaapS4E=; b=bPFmIqC1Zeo6VjMupTa3lK06lbZtU7g99YfzL6lqz5jMgQGHt6lFRc3UJ8OKG0MR/L MT9IB7iPpkD0BtvF33PVvotxKylVAvCPPZel7e1UG6aWf/xiNJvR1uG6ZwlvnRKin8hb K7PU2Gaz+Sw1JhIL18GVf9fQG5ARPbT4oOqailtTxjnONJTcRjm9yXii5aqBFE+irpIC tuzkRxkwDnpYjubo3IDc5yAO5l7ryKhcgZounNINSLpjju6tnNv2MTh3ZP/r8RfS0DCJ fdM7bLFgze7qZKwSklmZqkPh748SpJBRnDqlUk7lR+EqcA+A8Nyg9C+OayeM1A22qaWc dTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:in-reply-to:references:from:date :message-id:mime-version; bh=nVq+Z14zSoMPnXGSxR8dxEFZ21ogsfyWqFvXxaapS4E=; b=NMA3A91+5Vgb/3FkNB/OIVOmbE5JlUOQCRIW+wohuhTtdrNkgedeN5i1O3CzyQygwC LMDf8uy7Odm92QzW8qcMnh8umTWvk5gDsWlcx2zx/qovD5RMEqHGVqfp/VT9GiwwqFLJ ZKLTLuakd0xl8tXz//Su1JDPStxpWTxLdATXi1OQxcR/msFCFYURXx9e4mUQGaMmpwpD tvbj543Fmph7u31HvYopQecw2XTXNFLDqTRBQ0FTiOrO2yBB9DDBy6VBjB6oQmMwTY/6 7ZUAzX2tSnkMg8aiEGm2pBrggAaDwK3fWwoSc0Jibr/kHQAhKlyVMgTnRSehB6exjvQr 1mtw== X-Gm-Message-State: ABuFfog6QsYuqo1suKlrfSQTpWCuwaEF5+FUJoHFOB9i2j5fwG6xgQav f+xXnC6PtNy+7/0bPSDx0Dcb/g== X-Google-Smtp-Source: ACcGV61i2l3NM8iC1y0ReOZMsyMshWPMwI9xe9vREBaV7/vrbYz3PN3re27TdHt7r6pQg/nbj+vaVQ== X-Received: by 2002:a5d:46d2:: with SMTP id g18-v6mr1225046wrs.185.1538387327932; Mon, 01 Oct 2018 02:48:47 -0700 (PDT) Received: from disaster-area.hh.sledj.net (disaster-area.hh.sledj.net. [81.149.164.25]) by smtp.gmail.com with ESMTPSA id p64-v6sm12797817wrc.97.2018.10.01.02.48.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 02:48:46 -0700 (PDT) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id 32f32b8f; Mon, 1 Oct 2018 09:48:46 +0000 (UTC) To: David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH v2 1/4] emacs: Asynchronous retrieval of GPG keys In-Reply-To: <87bm8fn4ax.fsf@tethera.net> References: <20180907112920.3130-1-dme@dme.org> <20180907112920.3130-2-dme@dme.org> <87bm8fn4ax.fsf@tethera.net> X-HGTTG: gag-halfrunt From: David Edmondson Date: Mon, 01 Oct 2018 10:48:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 09:48:51 -0000 On Saturday, 2018-09-29 at 22:48:38 -03, David Bremner wrote: > David Edmondson 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.