#131: Correct parentheses support in in search parsing
------------------------+---------------------------------------------------
  Reporter:  jblayloc   |       Owner:  jblayloc                       
      Type:  defect     |      Status:  assigned                       
  Priority:  critical   |   Milestone:                                 
 Component:  WebSearch  |     Version:                                 
Resolution:             |    Keywords:  INSPIRE Invenio Syntax News Oct
------------------------+---------------------------------------------------

Comment (by simko):

 WRT `re_pattern_parens` regexp match, this was introduced so that query
 like `(...)` gets treated by the parenthesized parser only when there is
 an empty space inside `...`, i.e. only when we have a chance of having a
 Boolean expression to process.  Otherwise we consider stuff between
 brackets as a word, basically.  So `U(1)` would not get processed since
 not matched by this regexp, but `(ellis OR kaon)` would get processed,
 which is mostly what we want.

 Now that we support nested parens, I think this regexp should be changed
 so that parenthesized parser will get invoked if `...` contains either en
 empty space or another paren (=having a nested paren situation).

 Note that the role of this regexp is basically to save the search
 processing time, so that the supposedly slower parenthesized parser would
 get invoked only when necessary.

 Note also that cases like `(U(1))` are touched by this regexp, but not the
 cases I mentioned above like `(ellis (NOT muon))` that would get
 dispatched to the parenthesized parser, but that behaved differently in
 master and in your branch.  (I have not yet looked at your updated branch
 how it behaves now, these are just comments to your textual musings.)  It
 is mostly for these cases that we have to ensure the sane behaviour in
 case of no hits found, in case they are hidden inside some complex `foo
 AND bar (NOT baz (fuux OR quux)) OR (xyzzy AND (NOT zyxxy))` sub-
 expression. So while the regexp is a real issue, it is a kind of parallel
 one. I guess we should be able to fix this parallel issue relatively
 easily by altering the regexp as mentioned above.

-- 
Ticket URL: <http://invenio-software.org/ticket/131#comment:22>
Invenio <http://invenio-software.org>

Reply via email to