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 E62146DE0962 for ; Wed, 19 Oct 2016 15:06:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.188, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.211, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 E1ooVUBfyPcw for ; Wed, 19 Oct 2016 15:06:47 -0700 (PDT) Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) by arlo.cworth.org (Postfix) with ESMTPS id 4F55C6DE0946 for ; Wed, 19 Oct 2016 15:06:47 -0700 (PDT) Received: by mail-pf0-f170.google.com with SMTP id 128so22899212pfz.0 for ; Wed, 19 Oct 2016 15:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=bo0dy/6hpjNMp6bvJuGu6fji0gVrkQfn8C2ghyAtXt8=; b=Tb67e17szvV1v2pQEvJmH83dHQBAooZ+XGi9WdJ+lJsXy0eifJbC7PKytVOVAfspS4 qvTmyVBpmb2gwxiC0d0sx1x4sJ5r11V5Kmp0iSlaEU8lmeAbE3cBZgI4SkR87ajvjZGH QRVP2WpYa6BJLZUt5wI5cDoSkzjmC9nmrHL0K4sUDlgFNuUnAAYHarcfi+894x3sqBW3 og2VMYtY7AKCkPRPbOzZTto4dzaLmuwwCZOT8xfOUxw4CED5cL6Wvy2HgdcyPg2z1VaH mJZVNuWQYNkvtkTqb1fY/VmuepGpH6NRKIWZ9AqQDTHj66HWLWJWr6Z1ECfaPbgWCyRX N1DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=bo0dy/6hpjNMp6bvJuGu6fji0gVrkQfn8C2ghyAtXt8=; b=K9tr5prHdCT8bSW31mSydPxJ26JceNetOPZSGGaH+hOXl/M4pkaxuumwUVzjvR/eaV uN4zXEGhtHyH6Jd8B+jfe6Jvp0dGGPAF5kpxc4ifEf1orEk/15rjlpXo5Q24Hd8T0kIW vvzpZV61BXbYmD2qntZVpr6busAVKMXI6go279KOSlpi4WGJTpyU7kbiPdGuJln1Apwn q6EqwDc5vlg0fEYtjhyFDcUSmUmCWhazJoQJUAz5T8pyuf91lh9zegS8We4eotw2zd6G 2edaAP8nhOvA0pNcODDW4CHmsvDyI8twE5jvzKlYHEE2ERrcGON6hp5I9YZHj4kKGL0t gkYA== X-Gm-Message-State: AA6/9RlZVoFuO+vmAmzxuoDXCEzqdrzDWftgalx4+L7lJipHU9FSKyrobyo3d9z/BF9tWq52 X-Received: by 10.98.4.6 with SMTP id 6mr15034983pfe.152.1476914804687; Wed, 19 Oct 2016 15:06:44 -0700 (PDT) Received: from marmstrong-linux.kir.corp.google.com ([2620:0:1008:11:e964:81b:22b:5b97]) by smtp.gmail.com with ESMTPSA id xv9sm66302462pab.36.2016.10.19.15.06.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 19 Oct 2016 15:06:44 -0700 (PDT) From: Matt Armstrong To: Mark Walters , notmuch@notmuchmail.org Subject: Re: [PATCH v3] Add notmuch-show--build-queries. In-Reply-To: <87vawu5chb.fsf@qmul.ac.uk> References: <1476387478-11506-1-git-send-email-marmstrong@google.com> <1476387478-11506-2-git-send-email-marmstrong@google.com> <87vawu5chb.fsf@qmul.ac.uk> Date: Wed, 19 Oct 2016 15:06:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 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: Wed, 19 Oct 2016 22:06:48 -0000 Mark Walters writes: >> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el [...] >> +(defun notmuch-show--build-queries () [...] > We may want to call this from tree-mode later, so I wonder whether > passing it notmuch-show-thread-id and notmuch-show-query-context as > arguments would make sense. I quite like the idea of this function being > self contained (ie not referencing global state variables). My instinct > is that referencing truly global variables like customise variables is > fine, but I am less keen on referencing buffer-local global variables. Done. Perhaps a useful rule of thumb is that functions referencing buffer-local vars should be interactive? I'm not sure that follows for all cases, but I certainly agree that global and buffer-local vars should probably not be referenced gratuitously, and pure functions are generally good. > However, some of this depends on what your later plans are. Calling what I have in mind "plans" may be a stretch. ;-) I'm not sure this function is useful for notmuch-tree as written. At minimum, I would expect a shared function to have a different name. But I think you're right that there is probably opportunity for code sharing, especially if notmuch grows more complex features with respect to searching vs. expanding messages in threads. Look for a v4 of this patch soon. I appreciate your review so far.