On Wed, Feb 16, 2000 at 06:04:32PM +0100, Mirko Nasato wrote:
> Reimer Behrends wrote:
> > On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
> > > Anyone made a ruby.vim syntax file yet? If not, i'm going to do it.
> > I have an unfinished one at
> > 	http://www.cse.msu.edu/~behrends/vim/
> Now i go and fetch it.
> 
> In the meantime, i have started my own...
> 
>   => http://altern.org/mn/ruby/ruby.vim
>   => http://altern.org/mn/ruby/vim.html  (documentation)

Looks good. Much better than mine, too. :)

[...]
> > 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)

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.

Unfortunately, I don't see a good heuristic here. Tolerable, yes, but
not necessarily good. You cannot distinguish by left or right context,
either.

> > Reliably parsing "here documents".
> Mine support only EOF (like perl.vim). Other labels can be added, but
> i doubt we can find a generalized way.

I went for supporting a couple of standard ones, and otherwise just to
terminate the pattern whenever I encountered a line made up of just
capital letters (with initial whitespace allowed for the <<-EOF variant).

This is probably less of a problem than just letting the highlighting
mechanism run amok over arbitrary text.

By the way, I believe your syntax file doesn't yet allow <<-EOF,
<<'EOF', and <<"EOF"?

> > Handling %[qQrxw] constructs that span multiple lines (same problem).
> Mine does, but not for all delimiters (again, like perl.vim).

I've wondered if it is feasible (i.e. doesn't slow down highlighting
significantly) to have these patterns automatically pregenerated by a
quick script.

> > Better treatment of #{...} embedded in strings and regular expressions.
> Mine does it well, i think.

Try the following extreme example:

print <<EOF
foo
#{ { 1 => "bar", 2 => "baz" }[1] }
EOF

Not really a serious problem, but a pain to get completely right.

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

> Other features i've put in it:
>   * option to disable colorizing of constants, instance vars, 
>     global vars, iterator vars, predefined vars, symbols
>   * "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).

> Other problems:
>   * characters, like ?a or ?\M-a: where are they documented?

Check the irb package, ruby-lex.rb has a read_escape routine that
parses all of them (well, kindof). Basically, as I understand it:

\\, \n, \r, \f, \t, \v, \a, \e, \b.
\[0-7]{1,3} for octal escapes
\x[0-7a-fA-F]{1,2} for hex escapes
\M- followed by another character or escape sequence
\C- followed by another character or escape sequence
\c  followed by another character or escape sequence

(\^ doesn't appear to work.)

Any syntax highlighting pattern would apply to string escapes, too.

>   * slow or inaccurate (that's a trade-off) for big files
>   * all the ones i didn't catch
> 
> Should we make a ruby.vim.regression.rb?  I've used test.rb in Ruby's
> sample dir, plus a few ad hoc scripts.

Sounds like a good idea. I think I can put some nasty tests together. :)

				Reimer Behrends