Hello Vlad,
> Hi Boris,
> your method does work when I try it like this:
>
> :syntax match ARecord_RecordType "^A" nextgroup=ARecord_RecordCount
> :syntax match ARecord_RecordCount ".\{9}"
> nextgroup=ARecord_OriginatorID contained
> :syntax match ARecord_OriginatorID ".\{10}" contained
>
> :highlight ARecord_RecordType ctermfg=blue guifg=blue
> :highlight ARecord_RecordCount ctermfg=red guifg=red
> :highlight ARecord_OriginatorID ctermfg=yellow guifg=yellow
>
>
> It is not obvious to me why this should be (much) faster than the
> method with CONTAINS. That needs to be tested by profiling.
I tried to show a good way to link highlight groups to one, but
failed. In any way, my reasoning is that
when you have this code:
> syntax match ARecord_RecordType /^A/ contains=ALL
> syntax match ARecord_RecordCount /^A.\{9}/ contains=ALL
> syntax match ARecord_RecordOriginatorID /^A.\{19}/ contains=ALL
It checks all patterns one by one: the first pattern does match, then
the second one matches and finally the third does match. Nothing
matches anymore so the last pattern is used. Then again it has to
start all over again from "^A" because the third pattern contains all
patterns so it tries first and second once again. I don't know how
it's implemented and really hope the implementation is *much* smarter
that I described now. Maybe implementation uses theory of finite
automata, FIRST and LAST sets and other good optimization stuff... but
some 7th sense suggests me that when only one pattern (which doesn't
contain anything) matches and it immediatelly tells what is the next
pattern that matches too (and doesn't contain unnesesary patterns
inside) and finally it tells vim the third pattern that matches
flawlessly and so on. This way all vim must do is just to consume
input chars.
Regards,
Boris
--
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
