>
> On 2011-12-19 14:00, Timothy Madden wrote:
> > I find this everything-everyore-must-be-a-simple-RE design (for vim
> > syntax highlighting) insufficient to describe the syntax of a language.
> >
> > More high-level features like followed-by, containing and contained
> > regions should be present, but with the ability to add alternatives for
> > the following and previous regions, to search only in a region as one
> > would search in a file, to add names to any regions in order to search
> > or extract data from it later or in other places, or to be used in some
> > kind of group_exists('name') macro, and some other high-level
> > conditionals, using defines or flags declared when matching regions of
> > text like defining them from within the REs used for a match.
>
> For followed-by, containing, and contained, is that that just nextgroup
> and contained/contains/containedin?
>
> You can use nextgroup to do some of the stuff you want, but it's a bit of a
> hack (the keepend part of the hdBody line is important):
>
> unlet! b:current_syntax | syn include @awkSyntax syntax/awk.vim
> unlet! b:current_syntax | syn include @phpSyntax syntax/php.vim
>
> syn region hdBody matchgroup=shRedir contains=hdStart keepend
> \ start="<<-\?["']\?\z(.*\)['"]\?" end="\z1"
> syn match hdStart "\%(<<.*\n\)\@<=" contained nextgroup=@hdLang
>
> syn cluster hdLang contains=hdAwk,hdPhp
> syn region hdAwk start="\%(.*\n\)\{0,4}.*ft=awk" end="\#$" contained
contains=@awksyntax
> syn region hdPhp start="\%(.*\n\)\{0,4}.*ft=php" end="\#$" contained
contains=@phpSyntax
>
> From :help syntax, "Lexical highlighting might be a better name, but
> since everybody calls it syntax highlighting we'll stick with that."
>
> "Lexical highlighting" kind of defines the scope to simple regexes ;)
> There are also some advantages to keeping it in this scope, you might
> not always want a match to fail just because it's not technically
> valid.. syn-region is a good example of this, it's nice to have it
> highlight a string as a string even if you haven't typed the end quote
> yet. With a stricter parser you might get a "syntax error" and not have
> it match at all.
>
> That being said, I've wanted some higher-level features for the syntax
> matching too, and even more so for helping with indent expressions and
> omnicompleteion. I started writing a BNF like parser for vim a while
> back, but didn't get very far :(
I can not believe after days (and nights!) of un-encouraging attempts to turn
vim REs upside-down I got a working version !
It is based entirely on inline hints (in form of modeline comments) from the
user, but it overrides no syntax group from the provided
$VIMRUNTIME/syntax/sh.vim (it only adds new groups within shHereDoc).
The script author should provide the opening modeline (within the heredoc), the
closing modeline (just before the here-document delimiter line) and if necesary
a file-modeline (not heredoc-modeline) listing the language(s) being used in the
here-doc(s). Pretty manual, but it still provides nice highlighting for any ones
of lots of languages, and allows user to load more if needed, per-document.
I still have to extend the REs to add support for nested here-docs, and then I
hope to get a working, presentable, installable version and maybe upload it as a
vim 7.3 script ...
Thank you,
Timothy Madden
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment