RegExp with lookbehind

[Ron Francis]

Regarding the search facility, is there any chance of using a version of RegExp that supports lookbehind?
For example, something like (?<!foo) would not match anything with foo as a prefix.
Not having lookbehind makes it very difficult to filter filenames in some cases.

[Ron Francis]

No-one else interested in this?
As an example, searching for 'fence' not preceded by 'boy', so that 'boy on a fence' was filtered out, seems to be impossible.
If I don't understand something, or there is a workaround, I'd love to hear it.

[xnview]

currently no way to change the regexp behaviour

[danjcla]

No-one else interested in this?

Perhaps I can interest you in expressing interest for the second interesting suggestion at http://newsgroup.xnview.com/viewtopic.php?f=60&t=31302 which would make absolutely any search both possible and pretty easy for somewhat more technical users (e.g. the kind of people who would use regular expressions :-)

As an example, searching for 'fence' not preceded by 'boy', so that 'boy on a fence' was filtered out, seems to be impossible.
If I don't understand something, or there is a workaround, I'd love to hear it.

A workaround for queries that only reference XnView database info would be to get the initial set of files you want to work with via an SQL query, write that to a file, manipulate that file with some language that supports lookbehind regexps (perl/python/etc), and then use that file and some library or command-line utility to write a keyword for that search to the file's metadata (or to XnView's SQLite database if you are brave/foolhardy), and then search for that metadata within XnView to get the result set displayed.

If you want to also include in-file metadata in your query, you'd have to either have XnView set up to sync file metadata into its database (and verify that actually works for you), or write your own stuff that queries the file using some command-line tool and then does something, yada yada yada...

[danjcla]

Just thought of an even uglier last bit of the workaround, but it means you wouldn't have to modify the original photo with new metadata for each search it is included in - on mac and linux, you could make symbolic link farms, and then you could just view your result set as a normal filesystem folder. That should also actually be significantly faster, and give you instant "saved searches" for free, although actually in both cases you have to remember it'd be a snapshot, staying at the point in time you executed the search process.