Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6B712431FB6 for ; Mon, 2 Apr 2012 12:46:24 -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 mroopGnhPzuG for ; Mon, 2 Apr 2012 12:46:23 -0700 (PDT) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 3F102431FAE for ; Mon, 2 Apr 2012 12:46:23 -0700 (PDT) Received: by bkwj4 with SMTP id j4so2953743bkw.26 for ; Mon, 02 Apr 2012 12:46:20 -0700 (PDT) X-Google-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 :content-type:x-gm-message-state; bh=AyRYYx2Cgkukv0pWk4nXMeBpndgFXRUVMBBnEcfIzRk=; b=Cw6uY2AMSPM0/lrnPMJkxsyAfByxFBNFMDEe30qQI3EGP53ZHXVFXSzzzDjJOBdHBs CEJSHu1qplWZ0d9/A1UUMiNbMhDcwbXYtVdVcYe+F8xLSw7eDXKK1z544F2SxcRdxfep gwzP2mQFwMlaNAiVeX9cVCg0mYX560lVFuH5YG4dm7kPaVIX658wUogxKJukYBwRzYJQ m5lvXwCF96T3lGJVOY+pYjcnzhw0+Y+Y3NGEkYhtkEDuc21SjptAtSLnOzzMa1kq71jk 1YB/2fKc1e5LEcK5PuKWrnVJXqrkWAtFSR7rU4M32iceiLnx3k5utJ4DnHmvC5s+EcDF qluA== Received: by 10.205.122.77 with SMTP id gf13mr4432300bkc.15.1333395980070; Mon, 02 Apr 2012 12:46:20 -0700 (PDT) Received: from localhost (dsl-hkibrasgw4-fe4fdc00-105.dhcp.inet.fi. [80.220.79.105]) by mx.google.com with ESMTPS id s16sm40849495bkt.3.2012.04.02.12.46.17 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 12:46:18 -0700 (PDT) From: Jani Nikula To: Jameson Graef Rollins , notmuch@notmuchmail.org Subject: Re: [PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag" In-Reply-To: <87wr5y3ttw.fsf@servo.finestructure.net> References: <87wr5y3ttw.fsf@servo.finestructure.net>User-Agent: Notmuch/0.12+81~g839a805 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Mon, 02 Apr 2012 22:46:15 +0300 Message-ID: <87bon9apdk.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQkJ2UAQJhZZJTKxtojgBia6aVhDDp+MNpGS/+SsMlYO56U5nmwTHjFxiGxbXC6JcEdGa3nV 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: Mon, 02 Apr 2012 19:46:24 -0000 Jameson Graef Rollins writes: > On Sat, Mar 31 2012, Jani Nikula wrote: >> Add support for batch tagging operations through stdin to "notmuch >> tag". This can be enabled with the new --stdin command line option to >> "notmuch new". The input must consist of lines of the format: >> >> T +|- [...] [--] > > Hey, Jani. I can understand why you're going for this form, since it > mimics the command line arguments for tag and you want to be able to tag > for arbitrary searches, but I must say that I find it unappealing that > this functionality is *so* similar to that of notmuch restore, but the > file format is totally different. Can't we unify all of this in a > better way? Hi Jameson - Thanks for your comments. The intent is to converge notmuch tag and restore file formats, and reuse the code between them. The above is the proposed format for both, but I see that I failed to mention the future plans. This actually started from David's dump/restore rework [1]. I wanted to have batch tagging, and realized his proposed format wouldn't work for that. There was some discussion about this on IRC, and we settled on the above format as a starting point. And now would be the time to comment on the format, if you have any issues with it! ;) > This patch series seems to beg that we actually just unify the tag and > restore functions in to one thing. They're really just doing the same > thing. If we extended restore to accept a search-term instead of a > message id they would in fact be identical. > > The more I think about it the more it makes sense to me that we just > merge tag and restore, and extend the input file format to be able to > accept search terms. It just doesn't make sense to have these two > interfaces that do basically the exact same thing but in a slightly > divergent way. I totally agree on this goal. The dump/restore follow-up part is a work-in-progress in my local tree. At least initially, the format would be the same for tag and restore, but with the following subtle differences: 1) notmuch restore will only accept an id:message-id style query to be able to warn about messages present in the dump file but missing in the database. This is because dump/restore is primarily a backup/restore style operation. 2) Partly because of the above, and partly because of notmuch restore --accumulate vs. not, the query/tagging optimizations will have to be different. The rough idea is that both notmuch tag and restore would use the same file parsing (tag_file() introduced in this series), but notmuch tag would use tag_query() in notmuch-tag.c for tagging, and notmuch restore would use tag_message() in notmuch-restore.c for tagging. > and btw, according to comments in the code 'T' is supposed to stand for > the action, "tag" in this case. What other actions do you imagine? This was actually David's idea. It allows extensibility in the format. Thanks again for your interest, and sorry about not opening up the future plans up front. BR, Jani. [1] id:"1324214111-32079-1-git-send-email-david@tethera.net"