> Would this even be possible? I can imagine a whole lot of packages breaking if the regexp syntax changed, and changing it just for the user input in interactive functions looks a bit sketchy.
We could just add a special tag at the beginning of a regexp to indicate that it's a pcre regexp; something like this maybe? (re-search-forward "\\(?pcre:\\)…[pcre regexp goes here]…"). This form is currently a syntax error, so there would be no ambiguity, and we could define a (pcre …) macro so that you could write (re-search-forward (pcre "…[pcre regexp goes here]…")) instead. Alternatively, we could use an explicit tag, something like (re-search-forward (cons 'pcre "…[pcre regexp goes here]…")).
For interactive functions, I imagine you'd have a defcustom with a preferred regexp dialect.
I like where this is going, that and Eli's suggestion of a special text property we have plenty of ways to implement it where it'd play nice with the existing code.
So far 3 proposals:
- Regexps are always strings, with "\\(?pcre:\\)" as part of the regexp
- when the string is displayed you need to scan the beginning to see it is a PCRE regex
- no separation between the regexp and it's kind
- Regexps are strings (emacs regexps) or conses with their kind as symbol with the first argument
- when the argument is displayed you see immediatly wether it's an emacs regexp or one using another engine
- the regexp is clearly separated from it's kind, probably faciliting convertions
- seems more "open", in the sense we can easily imagine new types ('emacs, 'pcre', 'rx, 'sed, 'vim-verymagic, etc)
- Special text property on the string
- Not immediatly visible that it is a PCRE regexp
- Harder to manipulate?
Given this I'm in favor of the 2nd option, but maybe I missed some points.
Philippe