> > Yes, of course you're right. Indeed, this is the way I interpreted it > > when I read it, and it was just the hint I needed to make finding and > > fixing the problem super-fast. So thanks. :) > > Could this kind of fix be applied to the `(U(1) OR SL(2,Z))' failed > regression test case as well, to kill the two tasks in one go? Kind of > like if you see `(...)' where `...' does not contain spaces, replace it > by `__OPENPAREN__...__CLOSEPAREN__' before proceeding to the regular > paren parsing, then parse into units as usual, then replace underscore > variables back. Kind of what I had done in the past to temporary > replace spaces by __SPACE__ in the main parser in order to work around > quoted expressions, see `grep __SPACE__ search_engine.py'. It would be > nice to fix this failed regression test case too, and it looks so > similar to the hep-th case :) but I had not looked at the problem if it > is indeed that.
Well, this is actually exactly what I'm doing in search_engine_query_parser, but search_engine isn't calling search_engine_query_parser to parse the query for the U(1) case; it's special-cased to handle it internally. This used to not get tickled because the nested parentheses thing would blow up before it became a problem. I'm inclined to think that all the parsing should happen in search_engine_query_parser, but when I (very quickly in a very hackish way) made that happen a lot of regression tests started failing, so I stopped that experiment until I had more time to understand what-all is going on in search_engine. So to sum up: Yes, probably exactly so. But I haven't yet taken the time to understand where or how. Joe
