... From: Bram Moolenaar To: Stahlman Family Cc: Sent: Saturday, December 31, 2005 12:55 PM
Message 1 of 3
, Dec 31 12:41 PM
----- Original Message -----
From: "Bram Moolenaar" <Bram@...>
To: "Stahlman Family" <brettstahlman@...>
Sent: Saturday, December 31, 2005 12:55 PM
Subject: Re: Problem using rs=e+<d> with a syntax start pattern anchored at
end of line - bug or idosyncrasy?
> Brett Stahlman wrote:
>> To simplify things, I have taken an example from the syntax help, which
>> similar to the scenario in which I encountered problems:
>> <<< Example from "syntax.txt" >>>
>> :syn region Exa matchgroup=Foo start="foo"hs=s+2,rs=e+2 matchgroup=Bar
>> mmmmmmmmmmm match
>> ssrrrreee highlight start/region/end ("Foo", "Exa" and "Bar")
>> As an aside, note that region Exa actually appears to begin with the "r"
>> string, not the "t" as suggested in the help. (Is the offset measured
>> the char position after the match, or the last char that was part of the
>> match? The help suggests the latter, the results I see suggest the
> That's right, the highlight string should be "sssrrreee".
>> Anyways, if I modify the example slightly by requiring "foo" to occur at
>> end of a line...
>> <<< Slightly modified example >>>
>> :syn region Exa matchgroup=Foo start="foo$"hs=s+2,rs=e+2 matchgroup=Bar
>> Note: All I have done is insert a '$' after "foo" and an actual newline
>> after foo in the buffer text. I would expect that things would be pretty
>> much as before; i.e., the region would begin on either the 'r' or 't' of
>> string (or perhaps even the 's' if the newline is counted as part of the
>> offset). However, what actually happens is that the body of the region
>> disappears, with the matchgroup Foo slurping up everything to the start
>> matchgroup Bar.
>> i.e., Foo extends from the final 'o' in "foo" to the 'n' in "string"; Bar
>> begins with the 'g' at the end of "string", as expected. What happened to
>> Exa? And how can any of the characters in string be part of the Foo
>> Is this a bug or an idiosyncrasy of some sort?
> Well, if you take it literally then the region starts after the end of
> "foo", but there is nothing there thus the region never starts. The
> match highlighting then continues, apparently.
I see what you're saying, but generally when you talk about text being after
other text in Vim, linebreaks are not significant. I just noticed the
passage in "syntax.txt" on "Multi-line patterns". Specifically...
"When using a start pattern with an offset, the start of the match is not
allowed to start in a following line. The highlighting can start in a
following line though."
In the above text, I would assume that "start of the match" corresponds to
'ms=' and "highlighting" to 'hs=', with 'rs=' left somewhat ambiguous
(although it would certainly be useful to allow a region to start on a
> However, the region does continue after "bar". You can see that if you
> add more text. Weird.
Yes. I hadn't even noticed that. That definitely couldn't be labeled an
> I think the region should start anyway after the
> line break, as if the line was longer.
I agree. At least, that would be the most intuitive behavior. The only
question would be how newlines affect the offset. Given that an offset is
measured from the character after the last character in a match, rs=e+1
would have the region beginning either with the first or second character on
the subsequent line, depending upon whether the newline is counted as a
character position. On the one hand, since a newline can't be highlighted,
it might make sense to ignore it when calculating character offsets. On the
other hand, there may be situations in which multiline regions are being
created solely for the purpose of containing other regions where it would be
most natural to have newlines treated like ordinary characters. I don't know
what is best here...
Your message has been successfully submitted and would be delivered to recipients shortly.
Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer.
We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.