Possible search parser bug?

DEVONthink Feedback
1

I’ve been working through (and carefully documenting) the rich search grammar in DT 3.0, and I came across one peculiarity that might be a bug, or just might be the way the search parser was designed to work.

Consider these three search strings (typed into the search box):

  1. tag:red size:12
  2. tag:“red size:12”
  3. tag:(red size:12)

Search #1 works as expected, and breaks into two prefix terms: ‘tag:red’ and ‘size:12’. No surprises here at all.

Search #2 is more interesting. It also breaks into two prefix terms, but they are a bit odd: ‘tag:"red’ and ‘size:12"’ (note that odd way the double quotes are split across the terms). I’m not entirely surprised by this, as there is no reason to assume the tag: prefix respects quoting.

Search #3 is also interesting. It yields only a single prefix term, with a tag search of ‘(red size:12)’. I am a bit surprised by this example, since there seems to be some kind of additional parsing going on related to the tag: that understands parens but not quoting.

I don’t know if this is all intended behavior, since there is very little documentation on the syntax for a “tag:” search prefix (its clearly special, since there is a shorthand for multiple tags using semi-colons, but other than that, I can find no other information on the syntax in the docs).

2

A tag can contain punctuation like parentheses, so I’d say the behavior on 3 is expected. You’ve clearly encapsulated the values in the parens.

Development can respond on this thread, but my question is why would you be using forms 2 and 3?

3

No reason to use them, but since tags can contain spaces I was trying to elicit the way the parser determines the end of one prefix and the start of the next, so that if I have a tag named ‘one two’ I know the correct way to enter it in the search. Essentially I was observing how different search texts are parsed (by watching how the resulting smart group was formed as I typed).

I think the issue was less about the parens per se, and more that the parens suppressed the recognition of the ‘size:’ prefix. As I said in my post, I wasn’t sure if this was intended or not.

4

The second and third syntax aren’t supported, therefore the results are probably not the expected one.