From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 1B914431FAF for ; Fri, 5 Sep 2014 09:06:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7BcX0n5s7+8 for ; Fri, 5 Sep 2014 09:06:17 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 46EFB431FB6 for ; Fri, 5 Sep 2014 09:06:17 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id z12so11780786wgg.6 for ; Fri, 05 Sep 2014 09:06:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:in-reply-to:references:user-agent :from:date:message-id:mime-version:content-type; bh=hErSz26R6eGDkX6aAJF4DmUCm2ufy2ns21KH+lxonDM=; b=mUZFfsl+nr7uRga3CGe/kvkTfJPEStjWNxi0vpRaAUI+5YzwncHV9KXPTinLjg5IUl DazY2s6BkuJiD7u2T2XOS9oZkaG0aLYO5253aXxw2eMp7Zeq/4+dpvu0iNYdedhP/26g N9w0QuV5aObnSV/ezfiTxJoJual/D8GUgD/bVpP+dPO9hCNHuFyvcdSjPjyfinH/qDPq iEu2lKNhU4jNWh5ulSp0PbCbBY8r+au+uLa8Vxyz/XuXLoqx3OWBftXWnfwNnxGeGggs Fr04Qc6vcwrqH5Vrs9Z0fRPMfB+tz/8ZbPL4Ev1I9co2ebXR50eqOSGBUJWEcrzIDFx5 zzvA== X-Gm-Message-State: ALoCoQmDSNquwT/WZzxQ18GPVzNZ7L+GAe6gi/RtHkO8myrsK+nJpGqJ+YAF9yftgOWGlUlUq4mL X-Received: by 10.194.187.241 with SMTP id fv17mr16262486wjc.13.1409933174699; Fri, 05 Sep 2014 09:06:14 -0700 (PDT) Received: from localhost ([2a01:348:1a2:1:4559:6492:4175:6b36]) by mx.google.com with ESMTPSA id m9sm1851363wjz.35.2014.09.05.09.06.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Sep 2014 09:06:14 -0700 (PDT) To: Mark Walters , notmuch@notmuchmail.org Subject: Re: [PATCH v1 0/3] Address completion entirely in elisp. In-Reply-To: <87k35igk5n.fsf@qmul.ac.uk> References: <1409921969-65129-1-git-send-email-dme@dme.org> <87k35igk5n.fsf@qmul.ac.uk> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin) From: David Edmondson Date: Fri, 05 Sep 2014 17:06:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 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: Fri, 05 Sep 2014 16:06:23 -0000 On Fri, Sep 05 2014, Mark Walters wrote: > On Fri, 05 Sep 2014, David Edmondson wrote: >> Address completion entirely in elisp. >> >> I grew frustrated with having to use an external command to provide >> address completion, as they all had annoyances (up front scanning, >> requiring python bindings, etc.). This is an attempt to provide >> something similar to jkr's notmuch-addresses.py (which I was >> previously using) entirely in elisp, relying only on the `notmuch' >> command. > > Just a few quick comments: the first is relevant to others trying this > patch. > > 1) You seem to be missing a (require 'std11) somewhere. I did this via M-: > and then it ran fine. My apologies. Will fix (and a compiler warning at the same time). > 2) It is not quick on a spinning rust disk. This may not be relevant as > the delay is probably notmuch so would also be the case if I were using > notmuch-addresses.py (i normally just use a trivial script that parses > my .mailrc) It's not always as fast as I would like on SSD either :-) The mechanism is very similar to the equivalent Python program, so I think that it's probably about the same. > 3) Have you tried > id:1407771091-12651-1-git-send-email-sojkam1@fel.cvut.cz and do you have > any comments on the comparison? No, I will dig it out and look. > 4) Finally, I wonder if we would be worth approaching the backend > notmuch use slightly differently: if we added a > notmuch_messages_collect_from function which was very similar to > notmuch_messages_collect_tags, and added a corresponding --output=from > to notmuch search then you would get the information you need very > quickly. I think it might be a lot faster as I think the from header is > stored in the database but some other headers are not, so that the > current method the show --body=false needs to look at the actually > messages Extending notmuch to help with this was next on my list of things to do. At the moment I just needed a solution that worked. > I should emphasise that none of the above means I am opposed to the > patch: having respectable built in address-completion support would be > very nice. Cool, thanks!