Reimer Behrends wrote:
> On Wed, Feb 16, 2000 at 06:04:32PM +0100, Mirko Nasato wrote:
> > In the meantime, i have started my own...
> > 
> >   => http://altern.org/mn/ruby/ruby.vim
> 
> Looks good. Much better than mine, too. :)
> 
Good ideas are taken from perl.vim; bad ones are mine. :)

> > > Main problems remaining:
> > > Distinguishing the division operator from regular expressions.
> > Mine works for one line patterns, not for multiline.
> 
> Unfortunately, not quite. Try:
> 
> 	x / (1.0 + m / n)
>
That was an idea of mine, in fact.
Let's reach out for perl.vim again...

> In other words, if you've got more than one slash, things get mixed
> up. And multiline pattern are as always a problem. My quick hack was
> to distinguish slashes followed by a blank from those that weren't.
> This requires that you put spaces after a division operator and avoid
> them at the beginning of a regular expression.
>
I don't like the idea. I often write "n/3", not "n / 3". And you could
have a "/ regex/" beginning with a space, too.

> Unfortunately, I don't see a good heuristic here. Tolerable, yes, but
> not necessarily good. You cannot distinguish by left or right context,
> either.
>
Leading context is exactly the approach taken in perl.vim.

Adapting, it can handle forms like

  expr =~ /regex/
  func(/regex/, /regex/)
  rx = /regex/
  if /regex/ || /regex/

The "if" is treated as a special case.  I can see no general way to 
handle statement followed by regex. "if" is probably the most used;
elsewhere the programmer can always prepend an "r" to the pattern, 
writing "while r/regex/". That's not The Right Thing, of course.
Or we can provide a special treatment for each keyword...

(My ruby.vim has been updated with this idea.)

> > > Highlighting errors rather than ignoring them.
> > Errors? Do Ruby programmers make errors? ;-)
> 
> :)
> 
> When writing the eiffel.vim file, I intentionally designed it to catch
> as many typos (like mismatched parentheses) during editing, and it has
> been worthwhile. And even though ruby doesn't suffer from fairly slow
> compilation, it should be able to help you.
> 
I agree, a syntax file should not only be eye-pleasing. My idea was 
to focus on all the other features first. But you make me realize this 
isn't the right approach; we should think about possible errors while
handling correct forms. Apart from mismatched parens, which deserve
attention on their own.

> > Other features i've put in it:
> >   * "end" color match that of opening statement (e.g. "end" closing a
> >     "def" is purple like the "def", "end" closing a "while" is yellow 
> >     like the "while")
> 
> I've purposely avoided the latter because it can be hellishly slow on
> some older machines (sh.vim is a prime example on how to make editing
> on some of the older SPARCs torturous).
> 
I know it can become slow; maybe it can be made optional. Originally,
my idea was to help avoiding mismatched "end"s (not such a big issue,
maybe). But i missed that goal because of the "do" (sometimes it opens
a block, sometimes it is merely optional). So far it is just eye-candy.
But i have to say i like it anyway. :)

(I missed the time to address the other issues.)

Ciao.

-- Mirko Nasato