Loading ...
Sorry, an error occurred while loading the content.

Re: Context aware syntax?

Expand Messages
  • Ben Fritz
    ... 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
    Message 1 of 4 , Apr 26, 2010
    • 0 Attachment
      On Apr 20, 5:46 am, Ovid <publiustemp-...@...> 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
    Your message has been successfully submitted and would be delivered to recipients shortly.