Eric Wong writes: > I'm thinking these shouldn't include angle brackets: > > "m": "<[email protected]>", > "refs": ["<[email protected]>"], > > Using angle brackets on the command-line requires quoting to > disambiguate against redirects, so it's a pain. Leaving the > brackets in still works because of how Xapian's query parser > works, not because of anything we do on our end.
I think it'd be nice to drop the brackets from a noise perspective too. Also, does m: work with brackets? Trying it out with a recent message ID: $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \ '[email protected]' {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...} $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \ m:'[email protected]' {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...} $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \ '<[email protected]>' {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...} $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \ m:'<[email protected]>' # no results > Since the actual headers are "Message-ID" and "References", (and > not "m" or "refs"), I think it's clear that we don't have to > match the raw mail contents exactly. We RFC 2047 decode > "f|t|c|s" fields anyways instead of showing the raw values, > so more precedence for leaving out <>. Fwiw I don't think leaving out the brackets would be a source of confusion.
