Match pages by regexp not just by glob

[spanezz]

(From a conversation wtih @DonKult)

I have a silly local patch adding it as an additional parameter as globs
sometimes aren't enough, but somehow I think it should be possible to
annotate site_pages(path= somehow that I am passing a regex rather than
a fnmatch which is then translated to a regex.

I can think of two ways:

1. if path is a regexp object, use it directly. Export function to the
   jinja2 templates that is an alias to re.compile. It could be called
   'regex', 're', or 'R'.
2. add another argument path_re which, if present, overrides path and
   is used as a regexp

As I tried to explain I did 2., but I don't like it, so yeah, 1. would
be nice. I would recommend a not too generic/short alias though.

Ok. Let's try and accept a regexp object for path, and export a regex() function to the templates.

[spanezz]

Another option, is to decide that if the path argument starts with ^ or ends with $, then it's a regexp. I recall seeing some other software do it, although I don't recall which one.

One can still provide the regex() function to the templates, for explicit marking.

[DonKult]

On Sun, Dec 15, 2019 at 04:37:01AM -0800, Enrico Zini wrote: […] if the `path` argument starts with `^` or ends with `$`, then it's a regexp. I recall seeing some other software do it […]

*cough* apt *cough* Sort of at least: on the commandline it is more accepting (just needs to look roughly like a regex to be tried as such – would personally prefer if it would only act on ^<regex>$ …) while in apt_preferences it assumes regexes are wrapped in /<regex>/ – but in staticsite / is a normal and usual character so better not go there. Long story short, would work & would have been my alternative suggestion if I hadn't forgotten about it at the time I wrote the reply.

[spanezz]

Aah, right! (I really couldn't remember that apt did it!) So from your experience not only it's a viable option, but it didn't have particular downsides so far. I think we have a winner.