Wildcard syntax matching

[AndrewOwenMartin]

I'm trying to make a pattern which makes any following lines a specific syntax depending on the pattern. A bit like how you can define the syntax of some code in GitHub markdown with ```python or ```javascript.

I can define many lines in my after/syntax file, e.g.

call SyntaxRange#Include('^<<python>>$', '^@$', 'python')
call SyntaxRange#Include('^<<c>>$', '^@$', 'c')
call SyntaxRange#Include('^<<vim>>$', '^@$', 'vim')

but I was wondering if I could do something like regex group capture e.g.

call SyntaxRange#Include('^<<\(\w\)>>$', '^@$', '\1')

Where \(\w\+\) captures something like vim and '\1' would get substituted for vim.

The vim docs mention "External matches", where you can capture something in start= and use it in end=. E.g.

:call SyntaxRange#IncludeEx('matchgroup=Constant start="^<<\z(\w\+\)>>$" end="^@\z1$"', 'python')

This means I can start a python block with anything e.g. <<foobar>> and then I have to end it with @foobar. But the third argument can't accept the wildcard \z1.

[inkarkat]

The third argument of SyntaxRange#Include() is the filetype, and is used by the plugin itself, not the underlying :syntax region command, so the \z1 external match reference you've mentioned doesn't work there.

You could use a loop if you need to support many filetypes:

for filetype in ['python', 'c', 'vim`']
    call SyntaxRange#Include(printf('^<<%s>>$', filetype), '^@$', filetype)
endfor

You could even query all filetypes that Vim supports instead of supplying a hard-coded list; though this might turn out to be too slow, and maybe the buffer needs to be inspected on actual used markers instead (which also takes time, but only once on buffer loading). The downside of that is newly added filetypes aren't recognized until the buffer is reloaded.

---

Also, typically (for example in GitHub markdown) the syntax names don't correspond 100% to Vim's filetypes, so some sort of mapping is necessary. With all those complications and the fact that most users only ever encounter a handful of filetypes, the manual definition still seems to be the best approach.

[AndrewOwenMartin]

Thanks so much for this. It helps me work out where I might go with this (I'm writing a literate programming library for my own joy) and gives me comfort in using the manual approach for the foreseeable.