From: Jani Nikula <jani@nikula.org>
To: David Bremner <david@tethera.net>,
 Mark Walters <markwalters1009@gmail.com>,	notmuch@notmuchmail.org
Subject: Re: Xapian-quoting based batch-tagging.
In-Reply-To: <87txr9q763.fsf@zancas.localnet>
References: <1356464567-21779-1-git-send-email-david@tethera.net>
	<87ehid5h64.fsf@qmul.ac.uk> <87txr9q763.fsf@zancas.localnet>
User-Agent: Notmuch/0.14+235~gdaf492b (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Thu, 03 Jan 2013 20:41:28 +0100
Message-ID: <87mwwqgil3.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 26 Dec 2012, David Bremner <david@tethera.net> wrote:
> Mark Walters <markwalters1009@gmail.com> writes:
>
>> I am unclear about how this is going to deal with queries containing
>> newlines. For dump/restore I think this is not a problem (as Austin and
>> others have said), but for batch tagging I think it could be; for
>> example the query could be for a tag containing a newline.
>
> Yes, that's true, this patch series does not support queries with tags
> with embedded newlines. They can still be removed (and added) via either
> batch tagging or the command line. We could just live with this, or

I think we should just live with it. It's a bunch of code with some UI
wrinkles for a marginal feature.

BR,
Jani.


>
> - The current syntax allows for detecting options at the start of the
>   line; perhaps a future fix would be to have the batch tagging and
>   command line tagging accept an optionally hex encoded query, something
>   like:
>
>         --hex +found%20it -- tag:%22stupid%0Atag%22
>
> - Alternatively, we could add hex decoding on top of xapian quoting for
>   queries. One UI downside is that people have to remember that % are
>   special.
>
>      +found%25it -- tag:lost%25it
>
>   Another is that quoting is still (surprisingly) necessary for encoded
>   spaces
>   
>      +found%20it -- tag:"lost%20it"
>  
>   Introducing yet another escape format, e.g. "\n" would require more
>   code, and not really much benefit afaict versus re-using hex-encoding.
>   Offhand I don't see how to avoid this without some level of query
>   pre-processing a-la
>   
>         id:1356313183-9266-1-git-send-email-david@tethera.net
>
> d
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch