Monday, April 26, 2010

Re: Context aware syntax?

On Apr 20, 5:46 am, Ovid <publiustemp-...@yahoo.com> wrote:
> I'm using a simple syntax file to highlight the TAP protocol (http://en.wikipedia.org/wiki/Test_Anything_Protocol).  The syntax can be found here:
>    http://github.com/threebytesfull/perltest/blob/master/syntax/TAPVerbo...
>
> There are two problems I would like to address.  First, TAP is essentially a series of "ok/not ok" lines followed by an optional sequential number:
>
>   1..5
>   ok 1 - this is a test
>   not ok 2
>   ok - another test # number optional, assumed as 3
>   ok
>   ok 5 # number MUST be 5 because this is fifth result
>
> Is there anyway to highlight a syntax error if the fifth "ok/not ok" line should have the number 5, but actually has a different number?

It would be easiest if it were built into the syntax definition. I do
not have time to figure out how the current rules work and how to
modify them, but here are some suggestions.

First, I think it is a bad practice to set user-preference type
options in the syntax file:
set foldminlines=5
set foldcolumn=2
set foldenable
set foldmethod=syntax

ESPECIALLY since the script uses :set instead of :setlocal

For actually doing what you want in syntax, I know of no way to get it
working in general. However, you can set some reasonable limit on the
number of test cases (say, 200).

I would use the nextgroup keyword (:help :syn-nextgroup) combined with
the contained keyword (:help :syn-contained) to make sure that test
case 2 only follows test case 1, test case 3 only follows test case 2,
etc. I would then use a catch-all rule to match anything not matched
with these rules with an error highlight. For easier implementation,
you could execute a loop in the syntax file to build multiple syntax
rules of this sort that differ only in the subscript of the test
number.

Note, this will NOT highlight as an error, if you provide extra test
cases not contained in the range given in the first line.

>
> In a related case, we're trying to create "nested TAP". With this, you might see the following:
>
>   1..3
>   ok 1
>       1..2
>       ok 1
>       ok 2
>   ok 2
>   ok 3
>
> If the TAP is nested to the correct level (four spaces every time a new stream is embedded), is should be an error.  Again, is there any way for vim to be aware of this when highlighting?
>

First, to make nesting properly work with the error highlight for out-
of-sequence stuff above, you'll need to create a syntax region to
match an entire set of test cases, starting with 1\.\.\d\+ and ending
with the line above the same, or end of file. This will need to
contain the syntax rule for the first test case using the contains
keyword (:help :syn-contains), which in turn will need to contain the
region for test group to allow nesting. You may need to mess with the
keepend and extend keywords to get it working correctly (:help :syn-
keepend, :help :syn-extend).

With the above addition, you can probably even pick up error
highlighting of test case numbers that are too large, by ending the
containing region on the line with the test case matching the maximum
test case number.

Now, if I understand correctly, you want to highlight lines that are
not indented properly. This will probably prove much more difficult.
It may be possible in a similar way, by defining a reasonable limit
for the amount of nesting, say 10 levels. You could then define 10
different matches for your entire set of rules above, one for each
possible nested level. This part would be much harder I think, and
make everything much slower. It may be easier/more efficient able to
construct something to match as an error when the indent of a given
test case does not match the indent of the containing region starting
with 1..[num cases].

--
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

Subscription settings: http://groups.google.com/group/vim_use/subscribe?hl=en

No comments: