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 E79A1431FB6 for ; Wed, 18 Apr 2012 11:58:51 -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 eg2ze3+b8JFk for ; Wed, 18 Apr 2012 11:58:47 -0700 (PDT) Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com [209.85.215.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 08A46431FAE for ; Wed, 18 Apr 2012 11:58:46 -0700 (PDT) Received: by lahc1 with SMTP id c1so6101134lah.26 for ; Wed, 18 Apr 2012 11:58:43 -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=e+B46seoLm4wBcc3ASWwsyrCg9gBRHxf45DpFX6+8UM=; b=DcJZiXdynR945DMnDnl9am+Z22eZGG3QzE3VHzMpZ8TSV/82CFWmM0d7I3H8HJArFk Zb1BAJhXagYIR8oE3ZARBvJXydDE6LpZxxfsOXD6MPzjOpAeWWcXlyx/hZ7DzftABPks XCHLd6Jrs36+sSaKR4wLlyxSFXJ4D+tZdIqXwjeUZXZQrRTke+WkIu3FWxB7TA37vB0C dBhvivCCQ+U+B2497FvVQzW182jbd9pyPjgBMhuMIqHLlm7hgNM5x0ng4nyMRPuxsvHB +lVCFmivrSDO/uSYI3U8MlCkBHVNymvD4kVX0t/pU7uK0R/0rh49lmfBSwGQiOiDMhAV 0glA== Received: by 10.112.48.202 with SMTP id o10mr1607538lbn.25.1334775523398; Wed, 18 Apr 2012 11:58:43 -0700 (PDT) Received: from localhost (dsl-hkibrasgw4-fe50dc00-68.dhcp.inet.fi. [80.220.80.68]) by mx.google.com with ESMTPS id mr15sm27124493lab.8.2012.04.18.11.58.40 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 11:58:41 -0700 (PDT) From: Jani Nikula To: David Bremner , Jameson Graef Rollins , notmuch@notmuchmail.org Subject: Re: [PATCH v2 0/6] batch tagging support: "notmuch tag --stdin" In-Reply-To: <87mx6dtd85.fsf@zancas.localnet> References: <87d37ays85.fsf@servo.finestructure.net> <87ty0mdnti.fsf@nikula.org> <87mx6dtd85.fsf@zancas.localnet>User-Agent: Notmuch/0.12+81~g839a805 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Wed, 18 Apr 2012 21:58:38 +0300 Message-ID: <87zka8989t.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQmmtqqJ8Pmm9VDXlVzP+ZTME7g8wahC5ojtePDbAkwVzDsB1FeJ7QFCyzThg4MOugH5sfdw 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: Wed, 18 Apr 2012 18:58:52 -0000 On Sun, 15 Apr 2012, David Bremner wrote: > Jani Nikula writes: > > >> I'm totally fine with modifying the proposed format (e.g. change "T" to >> "tag", make things compatible with a future general batch mode), but to >> be absolutely clear: I will not implement a general batch command >> mode. > > I was thinking about the best way of making the interface extensible, > and it might be better have a kind of modal interface, where some well > defined escape at the beginning of the line introduces a mode switch. > This has two apparent advantages: it avoids duplication of redundant > information at the beginning of each line, and for input to a subcommand > it could be optional. Does it not worry you that such a modal format isn't much fun to filter with regular command line tools? > something like > > * tag > +foo +bar msg.id@blah > +glub -glog other.msg.id@blog > > vs > > * restore > foo bar msg.id@blah > glub glog other.msg.id@blog > > where a hypothetical general batch interface could take those two files > concatenated together, and the "*" lines would be optional feeding to > tag and restore respectively. Restore currently has two modes of operation: with and without --accumulate option. How would you specify that *outside* the file, if the restore was done with the hypothetical general batch interface? And if there was such an interface, we shouldn't have a dedicated restore command for restoring such dump files, should we...? (It's useful to be able to use the same dump file with/without --accumulate. See e.g. [1].) > I guess the current proposal is to have the restore format and tag > format a bit closer > > * restore > +foo +bar msg.id@blah > +glub +glog other.msg.id@blog Something like that... though in my original idea the same dump file could be fed to either tag or restore. They would interpret the file using the same routine, but perform the tagging in slightly different ways (mainly to keep restore very strict as it's a backup/restore command). > This looks like it would be a 2% space increase for my tags. I guess I > could live with that. Another option would be to have the '+' be > optional for tag as well; I suppose then tags starting with + would be > ambiguous, which is probably a bad idea. I'd like to keep the new format unambiguous if at all possible. BR, Jani. [1] http://notmuchmail.org/howto/#index5h2