rubyFunction, rubyClass, and rubyModule no longer highlighted

[Tim Pope-2]

In the latest CVS version of syntax/ruby.vim, method, class, and
module declarations are no longer highlighted.  This seems to be due
to changing lines like

syn region rubyFunction matchgroup=rubyDefine start="\<def\s\+"    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline

to lines like

syn region rubyFunction matchgroup=rubyDefine start="\<def\(\s\+\)\@="    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline

Presumably, this was to allow def, etc to be highlighted before the
following space is input.  A much simpler pattern (and one that
actually works) is

syn region  rubyFunction matchgroup=rubyControl start="\<def\>\s*"    end="\ze\%(\s\|(\|;\|$\)" oneline

I will update the syntax file to use this third form if nobody objects.
I also have a few other minor changes that make the colors easier to
tweak (things like grouping regexps together as rubyRegexp).

Cheers,

Tim
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Nikolai Weibull-11]

On 2/18/07, Tim Pope <vim-ruby-devel@...> wrote:

> A much simpler pattern (and one that actually works) is
>
> syn region  rubyFunction matchgroup=rubyControl start="\<def\>\s*"    end="\ze\%(\s\|(\|;\|$\)" oneline

Even simpler (and faster):

syn region  rubyFunction matchgroup=rubyDefine start="\<def\>\ze\s*"
 end="\ze\%([[:space:](;:#]\|$\)" oneline

When using a backtracking regex matcher (juck!), using [[:space:]]
over \s and a branch in this instance is "a lot" faster.

But why aren't we doing this with something simpler like

syn keyword rubyDefine def nextgroup=rubyFunction skipwhite skipnl
syn match rubyFunction '\h\w*'

?  That's as simple and fast as it gets, and it's more true to the
Ruby syntax, because you can write things like

def
  a
  puts 'Hi, I'm method a!'
end

  nikolai
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Nikolai Weibull-11]

On 2/19/07, Nikolai Weibull <now@...> wrote:

> syn keyword rubyDefine def nextgroup=rubyFunction skipwhite skipnl
> syn match rubyFunction '\h\w*'

Should be

syn keyword rubyDefine def nextgroup=rubyFunction skipwhite skipnl
syn match rubyFunction contained '\h\w*'

  nikolai
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Sun, Feb 18, 2007 at 04:58:41PM -0600, Tim Pope wrote:

> In the latest CVS version of syntax/ruby.vim, method, class, and
> module declarations are no longer highlighted.  This seems to be due
> to changing lines like
>
> syn region rubyFunction matchgroup=rubyDefine start="\<def\s\+"    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline
>
> to lines like
>
> syn region rubyFunction matchgroup=rubyDefine start="\<def\(\s\+\)\@="    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline
>
> Presumably, this was to allow def, etc to be highlighted before the
> following space is input.

That's a side effect but it was actually so that users who specify
background colours, other than the default, for highlight groups don't
have the whitespace picked up too.

> A much simpler pattern (and one that
> actually works) is
>
> syn region  rubyFunction matchgroup=rubyControl start="\<def\>\s*"    end="\ze\%(\s\|(\|;\|$\)" oneline
>
> I will update the syntax file to use this third form if nobody objects.

So, unfortunately, this won't work.

Just out of interest, did you specifically drop the '#' from the end
pattern?  The following is valid syntax:

def foo# a comment
end
 
> I also have a few other minor changes that make the colors easier to
> tweak (things like grouping regexps together as rubyRegexp).

Go for it! ;-)

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Mon, Feb 19, 2007 at 12:55:46AM +0100, Nikolai Weibull wrote:

> On 2/18/07, Tim Pope <vim-ruby-devel@...> wrote:
>
> > A much simpler pattern (and one that actually works) is
> >
> > syn region  rubyFunction matchgroup=rubyControl start="\<def\>\s*"    end="\ze\%(\s\|(\|;\|$\)" oneline
>
> Even simpler (and faster):
>
> syn region  rubyFunction matchgroup=rubyDefine start="\<def\>\ze\s*"
>  end="\ze\%([[:space:](;:#]\|$\)" oneline

Why have you included the semicolon in the end pattern?  def Foo::bar; end
 
> When using a backtracking regex matcher (juck!), using [[:space:]]
> over \s and a branch in this instance is "a lot" faster.

I'll keep that in mind - thanks.
 
> But why aren't we doing this with something simpler like

Insufficiently refactored legacy 'code' I suspect. ;-)
 

> syn keyword rubyDefine def nextgroup=rubyFunction skipwhite skipnl
> syn match rubyFunction '\h\w*'
>
> ?  That's as simple and fast as it gets, and it's more true to the
> Ruby syntax, because you can write things like
>
> def
>   a
>   puts 'Hi, I'm method a!'
> end

I reckon we have a winner in principle.  Although that final pattern is
obviously an oversimplification eg. def foo.bar;end and def Foo::bar;end

Unfortunately, it doesn't work either due to all the def <-> end
matching malarkey. *sigh*

I'll take a look at it tonight.

Thanks,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Mon, Feb 19, 2007 at 12:43:43PM +1100, Doug Kearns wrote:
> So, unfortunately, this won't work.

I've already committed.  Since none of the three patterns is perfect,
I guess we need to come up with something different.  Nikolai's
pattern seems to meet both our criteria here, but has a side effect of
breaking folding (or else I would have used it already).  Perhaps you
can fix that, Nikolai?  I'm not doing anymore tonight, but I can take
a look tomorrow or so if you don't.

> Just out of interest, did you specifically drop the '#' from the end
> pattern?  The following is valid syntax:
>
> def foo# a comment
> end

No, I kept # in the pattern.  Must have been a botched up copy and
paste.

> > I also have a few other minor changes that make the colors easier to
> > tweak (things like grouping regexps together as rubyRegexp).
>
> Go for it! ;-)

I made a major change to how string interpolation works; try it out.
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Mon, Feb 19, 2007 at 12:48:36PM +1100, Doug Kearns wrote:

> On Mon, Feb 19, 2007 at 12:55:46AM +0100, Nikolai Weibull wrote:
> > On 2/18/07, Tim Pope <vim-ruby-devel@...> wrote:
> >
> > > A much simpler pattern (and one that actually works) is
> > >
> > > syn region  rubyFunction matchgroup=rubyControl start="\<def\>\s*"    end="\ze\%(\s\|(\|;\|$\)" oneline
> >
> > Even simpler (and faster):
> >
> > syn region  rubyFunction matchgroup=rubyDefine start="\<def\>\ze\s*"
> >  end="\ze\%([[:space:](;:#]\|$\)" oneline
>
> Why have you included the semicolon in the end pattern?  def Foo::bar; end

                            colon

<snip>

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Sun, Feb 18, 2007 at 08:07:21PM -0600, Tim Pope wrote:
> On Mon, Feb 19, 2007 at 12:43:43PM +1100, Doug Kearns wrote:

<snip>
 
> > > I also have a few other minor changes that make the colors easier to
> > > tweak (things like grouping regexps together as rubyRegexp).
> >
> > Go for it! ;-)
>
> I made a major change to how string interpolation works; try it out.

This has been tinkered with before using the same method you've used
and, from memory, it broke with some reasonably common nested string
constructs.  Unfortunately, when string highlighting goes awry it tends
to result in a rather bright red page. :)  So, the cop-out (err
compromise) was to highlight the simple one line interpolation sequences
and fall back to the standard string highlighting for the multi-line
interpolation sequences - yuck!

Now that we've got some extra man power and motivation on board (thanks)
it would be great to get this sorted out.  I've had a quick look through
the standard library files and with a couple of small exceptions, which
I'll fix, it seems to work fine.  The third party libraries are usually
less straight forward but, as usual, once it's sent out into the world
we're sure to hear about where it doesn't work in quick time. :)

I notice you haven't enhanced the highlighting, in kind, for #@foo and
similar.  I assume that's just an oversight?

My only concern with this change is it seems to be pushing us further
towards a saturated kaleidoscope of colour. ;-)

Thanks,
Doug

PS.  Vim 7 appears to have auto-magically fixed some of our other
outstanding highlighting bugs.  Patience is a virtue...
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Tue, Feb 20, 2007 at 09:36:49PM +1100, Doug Kearns wrote:

> On Sun, Feb 18, 2007 at 08:07:21PM -0600, Tim Pope wrote:
> > I made a major change to how string interpolation works; try it out.
>
> This has been tinkered with before using the same method you've used
> and, from memory, it broke with some reasonably common nested string
> constructs.  Unfortunately, when string highlighting goes awry it tends
> to result in a rather bright red page. :)  So, the cop-out (err
> compromise) was to highlight the simple one line interpolation sequences
> and fall back to the standard string highlighting for the multi-line
> interpolation sequences - yuck!

I have found this pattern to be more robust than the plain
highlighting it replaces.  Consider this excerpt from
test/test_helper.rb in Beast.  It works fine with my new pattern but
leaves the rest of the file as a string with the old one.

    @request.env["HTTP_AUTHORIZATION"] = user ? "Basic #{Base64.encode64("#{users(user).login}:testy")}" : nil

> Now that we've got some extra man power and motivation on board (thanks)
> it would be great to get this sorted out.  I've had a quick look through
> the standard library files and with a couple of small exceptions, which
> I'll fix, it seems to work fine.  The third party libraries are usually
> less straight forward but, as usual, once it's sent out into the world
> we're sure to hear about where it doesn't work in quick time. :)

If you can point me to an example, I'd love to see it.

> I notice you haven't enhanced the highlighting, in kind, for #@foo and
> similar.  I assume that's just an oversight?

Laziness, coupled with the fact that I don't consider this as critical
because there isn't really any "syntax" so the highlighting is just
cosmetic.  I'll probably fix it sooner or later; feel free to beat me
to it.

> My only concern with this change is it seems to be pushing us further
> towards a saturated kaleidoscope of colour. ;-)

I'm undecided as to whether the area inside the #{} should receive
delimiter highlighting or not.  I've coded my current inclination.
I'm also wondering if it'd look a bit better to highlight string
quotes as plain strings, not delimiters.  Yes, they are delimiters,
but it seems to be an unusual practice to highlight them as such, and
it seems to be to reduce the impact of string escape sequences and
interpolation, which I think are more important.

Cheers,

Tim
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Sun, Feb 18, 2007 at 08:07:21PM -0600, Tim Pope wrote:
> On Mon, Feb 19, 2007 at 12:43:43PM +1100, Doug Kearns wrote:
> > So, unfortunately, this won't work.
>
> I've already committed.  Since none of the three patterns is perfect,
> I guess we need to come up with something different.

Yes, I guess it's time to rethink the way this is done.  Just a couple
of quick comments on some of your changes below.

Index: syntax/ruby.vim
===================================================================
RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
retrieving revision 1.95
retrieving revision 1.97
diff -u -r1.95 -r1.97
--- syntax/ruby.vim     8 Nov 2006 13:01:57 -0000       1.95
+++ syntax/ruby.vim     20 Feb 2007 22:52:49 -0000      1.97
@@ -150,14 +150,14 @@

 " Expensive Mode - colorize *end* according to opening statement
 if !exists("b:ruby_no_expensive") && !exists("ruby_no_expensive")
-  syn region rubyFunction matchgroup=rubyDefine start="\<def\(\s\+\)\@="    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline
-  syn region rubyClass   matchgroup=rubyDefine start="\<class\(\s\+\)\@="  end="\%(\s*\%(\s\|<\|;\|$\|#\)\)\@=" oneline
-  syn match  rubyDefine   "\<class\ze<<"
-  syn region rubyModule   matchgroup=rubyDefine start="\<module\(\s\+\)\@=" end="\%(\s*\%(\s\|;\|$\|#\)\)\@="    oneline
+  syn region rubyFunction matchgroup=rubyDefine start="\<def\>\s*"    end="\%(\s*\%(\s\|(\|;\|$\|#\)\)\@=" oneline contains=rubyPseudoVariable

Is there a reason you think this is a better start pattern than
\<def\s\+, or \<def\_s\+, which is closer to how the parser works?  Am I
missing something?  Whilst not a big deal this now allows incorrect
syntax (like def.foobar) to be highlighted.  You can probably find an
orange for my apple though. ;-)

How about reverting to this in the interim?

syn region rubyFunction matchgroup=rubyDefine start="\<def\s\+" end="\ze\%([[:space:](;#]\|$\)" oneline contains=rubyPseudoVariable

+  syn region rubyClass   matchgroup=rubyType   start="\<class\>\s*"  end="\%(\s*\%(\s\|<\|;\|$\|#\)\)\@=" oneline
+  syn match  rubyType     "\<class\ze\s*<<"

This line can actually be removed if we use the pattern you've changed it to
above.  It was just a special case since it's the only time something other
than \s can follow the class keyword.

+  syn region rubyModule   matchgroup=rubyType   start="\<module\>\s*" end="\%(\s*\%(\s\|;\|$\|#\)\)\@="          oneline

   syn region rubyBlock start="\<def\>"   matchgroup=rubyDefine end="\<end\>" contains=ALLBUT,@rubyExtendedStringSpecial,rubyTodo nextgroup=rubyFunction fold
-  syn region rubyBlock start="\<class\>"  matchgroup=rubyDefine end="\<end\>" contains=ALLBUT,@rubyExtendedStringSpecial,rubyTodo nextgroup=rubyClass   fold
-  syn region rubyBlock start="\<module\>" matchgroup=rubyDefine end="\<end\>" contains=ALLBUT,@rubyExtendedStringSpecial,rubyTodo nextgroup=rubyModule  fold
+  syn region rubyBlock start="\<class\>"  matchgroup=rubyType   end="\<end\>" contains=ALLBUT,@rubyExtendedStringSpecial,rubyTodo nextgroup=rubyClass   fold
+  syn region rubyBlock start="\<module\>" matchgroup=rubyType   end="\<end\>" contains=ALLBUT,@rubyExtendedStringSpecial,rubyTodo nextgroup=rubyModule  fold

   " modifiers
   syn match  rubyControl "\<\%(if\|unless\|while\|until\)\>" display

<snip>

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

Tim,

Just ignore that.  It seems my fetchmail has died and I didn't notice
your most recent changes. *sigh*

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Tue, Feb 20, 2007 at 10:10:25AM -0600, Tim Pope wrote:
> On Tue, Feb 20, 2007 at 09:36:49PM +1100, Doug Kearns wrote:

<snip>
 
> > Now that we've got some extra man power and motivation on board (thanks)
> > it would be great to get this sorted out.  I've had a quick look through
> > the standard library files and with a couple of small exceptions, which
> > I'll fix, it seems to work fine.  The third party libraries are usually
> > less straight forward but, as usual, once it's sent out into the world
> > we're sure to hear about where it doesn't work in quick time. :)
>
> If you can point me to an example, I'd love to see it.

A simple example is:

puts "\#{"

I'll take a look at that next week if you don't get to it first.

<snip>

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Sat, Feb 24, 2007 at 01:31:21AM +1100, Doug Kearns wrote:
> A simple example is:
>
> puts "\#{"

Fixed, anything else?  If things get too hairy, we can always add
keepend to the string highlighting.  This breaks strings nested inside
interpolation, but only slightly.

Cheers,

Tim
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Tue, Feb 20, 2007 at 10:10:25AM -0600, Tim Pope wrote:

<snip>
 
> > Now that we've got some extra man power and motivation on board (thanks)
> > it would be great to get this sorted out.  I've had a quick look through
> > the standard library files and with a couple of small exceptions, which
> > I'll fix, it seems to work fine.  The third party libraries are usually
> > less straight forward but, as usual, once it's sent out into the world
> > we're sure to hear about where it doesn't work in quick time. :)
>
> If you can point me to an example, I'd love to see it.

FWIW, I suspect that some of the highlighting will break when in an
interpolation region since it makes assumptions about what can appear
before and after syntax 'elements'.  When I wrote these I didn't do so
with this new addition in mind.  Have you come across any yet?

<snip>

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Mon, Feb 26, 2007 at 08:56:47PM +1100, Doug Kearns wrote:
> FWIW, I suspect that some of the highlighting will break when in an
> interpolation region since it makes assumptions about what can appear
> before and after syntax 'elements'.  When I wrote these I didn't do so
> with this new addition in mind.  Have you come across any yet?

No, but it didn't take much searching:

"#{if true then 1 end}"

However, syntax highlighting also fails on

3.times { if true then 1 end }

Of these two, the latter is more serious because it affects future end
highlighting.

Adding { to the monster regexp setting off if/unless does not fix
this.  Apparently Vim doesn't like backtracking through the beginning
of a region definition.  I'll investigate a bit more; let me know if
you have any ideas.

Cheers,
Tim
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Nikolai Weibull-11]

On 2/26/07, Tim Pope <vim-ruby-devel@...> wrote:

> On Mon, Feb 26, 2007 at 08:56:47PM +1100, Doug Kearns wrote:
> > FWIW, I suspect that some of the highlighting will break when in an
> > interpolation region since it makes assumptions about what can appear
> > before and after syntax 'elements'.  When I wrote these I didn't do so
> > with this new addition in mind.  Have you come across any yet?
>
> No, but it didn't take much searching:
>
> "#{if true then 1 end}"
>
> However, syntax highlighting also fails on
>
> 3.times { if true then 1 end }
>
> Of these two, the latter is more serious because it affects future end
> highlighting.
>
> Adding { to the monster regexp setting off if/unless does not fix
> this.  Apparently Vim doesn't like backtracking through the beginning
> of a region definition.  I'll investigate a bit more; let me know if
> you have any ideas.

Uh, oh.  It sounds as if we're going overboard here.  Sorry, no ideas,
just complaints.  Still, it's going to be very hard to match every
weird part of the Ruby grammar, so optimizing for the common cases
makes things a lot easier.  I'm sure there's code out there that
actually contains the line "#{if true then 1 end}", but I don't see
why we should try so damn hard to match it beyond matching the
delimiters.  If you're silly enough to put a lot of junk in your
string interpolations, then syntax highlighting isn't really going to
help you much.

  nikolai
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:

> On 2/26/07, Tim Pope <vim-ruby-devel@...> wrote:
> > On Mon, Feb 26, 2007 at 08:56:47PM +1100, Doug Kearns wrote:
> > > FWIW, I suspect that some of the highlighting will break when in an
> > > interpolation region since it makes assumptions about what can appear
> > > before and after syntax 'elements'.  When I wrote these I didn't do so
> > > with this new addition in mind.  Have you come across any yet?
> >
> > No, but it didn't take much searching:
> >
> > "#{if true then 1 end}"
> >
> > However, syntax highlighting also fails on
> >
> > 3.times { if true then 1 end }
> >
> > Of these two, the latter is more serious because it affects future end
> > highlighting.
> >
> > Adding { to the monster regexp setting off if/unless does not fix
> > this.  Apparently Vim doesn't like backtracking through the beginning
> > of a region definition.  I'll investigate a bit more; let me know if
> > you have any ideas.
>
> Uh, oh.  It sounds as if we're going overboard here.  Sorry, no ideas,
> just complaints.  Still, it's going to be very hard to match every
> weird part of the Ruby grammar, so optimizing for the common cases
> makes things a lot easier.  I'm sure there's code out there that
> actually contains the line "#{if true then 1 end}", but I don't see
> why we should try so damn hard to match it beyond matching the
> delimiters.  If you're silly enough to put a lot of junk in your
> string interpolations, then syntax highlighting isn't really going to
> help you much.

Agreed, regarding strings.  However, I thing my second example,

3.times { if true then 1 end }

is a bit more reasonable.  A fix for this would probably fix the
string interpolation for free.

Cheers,
Tim
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Nikolai Weibull-11]

On 2/26/07, Tim Pope <vim-ruby-devel@...> wrote:

> On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:
> > On 2/26/07, Tim Pope <vim-ruby-devel@...> wrote:
> > > On Mon, Feb 26, 2007 at 08:56:47PM +1100, Doug Kearns wrote:
> > > > FWIW, I suspect that some of the highlighting will break when in an
> > > > interpolation region since it makes assumptions about what can appear
> > > > before and after syntax 'elements'.  When I wrote these I didn't do so
> > > > with this new addition in mind.  Have you come across any yet?
> > >
> > > No, but it didn't take much searching:
> > >
> > > "#{if true then 1 end}"
> > >
> > > However, syntax highlighting also fails on
> > >
> > > 3.times { if true then 1 end }
> > >
> > > Of these two, the latter is more serious because it affects future end
> > > highlighting.
> > >
> > > Adding { to the monster regexp setting off if/unless does not fix
> > > this.  Apparently Vim doesn't like backtracking through the beginning
> > > of a region definition.  I'll investigate a bit more; let me know if
> > > you have any ideas.
> >
> > Uh, oh.  It sounds as if we're going overboard here.  Sorry, no ideas,
> > just complaints.  Still, it's going to be very hard to match every
> > weird part of the Ruby grammar, so optimizing for the common cases
> > makes things a lot easier.  I'm sure there's code out there that
> > actually contains the line "#{if true then 1 end}", but I don't see
> > why we should try so damn hard to match it beyond matching the
> > delimiters.  If you're silly enough to put a lot of junk in your
> > string interpolations, then syntax highlighting isn't really going to
> > help you much.
>
> Agreed, regarding strings.  However, I thing my second example,
>
> 3.times { if true then 1 end }
>
> is a bit more reasonable.  A fix for this would probably fix the
> string interpolation for free.

Absolutely.  I don't know if it fixes it, but that would be good too ;-).

Wait, this only fails if you have that silly "what-type-of-end-is-it"
option on, right?

  nikolai
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

On Mon, Feb 26, 2007 at 09:15:06PM +0100, Nikolai Weibull wrote:
> Wait, this only fails if you have that silly "what-type-of-end-is-it"
> option on, right?

Yes.
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

On Mon, Feb 26, 2007 at 09:21:40AM -0600, Tim Pope wrote:

> On Mon, Feb 26, 2007 at 08:56:47PM +1100, Doug Kearns wrote:
> > FWIW, I suspect that some of the highlighting will break when in an
> > interpolation region since it makes assumptions about what can appear
> > before and after syntax 'elements'.  When I wrote these I didn't do so
> > with this new addition in mind.  Have you come across any yet?
>
> No, but it didn't take much searching:
>
> "#{if true then 1 end}"
>
> However, syntax highlighting also fails on
>
> 3.times { if true then 1 end }
>
> Of these two, the latter is more serious because it affects future end
> highlighting.
>
> Adding { to the monster regexp setting off if/unless does not fix
> this.  Apparently Vim doesn't like backtracking through the beginning
> of a region definition.  I'll investigate a bit more; let me know if
> you have any ideas.

This seems to work:


Index: syntax/ruby.vim
===================================================================
RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
retrieving revision 1.115
diff -u -r1.115 ruby.vim
--- syntax/ruby.vim 27 Feb 2007 13:17:36 -0000 1.115
+++ syntax/ruby.vim 28 Feb 2007 10:08:14 -0000
@@ -183,7 +183,7 @@
   " statements without *do*
   syn region rubyNoDoBlock  matchgroup=rubyControl     start="\<begin\>" end="\<end\>" contains=TOP fold
   syn region rubyCaseBlock  matchgroup=rubyConditional start="\<case\>"  end="\<end\>" contains=TOP fold
-  syn region rubyConditionalBlock matchgroup=rubyConditional start="\%(^\|\.\.\.\=\|[,;=([<>~\*/%&^|+-]\|\%(\<[_[:lower:]][_[:alnum:]]*\)\@<![!=?]\)\s*\zs\%(if\|unless\)\>" end="\<end\>" contains=TOP fold
+  syn region rubyConditionalBlock matchgroup=rubyConditional start="\%(\%(^\|\.\.\.\=\|[{,;=([<>~\*/%&^|+-]\|\%(\<[_[:lower:]][_[:alnum:]]*\)\@<![!=?]\)\s*\)\@<=\%(if\|unless\)\>" end="\<end\>" contains=TOP fold
   syn keyword rubyConditional then else when  contained containedin=rubyCaseBlock
   syn keyword rubyConditional then else elsif contained containedin=rubyConditionalBlock
 

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel