[#1215] Tk widget demo; English Tk docs?; Java 1.2 Swing — "Conrad Schneiker" <schneiker@...>
Hi,
[#1218] Trivial FAQ bug — Dave Thomas <Dave@...>
[#1229] A vote for old behavior — Dave Thomas <Dave@...>
[#1232] Any FAQ requests, updates, ... — Dave Thomas <Dave@...>
[#1233] Singleton classes — Dave Thomas <Dave@...>
[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>
[#1307] Ruby/GTK 0.23 released — Hiroshi IGARASHI <igarashi@...>
Hi all,
From: Hiroshi IGARASHI <igarashi@ueda.info.waseda.ac.jp>
From: "Conrad Schneiker" <schneiker@jump.net>
On Fri, Feb 18, 2000 at 09:37:27PM -0500, Yasushi Shoji wrote:
[#1322] FAQ: Ruby acronyms — "Conrad Schneiker" <schneiker@...>
In the spirit of TABWTDI (there are better ways to do it), I'd like to
[#1341] Vim syntax file — Mirko Nasato <mirko.nasato@...>
Hi,
On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
[#1354] Say hi (bis) — Pixel <pixel_@...>
hi all,
[#1355] nice sample for functional stuff — Pixel <pixel_@...>
what about having map in standard (and map_index too)?
[#1373] Ruby Language Reference Manual--Glossary — "Conrad Schneiker" <schneiker@...>
I was going to print the Ruby Language Reference Manual when I noticed that
[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>
Conrad writes:
[#1379] Re: Yield — Andrew Hunt <andy@...>
>From: "Conrad Schneiker" <schneiker@jump.net>
[#1384] Re: Say Hi — mengx@...
My suggestion was to try to find a more comfortable method name (to me, and
[#1392] Re: Some Questions - Parameterised Types / Invariants — Andrew Hunt <andy@...>
>1. Parameterised Types / Template Classes
[#1398] Bignum aset — Andrew Hunt <Andy@...>
[#1488] Discussion happens on news.groups — Clemens Hintze <c.hintze@...>
Hi,
[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>
Hello Ian,
On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:
[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>
((FYI: This was sent to the Ruby mail list.))
From: "Conrad Schneiker" <schneiker@jump.net>
[#1528] ruby <=> python — Quinn Dunkan <quinn@...>
Hello! I'm new to ruby-talk, and mostly new to ruby. I'm making a document
[#1551] Ruby thread scheduling buglet — Ian Main <imain@...>
[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1591] Certain char's not recognized by "." in regex? — Wes Nakamura <wknaka@...>
[#1592] Race condition in Singleton — Dave Thomas <Dave@...>
[ruby-talk:01464] Re: Vim syntax file
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