On 12 June 2015 at 13:59, Duncan <1i5t5.dun...@cox.net> wrote: > [...] It may be that the code deliberately > shuts off parsing in this case, and "forgets" to turn it back on again, > thus leaving the process stuck until toggled.
I reckon this is probably the right answer. I've found the code where Pan attempts to make sense of the regex entered into the search box [text-match.cc:202], and it seems to have three states: NEED_COMPILE - a regex is entered & needs looking at COMPILED - a looked at regex is successfully filtered ERR - a looked at regex seems to be invalid NEED_COMPILE turns into COMPILED nicely enough and back when finished. But when ERR happens, nothing resets it to NEED_COMPILE and it won't check again until toggled. As there's only 0.5 seconds to enter a regex, even a valid but partially typed one will end up in an ERR state. I created a quick patch that resets ERR back into NEED_COMPILE, and in my quick testing seems to work. The only gotcha is it spams up the log a bit with "Can't use regular expression" type error messages until valid, but this happens the first time an invalid regex is entered anyway. Patch attached for the brave! :-)
text-match.cc.patch
Description: Binary data
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
