From rob at muhlestein.net  Wed Jan 10 16:25:30 2007
From: rob at muhlestein.net (Rob Muhlestein)
Date: Wed, 10 Jan 2007 16:25:30 -0500
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
Message-ID: <1168464330.4245.89.camel@dads>

Downloaded the latest ruby-vim but still don't see the following
keywords in ruby.vim. I've added them to my own but would a patch to the
ruby.vim in this project be worth it? If so, I'll submit what I have.

RSpec DSL:

  context
  context_setup
  setup
  specify
  context_teardown
  teardown

GEMS DSL:
  require_gem
  (more I'll look up if worth it)

These DSLs are pretty mainstream and I think would be worth inclusion
for much the same reason that the Rails DSL addition to ruby also seems
worth it.

-- 
Rob Muhlestein
http://rob.muhlestein.net


From gsinclair at gmail.com  Wed Jan 10 20:54:04 2007
From: gsinclair at gmail.com (Gavin Sinclair)
Date: Thu, 11 Jan 2007 12:54:04 +1100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <1168464330.4245.89.camel@dads>
References: <1168464330.4245.89.camel@dads>
Message-ID: <a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>

On 1/11/07, Rob Muhlestein <rob at muhlestein.net> wrote:
>
> RSpec DSL:
>
>   context
>   context_setup
>   setup
>   specify
>   context_teardown
>   teardown

Sounds good.

> GEMS DSL:
>   require_gem
>   (more I'll look up if worth it)

"require_gem" is deprecated in favour of "gem".  Maybe "require_gem"
should be coloured something ugly to alert people.

Gavin

From rob at muhlestein.net  Fri Jan 12 08:14:11 2007
From: rob at muhlestein.net (Rob Muhlestein)
Date: Fri, 12 Jan 2007 08:14:11 -0500
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
References: <1168464330.4245.89.camel@dads>
	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
Message-ID: <1168607652.18820.9.camel@dads>

> "require_gem" is deprecated in favour of "gem".  Maybe "require_gem"
> should be coloured something ugly to alert people.

Ok. Before I tweek this, what is the module name for CVS checkout? Any
chance of moving project to SVN?

-- 
Rob Muhlestein
http://rob.muhlestein.net


From alexandru at globalterrasoft.ro  Fri Jan 19 10:31:36 2007
From: alexandru at globalterrasoft.ro (Alexandru E. Ungur)
Date: Fri, 19 Jan 2007 17:31:36 +0200
Subject: new rubycomplete for testing
In-Reply-To: <456F0C33.2070100@hasno.info>
References: <456F0C33.2070100@hasno.info>
Message-ID: <20070119153136.GA18559@globalterrasoft.ro>

>>> sender: "Mark Guzman" date: "Thu, Nov 30, 2006 at 11:52:03AM -0500" <<<EOQ
> I've checked in the version of rubycomplete that I've been working on.
> It passes my current tests. If anyone has some time, please grab it from
> cvs and test it out please.
>    --mark
Hi,
I just downloaded the version from CVS yesterday and am experiencing
some crashes.

if I do this:
[].each do |a| a.<C-X><C-O>

At omnicomplete point it just crashes, sometimes from the first try,
other times by simply deleting the . then trying again .<C-X><C-O>

You can use anything in place of 'each', it will behave the same.
Also you can write that as multiline, properly close the do with
an 'end', and then try to complete 'a.' it will still crash just 
the same.

I am using this version of vim:
:version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep  7 2006 18:25:18)
Included patches: 1-91
Compiled by Alexandru Ungur <alex at rb.no-ip.biz>
Normal version with X11-Motif GUI.  Features included (+) or not (-):
-arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+cryptv -cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic 
-emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path 
+folding -footer +fork() +gettext -hangul_input -iconv +insert_expand +jumplist 
-keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu 
+mksession +modify_fname +mouse +mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm 
-mouse_netterm +mouse_xterm -multi_byte +multi_lang -mzscheme +netbeans_intg 
-osfiletype +path_extra +perl +postscript +printer -profile +python +quickfix 
+reltime -rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline 
-sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo 
+termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit 
+visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup 
+X11 +xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save

Let me know if you need any other info, a strace log, etc. 

Ok, besides the bug reports,
I just want to say thanks for the great work, it's a really nice plugin.

Cheers, 
Alex

From segfault at hasno.info  Mon Jan 22 02:45:47 2007
From: segfault at hasno.info (Mark Guzman)
Date: Mon, 22 Jan 2007 02:45:47 -0500
Subject: new rubycomplete for testing
In-Reply-To: <20070119153136.GA18559@globalterrasoft.ro>
References: <456F0C33.2070100@hasno.info>
	<20070119153136.GA18559@globalterrasoft.ro>
Message-ID: <45B46BAB.1020406@hasno.info>

Alexandru E. Ungur wrote:
>>>> sender: "Mark Guzman" date: "Thu, Nov 30, 2006 at 11:52:03AM -0500" <<<EOQ
>>>>         
>> I've checked in the version of rubycomplete that I've been working on.
>> It passes my current tests. If anyone has some time, please grab it from
>> cvs and test it out please.
>>    --mark
>>     
> Hi,
> I just downloaded the version from CVS yesterday and am experiencing
> some crashes.
>
> if I do this:
> [].each do |a| a.<C-X><C-O>
>   

> Let me know if you need any other info, a strace log, etc. 
>   
Can you get me the ruby version that vim is linked to? The strace would 
be useful also.

> Ok, besides the bug reports,
> I just want to say thanks for the great work, it's a really nice plugin.
>   
Thanks, glad to hear it.

  --mark

From alexandru at globalterrasoft.ro  Mon Jan 22 04:01:11 2007
From: alexandru at globalterrasoft.ro (Alexandru E. Ungur)
Date: Mon, 22 Jan 2007 11:01:11 +0200
Subject: new rubycomplete for testing
In-Reply-To: <45B46BAB.1020406@hasno.info>
References: <456F0C33.2070100@hasno.info>
	<20070119153136.GA18559@globalterrasoft.ro>
	<45B46BAB.1020406@hasno.info>
Message-ID: <20070122090111.GA17432@globalterrasoft.ro>

>>> sender: "Mark Guzman" date: "Mon, Jan 22, 2007 at 02:45:47AM -0500" <<<EOQ
> Can you get me the ruby version that vim is linked to? The strace would 
> be useful also.
Well, I supposed it linked against the installed Ruby, and that means:
ruby 1.8.4 (2005-12-24) [i686-linux]

Not sure if gem and rails versions matter, but here they are anyway:
~>> gem -v
0.9.1
~>> rails -v
Rails 1.1.6

You can download the strace log from here:
http://pub.slax.no-ip.biz/strace.log.gz


If there's anything else I can do, just let me know.

Have a nice day everyone,
Alex

From vim-ruby-devel at tpope.info  Mon Jan 22 14:15:24 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 22 Jan 2007 13:15:24 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <4577388E.10800@hasno.info>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info>
Message-ID: <20070122191524.GQ5520@tpope.us>

On Wed, Dec 06, 2006 at 04:39:26PM -0500, Mark Guzman wrote:
> I wasn't sure how people would feel about using the 'interface' for all
> platforms where it was available. The only platform where it really gets
> under my skin happens to be windows. The load time would indeed be
> marginally quicker, so with your (assumed) blessing I'll modify the file
> again to make the change relevant to all platforms.
>    --mark

As you may recall from our IRC discussion, I was quite skeptical :).
Yesterday, I encountered a user with an actual problem with this.  Vim
was segfaulting everytime he edited a Ruby file after updating to the
latest vim-ruby scripts.  This use of the Vim Ruby interface turned
out to be the problem.  We never pinned down the true cause (probably
something broken in the way Vim or Ruby was compiled).  The Vim Ruby
interface has always seemed like a dirty hack.  Often times when using
it, I get errors like:

SystemStackError: (eval):761:in `get_completions': stack level too deep

That's from the rubycomplete script plugin, but I've seen it when
writing my own code as well.  I've also seen segfaults as well
(including the same segfault experienced in the recent post about
rubycomplete).  The very fact a user script can bring down Vim as a
whole suggests something isn't quite right.  I'm reverting this change
to just be used on Windows because this is where the largest gains can
be seen, and because on Windows, there are generally just a few well
known compilations, as opposed to the plethora of custom compilations
(both by distros and by end users) that can be found on other
operating systems.

Feel free to revert and discuss if you disagree.

Any news about a release? :)

Cheers,

Tim

From segfault at hasno.info  Mon Jan 22 19:57:39 2007
From: segfault at hasno.info (Mark Guzman)
Date: Mon, 22 Jan 2007 19:57:39 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070122191524.GQ5520@tpope.us>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>
Message-ID: <45B55D83.4030502@hasno.info>

Tim Pope wrote:
>
> As you may recall from our IRC discussion, I was quite skeptical :).
> Yesterday, I encountered a user with an actual problem with this.  Vim
> was segfaulting everytime he edited a Ruby file after updating to the
> latest vim-ruby scripts.  This use of the Vim Ruby interface turned
> out to be the problem.  We never pinned down the true cause (probably
> something broken in the way Vim or Ruby was compiled).  The Vim Ruby
> interface has always seemed like a dirty hack.  Often times when using
> it, I get errors like:
>
>   
This doesn't occur unless rails.vim is loaded. I'm still searching for 
the actual cause, but I can confirm that this is the reason under 
osx,fbsd, solaris, and linux. I've been testing with the cvs version of 
rubycomplete and the rails.vim from your site. This seems to match up 
with the user reports also, though I haven't had them run it without 
rails.vim.
> Feel free to revert and discuss if you disagree.
>   

Have you actually experienced a crash due to the path discovery code?

  --mark

From vim-ruby-devel at tpope.info  Tue Jan 23 11:45:16 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 23 Jan 2007 10:45:16 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B55D83.4030502@hasno.info>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info>
Message-ID: <20070123164516.GR5520@tpope.us>

On Mon, Jan 22, 2007 at 07:57:39PM -0500, Mark Guzman wrote:
> Tim Pope wrote:
> >
> > As you may recall from our IRC discussion, I was quite skeptical :).
> > Yesterday, I encountered a user with an actual problem with this.  Vim
> > was segfaulting everytime he edited a Ruby file after updating to the
> > latest vim-ruby scripts.  This use of the Vim Ruby interface turned
> > out to be the problem.  We never pinned down the true cause (probably
> > something broken in the way Vim or Ruby was compiled).  The Vim Ruby
> > interface has always seemed like a dirty hack.  Often times when using
> > it, I get errors like:
> >
> This doesn't occur unless rails.vim is loaded. I'm still searching for 
> the actual cause, but I can confirm that this is the reason under 
> osx,fbsd, solaris, and linux. I've been testing with the cvs version of 
> rubycomplete and the rails.vim from your site. This seems to match up 
> with the user reports also, though I haven't had them run it without 
> rails.vim.

Very odd.  rails.vim only recently started making use of the Vim-Ruby
interface.  The next revision will limit it to Windows only; perhaps I
should just do away with it all together (although I can't reproduce
any of these problems on Windows).  For the record, rails.vim uses it
in two places which previously used system():

1. require 'action_view' and extract a list of helper methods from it.

2. require 'yaml' and parse database.yml (only if dbext.vim is installed)

On my system, I observe the following behaviors.  If the first is
performed, with or without the second. the stack overflow error starts
to be seen when completion is used.  If the second is performed
*without* the first, Vim will segfault when completion is used.
Things work fine if you :ruby require the same libraries manually, and
things still break if all rails.vim does is require the same
libraries.  Perhaps is has something to do with how things are nested
in a Vim function.  I will investigate further.

> Have you actually experienced a crash due to the path discovery code?

No.  This user claims to have, even without rails.vim loaded.
g:rubycomplete_rails might have been set.

Cheers,

Tim

From segfault at hasno.info  Tue Jan 23 14:17:00 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 14:17:00 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123164516.GR5520@tpope.us>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>
Message-ID: <45B65F2C.2090105@hasno.info>

Tim Pope wrote:
> Very odd.  rails.vim only recently started making use of the Vim-Ruby
> interface.  The next revision will limit it to Windows only; perhaps I
> should just do away with it all together (although I can't reproduce
> any of these problems on Windows).  For the record, rails.vim uses it
> in two places which previously used system():
>
> 1. require 'action_view' and extract a list of helper methods from it.
>
> 2. require 'yaml' and parse database.yml (only if dbext.vim is installed)
>
> On my system, I observe the following behaviors.  If the first is
> performed, with or without the second. the stack overflow error starts
> to be seen when completion is used.  If the second is performed
> *without* the first, Vim will segfault when completion is used.
> Things work fine if you :ruby require the same libraries manually, and
> things still break if all rails.vim does is require the same
> libraries.  Perhaps is has something to do with how things are nested
> in a Vim function.  I will investigate further.
>
>   
Weird, I'll see if i can be of any help. If it's a problem w/ the 
vim-ruby bridge it'd be nice if we could fix it.
>> Have you actually experienced a crash due to the path discovery code?
>>     
>
> No.  This user claims to have, even without rails.vim loaded.
> g:rubycomplete_rails might have been set.
>   
Who? Can you forward on the email so I can find out more? The rails 
support stuff is pretty intense since it's loading rails into the env.
  --mark

From segfault at hasno.info  Tue Jan 23 14:34:29 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 14:34:29 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B65F2C.2090105@hasno.info>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>	<20070123164516.GR5520@tpope.us>
	<45B65F2C.2090105@hasno.info>
Message-ID: <45B66345.8000506@hasno.info>

Mark Guzman wrote:
>>> Have you actually experienced a crash due to the path discovery code?
>>>     
>>>       
>> No.  This user claims to have, even without rails.vim loaded.
>> g:rubycomplete_rails might have been set.
>>  
>>     
It just struck me that you might've mis-understood my original question. 
I was asking about the actual path discovery stuff (s:rubypath), not the 
omni-completion crash.
  --mark

From segfault at hasno.info  Tue Jan 23 14:36:47 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 14:36:47 -0500
Subject: new rubycomplete for testing
In-Reply-To: <20070122090111.GA17432@globalterrasoft.ro>
References: <456F0C33.2070100@hasno.info>	<20070119153136.GA18559@globalterrasoft.ro>	<45B46BAB.1020406@hasno.info>
	<20070122090111.GA17432@globalterrasoft.ro>
Message-ID: <45B663CF.2020904@hasno.info>

Thanks for the strace Alex. It looks like theres some sort of problem w/ 
rubycomplete when rails.vim is loaded. From the strace it seems that 
rails.vim is being loaded, both Tim and I are searching for the cause.
  --mark

From vim-ruby-devel at tpope.info  Tue Jan 23 14:32:39 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 23 Jan 2007 13:32:39 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123164516.GR5520@tpope.us>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info> <20070123164516.GR5520@tpope.us>
Message-ID: <20070123193239.GS5520@tpope.us>

On Tue, Jan 23, 2007 at 10:45:16AM -0600, Tim Pope wrote:
> Things work fine if you :ruby require the same libraries manually, and
> things still break if all rails.vim does is require the same
> libraries.  Perhaps is has something to do with how things are nested
> in a Vim function.  I will investigate further.

A little further investigation reveals the trigger.  The first time
the Ruby interface is used is significant.  If it is used at the top
level, all is well.  If it is nested deep inside several function
calls, this seems to reduce the available stack space to Ruby.  Note
that only there very first call is relevant.  If I add

silent! ruby nil

to the plugin initialization function of rails.vim (so that the call
is nested just one function deep), everything works great.  I'm not
thrilled with forcing initialization at each start but I can't find a
better place to do it.

This does not help my segfaulting acquaintance (whom I wlll hereafter
refer to as jsunn) though.  I still think use of the interface in the
ftplugin should be limited to Windows.

Cheers,

Tim

From jason at indelicate.net  Tue Jan 23 14:40:02 2007
From: jason at indelicate.net (Jason LaRiviere)
Date: Tue, 23 Jan 2007 13:40:02 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B65F2C.2090105@hasno.info>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info> <20070123164516.GR5520@tpope.us>
	<45B65F2C.2090105@hasno.info>
Message-ID: <20070123194002.GK13348@indelicate.net>

Mark Guzman wrote:
> Tim Pope wrote:
> > Very odd.  rails.vim only recently started making use of the Vim-Ruby
> > interface.  The next revision will limit it to Windows only; perhaps I
> > should just do away with it all together (although I can't reproduce
> > any of these problems on Windows).  For the record, rails.vim uses it
> > in two places which previously used system():
> >
> > 1. require 'action_view' and extract a list of helper methods from it.
> >
> > 2. require 'yaml' and parse database.yml (only if dbext.vim is installed)
> >
> > On my system, I observe the following behaviors.  If the first is
> > performed, with or without the second. the stack overflow error starts
> > to be seen when completion is used.  If the second is performed
> > *without* the first, Vim will segfault when completion is used.
> > Things work fine if you :ruby require the same libraries manually, and
> > things still break if all rails.vim does is require the same
> > libraries.  Perhaps is has something to do with how things are nested
> > in a Vim function.  I will investigate further.
> >
> >   
> Weird, I'll see if i can be of any help. If it's a problem w/ the 
> vim-ruby bridge it'd be nice if we could fix it.
> >> Have you actually experienced a crash due to the path discovery code?
> >>     
> >
> > No.  This user claims to have, even without rails.vim loaded.
> > g:rubycomplete_rails might have been set.
> >   
> Who? Can you forward on the email so I can find out more? The rails 
> support stuff is pretty intense since it's loading rails into the env.
>   --mark

I believe we're discussing my particular problem here. I've had some
conference with Tim Pope about the aforementioned.

Here's my situation:
brand new macbook, osx 10.4.8

ruby 1.8.5. from source, --enable-pthreads
--with-readline-dir=/usr/local --prefix=/usr/local

vim 7.0.183 from source, --disable-gui --enable-rubyinterp
--prefix=/usr/local

rails 1.2.1, rubygems 0.9.0

Before Tim fixed up his rails.vim, as noted, vim trapped and died:
(from gdb)
dyld: Symbol not found: _rb_path2class
Referenced from:
/usr/local/lib/ruby/1.8.i686-darwin8.8.3/digest/sha2.bundle

The stock rubycomplete.vim works, as long as I don't attempt a rails
completion, straight up ruby omni works. The most recent
rubycomplete.vim from cvs kill it straight away, as did the version of
ftplugin before tpope messed with it.

As it stands, with the recently updated ftplugin, rails, and stock
rubycomplete vim scripts, I'm alright, as long as I don't attempt a
rails completion or try including 'rubygems' anywhere. Manually doing
:ruby require 'rubygems' traps vim immediately, always with the same
error from gdb.

I'm currently hassling friends with osx to attempt a replication of this
issue, as I'm quite sure it's the build of ruby within osx.

Thanks,
Jason.
-- 
GPG/PGP key ID: 0x3A410DBD | http://pgp.mit.edu
7B3F 4505 7D9A 7FDE 83C9  52C2 4909 59B9 3A41 0DBD

From segfault at hasno.info  Tue Jan 23 14:43:55 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 14:43:55 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123193239.GS5520@tpope.us>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us> <20070123193239.GS5520@tpope.us>
Message-ID: <45B6657B.4070705@hasno.info>

Tim Pope wrote:
> A little further investigation reveals the trigger.  The first time
> the Ruby interface is used is significant.  If it is used at the top
> level, all is well.  If it is nested deep inside several function
> calls, this seems to reduce the available stack space to Ruby.  Note
> that only there very first call is relevant.  If I add
>
> silent! ruby nil
>
> to the plugin initialization function of rails.vim (so that the call
> is nested just one function deep), everything works great.  I'm not
> thrilled with forcing initialization at each start but I can't find a
> better place to do it.
>   
I wonder if the same thing happens with the other interfaces.
> This does not help my segfaulting acquaintance (whom I wlll hereafter
> refer to as jsunn) though.  I still think use of the interface in the
> ftplugin should be limited to Windows.
>   
I'm fine with that, it doesn't really bother me anywhere other than 
windows. Though wouldn't that handle the initialization issue for you?

Thanks Tim
  --mark

From vim-ruby-devel at tpope.info  Tue Jan 23 14:50:29 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 23 Jan 2007 13:50:29 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B6657B.4070705@hasno.info>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info> <20070123164516.GR5520@tpope.us>
	<20070123193239.GS5520@tpope.us> <45B6657B.4070705@hasno.info>
Message-ID: <20070123195029.GT5520@tpope.us>

On Tue, Jan 23, 2007 at 02:43:55PM -0500, Mark Guzman wrote:
> Tim Pope wrote:
> > This does not help my segfaulting acquaintance (whom I wlll hereafter
> > refer to as jsunn) though.  I still think use of the interface in the
> > ftplugin should be limited to Windows.
> >   
> I'm fine with that, it doesn't really bother me anywhere other than 
> windows. Though wouldn't that handle the initialization issue for you?

In many circumstances, but it's not 100%.  If, for example, database.yml
file is loaded first, the ruby ftplugin won't be called but rails.vim
will be.

Cheers,

Tim

From segfault at hasno.info  Tue Jan 23 14:54:28 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 14:54:28 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123194002.GK13348@indelicate.net>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>	<45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net>
Message-ID: <45B667F4.2070602@hasno.info>

Jason LaRiviere wrote:
>
> I believe we're discussing my particular problem here. I've had some
> conference with Tim Pope about the aforementioned.
>
> Here's my situation:
> brand new macbook, osx 10.4.8
>
> ruby 1.8.5. from source, --enable-pthreads
> --with-readline-dir=/usr/local --prefix=/usr/local
>
> vim 7.0.183 from source, --disable-gui --enable-rubyinterp
> --prefix=/usr/local
>
> rails 1.2.1, rubygems 0.9.0
>
> Before Tim fixed up his rails.vim, as noted, vim trapped and died:
> (from gdb)
> dyld: Symbol not found: _rb_path2class
> Referenced from:
> /usr/local/lib/ruby/1.8.i686-darwin8.8.3/digest/sha2.bundle
>
> The stock rubycomplete.vim works, as long as I don't attempt a rails
> completion, straight up ruby omni works. The most recent
> rubycomplete.vim from cvs kill it straight away, as did the version of
> ftplugin before tpope messed with it.
>
> As it stands, with the recently updated ftplugin, rails, and stock
> rubycomplete vim scripts, I'm alright, as long as I don't attempt a
> rails completion or try including 'rubygems' anywhere. Manually doing
> :ruby require 'rubygems' traps vim immediately, always with the same
> error from gdb.
>
> I'm currently hassling friends with osx to attempt a replication of this
> issue, as I'm quite sure it's the build of ruby within osx.
>
>   
Have you tried this without having rails.vim in the plugins directory? 
AFAIK plugins are loaded before ftplugin is run... I am testing on the 
same platform, the only difference being that I used macports to build 
both ruby and vim.
  --mark

From jason at indelicate.net  Tue Jan 23 15:16:00 2007
From: jason at indelicate.net (Jason LaRiviere)
Date: Tue, 23 Jan 2007 14:16:00 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B667F4.2070602@hasno.info>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info> <20070123164516.GR5520@tpope.us>
	<45B65F2C.2090105@hasno.info> <20070123194002.GK13348@indelicate.net>
	<45B667F4.2070602@hasno.info>
Message-ID: <20070123201600.GL13348@indelicate.net>

Mark Guzman wrote:
> Have you tried this without having rails.vim in the plugins directory? 
> AFAIK plugins are loaded before ftplugin is run... I am testing on the 
> same platform, the only difference being that I used macports to build 
> both ruby and vim.
>   --mark

Just did, same result. In fact, I emptied scripts/ completely, and :ruby
require 'rubygems' still segfaults vim. Hard to say about ftplugin, as
Tim fixed it so it doesn't segfault at startup anymore, as it used to.
But before he got at it, merely opening a file with that ftplugin
crashed vim in the same way.

Also, fwiw, I don't see any of this behaviour on my openbsd machines,
with the same .vim/ from cvs.
-- 
GPG/PGP key ID: 0x3A410DBD | http://pgp.mit.edu
7B3F 4505 7D9A 7FDE 83C9  52C2 4909 59B9 3A41 0DBD

From segfault at hasno.info  Tue Jan 23 15:16:42 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 15:16:42 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123195029.GT5520@tpope.us>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>	<20070123193239.GS5520@tpope.us>
	<45B6657B.4070705@hasno.info> <20070123195029.GT5520@tpope.us>
Message-ID: <45B66D2A.6030601@hasno.info>


Tim Pope wrote:
> In many circumstances, but it's not 100%.  If, for example, database.yml
> file is loaded first, the ruby ftplugin won't be called but rails.vim
> will be.
>   
I checked the load order information after that, and it seems that 
plugins get loaded before ftplugins.
  --mark

From segfault at hasno.info  Tue Jan 23 15:31:36 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 15:31:36 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123201600.GL13348@indelicate.net>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>	<45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net>	<45B667F4.2070602@hasno.info>
	<20070123201600.GL13348@indelicate.net>
Message-ID: <45B670A8.7030107@hasno.info>

Jason LaRiviere wrote:
> Mark Guzman wrote:
>   
>> Have you tried this without having rails.vim in the plugins directory? 
>> AFAIK plugins are loaded before ftplugin is run... I am testing on the 
>> same platform, the only difference being that I used macports to build 
>> both ruby and vim.
>>   --mark
>>     
>
> Just did, same result. In fact, I emptied scripts/ completely, and :ruby
> require 'rubygems' still segfaults vim. Hard to say about ftplugin, as
> Tim fixed it so it doesn't segfault at startup anymore, as it used to.
> But before he got at it, merely opening a file with that ftplugin
> crashed vim in the same way.
>
> Also, fwiw, I don't see any of this behaviour on my openbsd machines,
> with the same .vim/ from cvs.
>   
Can you get me an strace?
  --mark

From segfault at hasno.info  Tue Jan 23 15:32:51 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 15:32:51 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123201600.GL13348@indelicate.net>
References: <456FD03E.7090009@hasno.info>	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>	<45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net>	<45B667F4.2070602@hasno.info>
	<20070123201600.GL13348@indelicate.net>
Message-ID: <45B670F3.9020309@hasno.info>

Jason LaRiviere wrote:
> Mark Guzman wrote:
>   
>> Have you tried this without having rails.vim in the plugins directory? 
>> AFAIK plugins are loaded before ftplugin is run... I am testing on the 
>> same platform, the only difference being that I used macports to build 
>> both ruby and vim.
>>   --mark
>>     
>
> Just did, same result. In fact, I emptied scripts/ completely, and :ruby
> require 'rubygems' still segfaults vim. Hard to say about ftplugin, as
> Tim fixed it so it doesn't segfault at startup anymore, as it used to.
> But before he got at it, merely opening a file with that ftplugin
> crashed vim in the same way.
>
> Also, fwiw, I don't see any of this behaviour on my openbsd machines,
> with the same .vim/ from cvs.
>   
A core would be nice too :)
  --mark

From jason at indelicate.net  Tue Jan 23 15:53:35 2007
From: jason at indelicate.net (Jason LaRiviere)
Date: Tue, 23 Jan 2007 14:53:35 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B670A8.7030107@hasno.info>
References: <20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
	<45B55D83.4030502@hasno.info> <20070123164516.GR5520@tpope.us>
	<45B65F2C.2090105@hasno.info> <20070123194002.GK13348@indelicate.net>
	<45B667F4.2070602@hasno.info> <20070123201600.GL13348@indelicate.net>
	<45B670A8.7030107@hasno.info>
Message-ID: <20070123205335.GM13348@indelicate.net>

Mark Guzman wrote:
> Can you get me an strace?
>   --mark

Well, I can get you a ktrace. :)
http://indelicate.net/misc/vim.ktrace.out

Sorta the same as strace, but with 20% more suck.
-- 
GPG/PGP key ID: 0x3A410DBD | http://pgp.mit.edu
7B3F 4505 7D9A 7FDE 83C9  52C2 4909 59B9 3A41 0DBD

From segfault at hasno.info  Tue Jan 23 16:30:49 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 23 Jan 2007 16:30:49 -0500
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070123205335.GM13348@indelicate.net>
References: <20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>	<4577388E.10800@hasno.info>
	<20070122191524.GQ5520@tpope.us>	<45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us>	<45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net>	<45B667F4.2070602@hasno.info>
	<20070123201600.GL13348@indelicate.net>	<45B670A8.7030107@hasno.info>
	<20070123205335.GM13348@indelicate.net>
Message-ID: <45B67E89.1030406@hasno.info>

Jason LaRiviere wrote:
> Mark Guzman wrote:
>   
>> Can you get me an strace?
>>   --mark
>>     
>
> Well, I can get you a ktrace. :)
> http://indelicate.net/misc/vim.ktrace.out
>
> Sorta the same as strace, but with 20% more suck.
>   
Sweet! Thanks.
  --mark

From jason at indelicate.net  Wed Jan 24 02:56:53 2007
From: jason at indelicate.net (Jason LaRiviere)
Date: Wed, 24 Jan 2007 01:56:53 -0600
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <45B67E89.1030406@hasno.info>
References: <20070122191524.GQ5520@tpope.us> <45B55D83.4030502@hasno.info>
	<20070123164516.GR5520@tpope.us> <45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net> <45B667F4.2070602@hasno.info>
	<20070123201600.GL13348@indelicate.net> <45B670A8.7030107@hasno.info>
	<20070123205335.GM13348@indelicate.net> <45B67E89.1030406@hasno.info>
Message-ID: <20070124075653.GN13348@indelicate.net>

Mark Guzman wrote:
> Sweet! Thanks.
>   --mark

I think we can put this to bed and chalk it up to a wonky ruby build.
At your request, I took a look at the macports build file for ruby, and
noticed some differences in CFLAGS and CPPFLAGS.

Left to its own devices, it was using CFLAGS=-O2, and nothing in
CPPFLAGS.

I forced each to use -O, as per the macports build file, and rebuilt
ruby, then vim.

Fixed. \o/ 

Terribly sorry to have wasted anyone's time with a problem that clearly
ended up not having anything to do with vim.

Regards,
Jason.

-- 
GPG/PGP key ID: 0x3A410DBD | http://pgp.mit.edu
7B3F 4505 7D9A 7FDE 83C9  52C2 4909 59B9 3A41 0DBD

From gsinclair at gmail.com  Wed Jan 24 19:04:17 2007
From: gsinclair at gmail.com (Gavin Sinclair)
Date: Thu, 25 Jan 2007 11:04:17 +1100
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070124075653.GN13348@indelicate.net>
References: <20070122191524.GQ5520@tpope.us> <20070123164516.GR5520@tpope.us>
	<45B65F2C.2090105@hasno.info>
	<20070123194002.GK13348@indelicate.net>
	<45B667F4.2070602@hasno.info> <20070123201600.GL13348@indelicate.net>
	<45B670A8.7030107@hasno.info> <20070123205335.GM13348@indelicate.net>
	<45B67E89.1030406@hasno.info> <20070124075653.GN13348@indelicate.net>
Message-ID: <a76b05c10701241604q2c34444at520bc0fe6550d4d6@mail.gmail.com>

On 1/24/07, Jason LaRiviere <jason at indelicate.net> wrote:

> Fixed. \o/
>
> Terribly sorry to have wasted anyone's time with a problem that clearly
> ended up not having anything to do with vim.

Sometimes these experiences can be educational for all involved, so
don't worry :)

Cheers,
Gavin

From jcroneme at thoughtworks.com  Fri Jan 26 09:04:33 2007
From: jcroneme at thoughtworks.com (Josh Cronemeyer)
Date: Fri, 26 Jan 2007 08:04:33 -0600
Subject: omnicomplete stacktrace
Message-ID: <OFDE9ED13D.1724E3D4-ON8625726F.004CE20F-8625726F.004D4235@thoughtworks.com>

Hi I'm trying to use the rubycomplete function.  I'm setup like this: 
http://t0fuu.wordpress.com/2006/09/11/using-vim-for-editing-ruby/
When I do Ctrl-x Ctrl-o I get the following:  "Error detected while 
processing function rubycomplete#Complete line 22: SystemStackError: 
(eval):203:in `clean sel`: stack level too deep"
Any ideas what I might be doing wrong?

Thanks,

Josh Cronemeyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/vim-ruby-devel/attachments/20070126/3a17fd4b/attachment.html 

From vim-ruby-devel at tpope.info  Fri Jan 26 11:49:07 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 26 Jan 2007 10:49:07 -0600
Subject: omnicomplete stacktrace
In-Reply-To: <OFDE9ED13D.1724E3D4-ON8625726F.004CE20F-8625726F.004D4235@thoughtworks.com>
References: <OFDE9ED13D.1724E3D4-ON8625726F.004CE20F-8625726F.004D4235@thoughtworks.com>
Message-ID: <20070126164906.GU5520@tpope.us>

On Fri, Jan 26, 2007 at 08:04:33AM -0600, Josh Cronemeyer wrote:
> Hi I'm trying to use the rubycomplete function.  I'm setup like this: 
> http://t0fuu.wordpress.com/2006/09/11/using-vim-for-editing-ruby/
> When I do Ctrl-x Ctrl-o I get the following:  "Error detected while 
> processing function rubycomplete#Complete line 22: SystemStackError: 
> (eval):203:in `clean sel`: stack level too deep"
> Any ideas what I might be doing wrong?

The cause of this just recently discovered and fixed.  Try the latest
rails.vim from subversion:

http://svn.tpope.net/rails/vim/railsvim

I suppose a new rails.vim release is in line, given that quite a few
people are affected.  Please confirm it works for you.

Cheers,

Tim Pope

From dougkearns at gmail.com  Wed Jan 31 06:31:46 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 31 Jan 2007 22:31:46 +1100
Subject: s:rubypath in ftplugin/ruby.vim
In-Reply-To: <20070122191524.GQ5520@tpope.us>
References: <456FD03E.7090009@hasno.info>
	<20061204215053.GG3187@cpe-121-209-236-2.nsw.bigpond.net.au>
	<4577388E.10800@hasno.info> <20070122191524.GQ5520@tpope.us>
Message-ID: <20070131113146.GB32215@localhost.localdomain>

On Mon, Jan 22, 2007 at 01:15:24PM -0600, Tim Pope wrote:

<snip>
 
> Any news about a release? :)

I'm back on deck now after a few months in the boondocks.

I've just got a couple of patches to test then I'm ready if everyone
else still is... ;-)

Regards,
Doug

From dougkearns at gmail.com  Wed Jan 31 06:48:49 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 31 Jan 2007 22:48:49 +1100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <1168464330.4245.89.camel@dads>
References: <1168464330.4245.89.camel@dads>
Message-ID: <20070131114849.GC32215@localhost.localdomain>

G'day Rob,

On Wed, Jan 10, 2007 at 04:25:30PM -0500, Rob Muhlestein wrote:
> Downloaded the latest ruby-vim but still don't see the following
> keywords in ruby.vim. I've added them to my own but would a patch to the
> ruby.vim in this project be worth it? If so, I'll submit what I have.
> 
> RSpec DSL:
> 
>   context
>   context_setup
>   setup
>   specify
>   context_teardown
>   teardown
> 
> GEMS DSL:
>   require_gem
>   (more I'll look up if worth it)
> 
> These DSLs are pretty mainstream and I think would be worth inclusion
> for much the same reason that the Rails DSL addition to ruby also seems
> worth it.

Personally I'd prefer these (with the exception of require_gem/gem) were
not added to ruby.vim.  I think that file should simply be for
highlighting the 'core language'.

Regards,
Doug

From now at bitwi.se  Wed Jan 31 08:02:18 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Wed, 31 Jan 2007 14:02:18 +0100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <20070131114849.GC32215@localhost.localdomain>
References: <1168464330.4245.89.camel@dads>
	<20070131114849.GC32215@localhost.localdomain>
Message-ID: <dbfc82860701310502w3da957f7q7aa84c4213f81ce0@mail.gmail.com>

On 1/31/07, Doug Kearns <dougkearns at gmail.com> wrote:
> G'day Rob,
>
> On Wed, Jan 10, 2007 at 04:25:30PM -0500, Rob Muhlestein wrote:
> > Downloaded the latest ruby-vim but still don't see the following
> > keywords in ruby.vim. I've added them to my own but would a patch to the
> > ruby.vim in this project be worth it? If so, I'll submit what I have.
> >
> > RSpec DSL:
> >
> >   context
> >   context_setup
> >   setup
> >   specify
> >   context_teardown
> >   teardown
> >
> > GEMS DSL:
> >   require_gem
> >   (more I'll look up if worth it)
> >
> > These DSLs are pretty mainstream and I think would be worth inclusion
> > for much the same reason that the Rails DSL addition to ruby also seems
> > worth it.
>
> Personally I'd prefer these (with the exception of require_gem/gem) were
> not added to ruby.vim.  I think that file should simply be for
> highlighting the 'core language'.

Yes, thank you.

A couple of months ago it would have been assert_X that someone would
have wanted.  What will the scenario be in six months?

Please add stuff like this in your after/syntax/ruby.vim file instead.

  nikolai

From hgs at dmu.ac.uk  Wed Jan 31 08:18:12 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Wed, 31 Jan 2007 13:18:12 +0000 (WET)
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <dbfc82860701310502w3da957f7q7aa84c4213f81ce0@mail.gmail.com>
References: <1168464330.4245.89.camel@dads>
	<20070131114849.GC32215@localhost.localdomain>
	<dbfc82860701310502w3da957f7q7aa84c4213f81ce0@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0701311310580.17858@brains.eng.cse.dmu.ac.uk>

On Wed, 31 Jan 2007, Nikolai Weibull wrote:

> On 1/31/07, Doug Kearns <dougkearns at gmail.com> wrote:
> > G'day Rob,
> >
> > On Wed, Jan 10, 2007 at 04:25:30PM -0500, Rob Muhlestein wrote:
> > > Downloaded the latest ruby-vim but still don't see the following
> > > keywords in ruby.vim. I've added them to my own but would a patch to the
        [Rspec, gem keywords and comments trimmed]
> > Personally I'd prefer these (with the exception of require_gem/gem) were
> > not added to ruby.vim.  I think that file should simply be for
> > highlighting the 'core language'.
> 
> Yes, thank you.

I'd agree with leaving them out of the ruby filetype for the
reason you give here...
> 
> A couple of months ago it would have been assert_X that someone would
> have wanted.  What will the scenario be in six months?
> 
> Please add stuff like this in your after/syntax/ruby.vim file instead.

... but it might be useful to distribute recipies for after/syntax/ruby
so that people can add them correctly and easily.  Maybe vim tips
on the vim site is sufficient, but it would be nice to keep them near
the ruby vim stuff -- "All the ruby vim mods you could want in one box!".
> 
>   nikolai

        Hugh

From sroberts at uniserve.com  Wed Jan 31 17:42:58 2007
From: sroberts at uniserve.com (Sam Roberts)
Date: Wed, 31 Jan 2007 14:42:58 -0800
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <20070131114849.GC32215@localhost.localdomain>
References: <1168464330.4245.89.camel@dads>
	<20070131114849.GC32215@localhost.localdomain>
Message-ID: <20070131224258.GA24612@pebble>

On Wed, Jan 31, 2007 at 10:48:49PM +1100, Doug Kearns wrote:
> On Wed, Jan 10, 2007 at 04:25:30PM -0500, Rob Muhlestein wrote:
> > Downloaded the latest ruby-vim but still don't see the following
> > keywords in ruby.vim. I've added them to my own but would a patch to the
> > ruby.vim in this project be worth it? If so, I'll submit what I have.
> > 
> > RSpec DSL:
> > 
> > GEMS DSL:
> >   require_gem

> Personally I'd prefer these (with the exception of require_gem/gem) were
> not added to ruby.vim.  I think that file should simply be for
> highlighting the 'core language'.

I agree.  I don't really mind that more and more functions in my
libraries show up in pretty lights on my screen, but I do think its a
bit odd.  Having functions from some libraries hightlighted in vim.ruby
based on popularity seems weird to me. Lots of libraries use "setup" as
a method, and the highlighting is going to get more and more
inconsistent.

Is there a way to load particular sets of highlighting depending on what
kind of ruby file is being edited? That would be nice. Or perhaps extra
files that if they are copied to the local .vim directory, they take
effect for that user?

Cheers,
Sam


From rob at muhlestein.net  Wed Jan 31 21:49:48 2007
From: rob at muhlestein.net (Rob Muhlestein)
Date: Wed, 31 Jan 2007 21:49:48 -0500
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <20070131224258.GA24612@pebble>
References: <1168464330.4245.89.camel@dads>
	<20070131114849.GC32215@localhost.localdomain>
	<20070131224258.GA24612@pebble>
Message-ID: <1170298188.7549.5.camel@localhost.localdomain>

On Wed, 2007-01-31 at 14:42 -0800, Sam Roberts wrote:
> On Wed, Jan 31, 2007 at 10:48:49PM +1100, Doug Kearns wrote:
> > On Wed, Jan 10, 2007 at 04:25:30PM -0500, Rob Muhlestein wrote:
> > > Downloaded the latest ruby-vim but still don't see the following
> > > keywords in ruby.vim. I've added them to my own but would a patch to the
> > > ruby.vim in this project be worth it? If so, I'll submit what I have.
> > > 
> > > RSpec DSL:
> > > 
> > > GEMS DSL:
> > >   require_gem
> 
> > Personally I'd prefer these (with the exception of require_gem/gem) were
> > not added to ruby.vim.  I think that file should simply be for
> > highlighting the 'core language'.
> 
> I agree.  I don't really mind that more and more functions in my
> libraries show up in pretty lights on my screen, but I do think its a
> bit odd.  Having functions from some libraries hightlighted in vim.ruby
> based on popularity seems weird to me. Lots of libraries use "setup" as
> a method, and the highlighting is going to get more and more
> inconsistent.
> 
> Is there a way to load particular sets of highlighting depending on what
> kind of ruby file is being edited? That would be nice. Or perhaps extra
> files that if they are copied to the local .vim directory, they take
> effect for that user

Yeah, this is so trivial I haven't even thought about it any longer.
It's in my ruby.vim and that's good enough. There aren't enough keywords
to warrant a patch or a rspec.vim, which is a waiste anyway cause can't
easily detect syntax context since rpecs are all .rb files (got flamed
to death even asking if .spec might be something to consider).

-- 
Rob Muhlestein
http://rob.muhlestein.net


From dougkearns at gmail.com  Wed Feb  7 08:47:40 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Thu, 8 Feb 2007 00:47:40 +1100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <1168607652.18820.9.camel@dads>
References: <1168464330.4245.89.camel@dads>
	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
	<1168607652.18820.9.camel@dads>
Message-ID: <20070207134740.GE3402@localhost.localdomain>

On Fri, Jan 12, 2007 at 08:14:11AM -0500, Rob Muhlestein wrote:

<snip>

> Any chance of moving project to SVN?

I'm completely indifferent but you're the second person to mention it.
Anyone else have any feelings either way?

Regards,
Doug

From now at bitwi.se  Wed Feb  7 11:21:19 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Wed, 7 Feb 2007 17:21:19 +0100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <20070207134740.GE3402@localhost.localdomain>
References: <1168464330.4245.89.camel@dads>
	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
	<1168607652.18820.9.camel@dads>
	<20070207134740.GE3402@localhost.localdomain>
Message-ID: <dbfc82860702070821w6e50a0e7r4e0bad0541c1b012@mail.gmail.com>

On 2/7/07, Doug Kearns <dougkearns at gmail.com> wrote:
> On Fri, Jan 12, 2007 at 08:14:11AM -0500, Rob Muhlestein wrote:

> > Any chance of moving project to SVN?

> I'm completely indifferent but you're the second person to mention it.
> Anyone else have any feelings either way?

Git.

  nikolai

From segfault at hasno.info  Wed Feb  7 11:52:45 2007
From: segfault at hasno.info (Mark Guzman)
Date: Wed, 07 Feb 2007 11:52:45 -0500
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <20070207134740.GE3402@localhost.localdomain>
References: <1168464330.4245.89.camel@dads>	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>	<1168607652.18820.9.camel@dads>
	<20070207134740.GE3402@localhost.localdomain>
Message-ID: <45CA03DD.3030508@hasno.info>

Doug Kearns wrote:
> I'm completely indifferent but you're the second person to mention it.
> Anyone else have any feelings either way?
>   
svn.
  --mark

From hgs at dmu.ac.uk  Wed Feb  7 12:21:36 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Wed, 7 Feb 2007 17:21:36 +0000 (WET)
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <dbfc82860702070821w6e50a0e7r4e0bad0541c1b012@mail.gmail.com>
References: <1168464330.4245.89.camel@dads>
	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
	<1168607652.18820.9.camel@dads>
	<20070207134740.GE3402@localhost.localdomain>
	<dbfc82860702070821w6e50a0e7r4e0bad0541c1b012@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0702071707370.4061@brains.eng.cse.dmu.ac.uk>

On Wed, 7 Feb 2007, Nikolai Weibull wrote:

> On 2/7/07, Doug Kearns <dougkearns at gmail.com> wrote:
> > On Fri, Jan 12, 2007 at 08:14:11AM -0500, Rob Muhlestein wrote:
> 
> > > Any chance of moving project to SVN?
> 
> > I'm completely indifferent but you're the second person to mention it.
> > Anyone else have any feelings either way?
> 
> Git.

:-) In British English that is a term of abuse! Given the context I
know it's not in this thread...

I can't build svn on the suns here, and haven't installed the blastwave.org
version yet, so I have a route out of that, if needed.

I don't suppose anyone has created a unified interface for all this?
There are so many flavours to chose from (all the obove, "moving over
to the DARCS side", etc).  The good thing about standards is anyone
can make their own, as someone's .sig used to say.

Are there any clear technical advantages of ... whatever?  ISTR that SVN
handles directorires better than CVS, and CVS handles renames better
than RCS, but where things are in this field now I don't know. With
them being open source I expect theres a bit of crossover and mutation
going on.
> 
>   nikolai

        Hugh

From now at bitwi.se  Wed Feb  7 13:28:36 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Wed, 7 Feb 2007 19:28:36 +0100
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <Pine.GSO.4.64.0702071707370.4061@brains.eng.cse.dmu.ac.uk>
References: <1168464330.4245.89.camel@dads>
	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>
	<1168607652.18820.9.camel@dads>
	<20070207134740.GE3402@localhost.localdomain>
	<dbfc82860702070821w6e50a0e7r4e0bad0541c1b012@mail.gmail.com>
	<Pine.GSO.4.64.0702071707370.4061@brains.eng.cse.dmu.ac.uk>
Message-ID: <dbfc82860702071028j732db85dp840831dd0c359bb3@mail.gmail.com>

On 2/7/07, Hugh Sasse <hgs at dmu.ac.uk> wrote:
> On Wed, 7 Feb 2007, Nikolai Weibull wrote:
>
> > On 2/7/07, Doug Kearns <dougkearns at gmail.com> wrote:
> > > On Fri, Jan 12, 2007 at 08:14:11AM -0500, Rob Muhlestein wrote:
> >
> > > > Any chance of moving project to SVN?
> >
> > > I'm completely indifferent but you're the second person to mention it.
> > > Anyone else have any feelings either way?
> >
> > Git.
>
> :-) In British English that is a term of abuse! Given the context I
> know it's not in this thread...

Git.

(Only kidding.  I know about the words meaning.  But I wanted to keep
my answer short and to the point without any "I think we should use
Subversion because it has such a cool name" or "I think the developers
should use Bazaar because it's written in Python and I like Python and
my opinion matters even though I don't actually develop for vim-ruby
or anything but I want to download the bleeding-edge sources every
night and masturbate all over the new change-sets and since I only
have one hand free I'm not able to install another VCS".)

> Are there any clear technical advantages of ... whatever?  ISTR that SVN
> handles directorires better than CVS, and CVS handles renames better
> than RCS, but where things are in this field now I don't know. With
> them being open source I expect theres a bit of crossover and mutation
> going on.

Well, CVS is just plain bad.  SVN is just plain not much better.  For
this particular project, handling of renames is almost irrelevant, so
SVN doesn't offer anything relevant over CVS.  Going distributed is
nice, and Git is my favorite.  If there's actually going to be a
switch, I hope people take the time to look at the merits modern VCSs
offer.  And let me make my point very clear: SVN is /not/ a modern
VCS.

  nikolai

From segfault at hasno.info  Wed Feb  7 17:09:19 2007
From: segfault at hasno.info (Mark Guzman)
Date: Wed, 07 Feb 2007 17:09:19 -0500
Subject: RSpec and GEMS DSL Keyword Additions to ruby.vim?
In-Reply-To: <dbfc82860702071028j732db85dp840831dd0c359bb3@mail.gmail.com>
References: <1168464330.4245.89.camel@dads>	<a76b05c10701101754h55c64027j57846a5a53243836@mail.gmail.com>	<1168607652.18820.9.camel@dads>	<20070207134740.GE3402@localhost.localdomain>	<dbfc82860702070821w6e50a0e7r4e0bad0541c1b012@mail.gmail.com>	<Pine.GSO.4.64.0702071707370.4061@brains.eng.cse.dmu.ac.uk>
	<dbfc82860702071028j732db85dp840831dd0c359bb3@mail.gmail.com>
Message-ID: <45CA4E0F.6050806@hasno.info>

Nikolai Weibull wrote:
>
> Well, CVS is just plain bad.  SVN is just plain not much better.  For
> this particular project, handling of renames is almost irrelevant, so
> SVN doesn't offer anything relevant over CVS.  Going distributed is
> nice, and Git is my favorite.  If there's actually going to be a
> switch, I hope people take the time to look at the merits modern VCSs
> offer.  And let me make my point very clear: SVN is /not/ a modern
> VCS.
>   
SVN + SVK probably covers most of what you want out of vcs, with the 
exception of signing. SVN also changes the history from per-file to 
repository snapshots. I'm not entirely sure that this would help 
anything in our case. I'm reasonably agnostic, though it's worth noting 
that rubyforge doesn't support git,darcs,arch, or monotone currently 
(afaik).
  --mark

From dougkearns at gmail.com  Mon Feb 12 04:48:49 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 12 Feb 2007 20:48:49 +1100
Subject: Omni completion stack overflow
Message-ID: <20070212094849.GA6859@localhost.localdomain>

G'day all,

Can someone confirm for me that calling the omnifunc in an empty file
produces the following:

...
SystemStackError: (eval):7: stack level too deep
...


I'm also experiencing random(ie. I haven't had time to find the cause)
segfaults so I just want to check the above first.  Note that I'm not
using rails.vim so it may be different to the other recently fixed
problems.

Thanks,
Doug

From vim-ruby-devel at tpope.info  Mon Feb 12 10:10:54 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 12 Feb 2007 09:10:54 -0600
Subject: Omni completion stack overflow
In-Reply-To: <20070212094849.GA6859@localhost.localdomain>
References: <20070212094849.GA6859@localhost.localdomain>
Message-ID: <20070212151053.GB18070@tpope.us>

On Mon, Feb 12, 2007 at 08:48:49PM +1100, Doug Kearns wrote:
> G'day all,
> 
> Can someone confirm for me that calling the omnifunc in an empty file
> produces the following:
> 
> ...
> SystemStackError: (eval):7: stack level too deep
> ...

I cannot confirm this.  I simply get a list of top level objects,
starting with ARGF.

> I'm also experiencing random(ie. I haven't had time to find the cause)
> segfaults so I just want to check the above first.  Note that I'm not
> using rails.vim so it may be different to the other recently fixed
> problems.

Both stack overflows and segfaults can be caused by initializing the
ruby interface (the first time :ruby is used) in a sufficiently nested
context.  Try adding "silent! ruby nil" to your vimrc.  If this
hides the problem, the true cause is some other plugin initializing
the ruby interface.

Cheers,

Tim

From jason at indelicate.net  Mon Feb 12 23:05:02 2007
From: jason at indelicate.net (Jason LaRiviere)
Date: Mon, 12 Feb 2007 22:05:02 -0600
Subject: Omni completion stack overflow
In-Reply-To: <20070212151053.GB18070@tpope.us>
References: <20070212094849.GA6859@localhost.localdomain>
	<20070212151053.GB18070@tpope.us>
Message-ID: <20070213040502.GB11994@indelicate.net>

Tim Pope wrote:
> I cannot confirm this.  I simply get a list of top level objects, starting
> with ARGF.
 
Yep, same here.

From dougkearns at gmail.com  Mon Feb 12 23:54:22 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 13 Feb 2007 15:54:22 +1100
Subject: Omni completion stack overflow
In-Reply-To: <20070212151053.GB18070@tpope.us>
References: <20070212094849.GA6859@localhost.localdomain>
	<20070212151053.GB18070@tpope.us>
Message-ID: <20070213045422.GB3347@localhost.localdomain>

On Mon, Feb 12, 2007 at 09:10:54AM -0600, Tim Pope wrote:
> On Mon, Feb 12, 2007 at 08:48:49PM +1100, Doug Kearns wrote:

<snip>
 
> > I'm also experiencing random(ie. I haven't had time to find the cause)
> > segfaults so I just want to check the above first.  Note that I'm not
> > using rails.vim so it may be different to the other recently fixed
> > problems.
> 
> Both stack overflows and segfaults can be caused by initializing the
> ruby interface (the first time :ruby is used) in a sufficiently nested
> context.  Try adding "silent! ruby nil" to your vimrc.  If this
> hides the problem, the true cause is some other plugin initializing
> the ruby interface.

Thanks for that, I managed to overlook your explanation in the
"s:rubypath in ftplugin/ruby.vim" thread.

Initializing the interface in my vimrc does seem to eliminate the
problem but running the omni completion script alone is enough to
trigger it (ie. when my ~/.vim contains only the vim-ruby runtime
files).

Has this general problem been reported 'upstream'?

Regards,
Doug

From segfault at hasno.info  Tue Feb 13 10:31:37 2007
From: segfault at hasno.info (Mark Guzman)
Date: Tue, 13 Feb 2007 10:31:37 -0500
Subject: Omni completion stack overflow
In-Reply-To: <20070213045422.GB3347@localhost.localdomain>
References: <20070212094849.GA6859@localhost.localdomain>	<20070212151053.GB18070@tpope.us>
	<20070213045422.GB3347@localhost.localdomain>
Message-ID: <45D1D9D9.3090109@hasno.info>

Doug Kearns wrote:
> Thanks for that, I managed to overlook your explanation in the
> "s:rubypath in ftplugin/ruby.vim" thread.
>
> Initializing the interface in my vimrc does seem to eliminate the
> problem but running the omni completion script alone is enough to
> trigger it (ie. when my ~/.vim contains only the vim-ruby runtime
> files).
>
> Has this general problem been reported 'upstream'?
>   
No, this hasn't been mentioned on vim-dev so far, I'll do so now.

So far it has all been related back to the stack issue, all of the 
people I've debugged with have had older versions of rails.vim installed.
  --mark


From vim-ruby-devel at tpope.info  Sun Feb 18 17:58:41 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sun, 18 Feb 2007 16:58:41 -0600
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
Message-ID: <20070218225841.GE18070@tpope.us>

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

From now at bitwi.se  Sun Feb 18 18:55:46 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Mon, 19 Feb 2007 00:55:46 +0100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070218225841.GE18070@tpope.us>
References: <20070218225841.GE18070@tpope.us>
Message-ID: <dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>

On 2/18/07, Tim Pope <vim-ruby-devel at tpope.info> 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

From now at bitwi.se  Sun Feb 18 19:04:58 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Mon, 19 Feb 2007 01:04:58 +0100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>
References: <20070218225841.GE18070@tpope.us>
	<dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>
Message-ID: <dbfc82860702181604p6f18d4c6q73edd9ad5d3257b@mail.gmail.com>

On 2/19/07, Nikolai Weibull <now at bitwi.se> 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

From dougkearns at gmail.com  Sun Feb 18 20:43:43 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 19 Feb 2007 12:43:43 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070218225841.GE18070@tpope.us>
References: <20070218225841.GE18070@tpope.us>
Message-ID: <20070219014343.GA6502@localhost.localdomain>

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

From vim-ruby-devel at tpope.info  Sun Feb 18 21:07:21 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sun, 18 Feb 2007 20:07:21 -0600
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070219014343.GA6502@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
Message-ID: <20070219020721.GF18070@tpope.us>

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.

From dougkearns at gmail.com  Sun Feb 18 21:08:56 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 19 Feb 2007 13:08:56 +1100
Subject: Omni completion stack overflow
In-Reply-To: <45D1D9D9.3090109@hasno.info>
References: <20070212094849.GA6859@localhost.localdomain>
	<20070212151053.GB18070@tpope.us>
	<20070213045422.GB3347@localhost.localdomain>
	<45D1D9D9.3090109@hasno.info>
Message-ID: <20070219020856.GA7166@localhost.localdomain>

On Tue, Feb 13, 2007 at 10:31:37AM -0500, Mark Guzman wrote:
> Doug Kearns wrote:
> > Thanks for that, I managed to overlook your explanation in the
> > "s:rubypath in ftplugin/ruby.vim" thread.
> >
> > Initializing the interface in my vimrc does seem to eliminate the
> > problem but running the omni completion script alone is enough to
> > trigger it (ie. when my ~/.vim contains only the vim-ruby runtime
> > files).
> >
> > Has this general problem been reported 'upstream'?
> >   
> No, this hasn't been mentioned on vim-dev so far, I'll do so now.

Thanks.
 
> So far it has all been related back to the stack issue, all of the 
> people I've debugged with have had older versions of rails.vim installed.

So am I the only one that can reproduce it with a clean Vim7
installation and the latest rubycomplete.vim?  I don't and never have
had rails.vim installed.  I've never even downloaded it. ;-)

Thanks,
Doug

From dougkearns at gmail.com  Sun Feb 18 20:48:36 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 19 Feb 2007 12:48:36 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>
References: <20070218225841.GE18070@tpope.us>
	<dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>
Message-ID: <20070219014836.GB6502@localhost.localdomain>

On Mon, Feb 19, 2007 at 12:55:46AM +0100, Nikolai Weibull wrote:
> On 2/18/07, Tim Pope <vim-ruby-devel at tpope.info> 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

From dougkearns at gmail.com  Sun Feb 18 22:01:50 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 19 Feb 2007 14:01:50 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070219014836.GB6502@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<dbfc82860702181555w24fc5866m62e2b6e6685b0171@mail.gmail.com>
	<20070219014836.GB6502@localhost.localdomain>
Message-ID: <20070219030150.GB7166@localhost.localdomain>

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 at tpope.info> 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

From dougkearns at gmail.com  Tue Feb 20 05:36:49 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 20 Feb 2007 21:36:49 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070219020721.GF18070@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
Message-ID: <20070220103649.GA15777@localhost.localdomain>

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

From dougkearns at gmail.com  Tue Feb 20 06:02:36 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 20 Feb 2007 22:02:36 +1100
Subject: Method definition highlighting
Message-ID: <20070220110236.GB15777@localhost.localdomain>

One of the reasons I'd temporarily forgotten that the current CVS wasn't
highlighting method names specially in method definitions is because
I've never liked it and have a local customization to prevent it.

I much prefer the "self" in:

def self.bar: end 

and the "Foo" in:

def Foo::bar; end

to be highlighted normally as rubyPseudoVariable, rubyConstant and
rubyLocalVariableOrMethod respectively rather than all of them being
highlighted as part of the artificial rubyFunction.

Does anyone else have any thoughts on this?

Regards,
Doug

From now at bitwi.se  Tue Feb 20 08:37:14 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Tue, 20 Feb 2007 14:37:14 +0100
Subject: Method definition highlighting
In-Reply-To: <20070220110236.GB15777@localhost.localdomain>
References: <20070220110236.GB15777@localhost.localdomain>
Message-ID: <dbfc82860702200537m40597f7asaf0c2e346c2806c0@mail.gmail.com>

On 2/20/07, Doug Kearns <dougkearns at gmail.com> wrote:
> One of the reasons I'd temporarily forgotten that the current CVS wasn't
> highlighting method names specially in method definitions is because
> I've never liked it and have a local customization to prevent it.
>
> I much prefer the "self" in:
>
> def self.bar: end
>
> and the "Foo" in:
>
> def Foo::bar; end
>
> to be highlighted normally as rubyPseudoVariable, rubyConstant and
> rubyLocalVariableOrMethod respectively rather than all of them being
> highlighted as part of the artificial rubyFunction.
>
> Does anyone else have any thoughts on this?

Can't remember if I have this disable as well, but highlighting self
does make sense, I think.

  nikolai

From vim-ruby-devel at tpope.info  Tue Feb 20 10:06:14 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 20 Feb 2007 09:06:14 -0600
Subject: Method definition highlighting
In-Reply-To: <dbfc82860702200537m40597f7asaf0c2e346c2806c0@mail.gmail.com>
References: <20070220110236.GB15777@localhost.localdomain>
	<dbfc82860702200537m40597f7asaf0c2e346c2806c0@mail.gmail.com>
Message-ID: <20070220150614.GA13167@tpope.us>

On Tue, Feb 20, 2007 at 02:37:14PM +0100, Nikolai Weibull wrote:
> Can't remember if I have this disable as well, but highlighting self
> does make sense, I think.

As you're no doubt aware, this is easy enough to accomplish by adding
a contains=rubyPseudoVariable to the appropriate line.

Cheers,

Tim

From vim-ruby-devel at tpope.info  Tue Feb 20 10:47:49 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 20 Feb 2007 09:47:49 -0600
Subject: Method definition highlighting
In-Reply-To: <20070220110236.GB15777@localhost.localdomain>
References: <20070220110236.GB15777@localhost.localdomain>
Message-ID: <20070220154749.GB13167@tpope.us>

On Tue, Feb 20, 2007 at 10:02:36PM +1100, Doug Kearns wrote:
> One of the reasons I'd temporarily forgotten that the current CVS wasn't
> highlighting method names specially in method definitions is because
> I've never liked it and have a local customization to prevent it.

Well, I can't say I ever particularly cared for it either, although it
is a common practice in Vim syntax highlighting.  Recently, I was
working on cloning "vibrant ink," a TextMate theme popular with Rails
users.  I added the rubyRegexp group in pursuit of this goal, which is
when I discovered the method name highlighting problem.  The theme in
question definitely looks better with such method name highlighting in
place.  So I'd at least like to keep it as a possibility.

> I much prefer the "self" in:
> 
> def self.bar: end 
> 
> and the "Foo" in:
> 
> def Foo::bar; end
> 
> to be highlighted normally as rubyPseudoVariable, rubyConstant and
> rubyLocalVariableOrMethod respectively rather than all of them being
> highlighted as part of the artificial rubyFunction.

Certainly a possibility.  To get the original effect, you'd have to
highlight all rubyLocalVariableOrMethod objects as Identifier, at
which point it'd probably be easier to highlight all the things that
aren't identifiers, as the screen is going to be saturated with it.

The amount of Identifier highlighting has always bothered me with the
current syntax file, actually.  I've tried disabling various things to
reduce it,  I'm happy to hack around it, but if while we're discussing
the subject, I figure I may as well throw my two cents into the pot.

One possible alternative is to move symbols into the Constant group
with numbers and strings.  This is more logical, in a way, and my
understanding is this is how TextMate works.  I do like having symbols
highlighted differently from strings, but from a theoretical
perspective it might make more sense to change String highlighting in
the color scheme instead.  Of course, this is not the default, so that
should be taken into account as well.

One group that doesn't get much play is Type.  Might it make more
sense to highlight constants (the capitalized kind) using this group.
This makes sense in cases where constants are classes.  In the cases
where they're not, well, keep in mind method declarations aren't
exactly PreProc either.  Making this change would basically allow us
to drop all the fanciness for module/class declarations as well.  The
colons would be different, but I don't think that's a bad thing.

Going on a real tangent now, it just occured to me a different use for
the Type group.  I find the variations of highlighting of "end" to be
extrordinarily useful.  Perhaps it would make sense to use the Type
group as a third color?  This strikes me as potentially very useful
for keeping things matched up.  You could also drop the module/class
fanciness in this case, as you'd want the class/module name to be
distinct from the introducing keyword.  I'm committing changes that
make this possible, but I am leaving the default highlighting for it
as PreProc until I have spent some time playing with it.

Cheers,

Tim

From vim-ruby-devel at tpope.info  Tue Feb 20 11:10:25 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 20 Feb 2007 10:10:25 -0600
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070220103649.GA15777@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
Message-ID: <20070220161024.GC13167@tpope.us>

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

From dougkearns at gmail.com  Wed Feb 21 01:29:53 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 21 Feb 2007 17:29:53 +1100
Subject: Method definition highlighting
In-Reply-To: <20070220154749.GB13167@tpope.us>
References: <20070220110236.GB15777@localhost.localdomain>
	<20070220154749.GB13167@tpope.us>
Message-ID: <20070221062953.GA5176@localhost.localdomain>

On Tue, Feb 20, 2007 at 09:47:49AM -0600, Tim Pope wrote:

<snip>
 
> The amount of Identifier highlighting has always bothered me with the
> current syntax file, actually.  I've tried disabling various things to
> reduce it,  I'm happy to hack around it, but if while we're discussing
> the subject, I figure I may as well throw my two cents into the pot.

I take it you've noticed ruby_no_identifiers?
 
<snip>

Regards,
Doug

From vim-ruby-devel at tpope.info  Wed Feb 21 01:49:24 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Wed, 21 Feb 2007 00:49:24 -0600
Subject: Method definition highlighting
In-Reply-To: <20070221062953.GA5176@localhost.localdomain>
References: <20070220110236.GB15777@localhost.localdomain>
	<20070220154749.GB13167@tpope.us>
	<20070221062953.GA5176@localhost.localdomain>
Message-ID: <20070221064924.GD13167@tpope.us>

On Wed, Feb 21, 2007 at 05:29:53PM +1100, Doug Kearns wrote:
> On Tue, Feb 20, 2007 at 09:47:49AM -0600, Tim Pope wrote:
> 
> <snip>
>  
> > The amount of Identifier highlighting has always bothered me with the
> > current syntax file, actually.  I've tried disabling various things to
> > reduce it,  I'm happy to hack around it, but if while we're discussing
> > the subject, I figure I may as well throw my two cents into the pot.
> 
> I take it you've noticed ruby_no_identifiers?

Sure.  It's rather all or nothing though.  Basically the only thing
left is method declaration highlighting then (and talk is of
eliminating that too).  Nonetheless, I can hack up just about anything
with enough :highlight rules, I'm just after the most sensible
possible defaults.  If I could only define sensible.

From boss at airbladesoftware.com  Wed Feb 21 06:19:44 2007
From: boss at airbladesoftware.com (Andrew Stewart)
Date: Wed, 21 Feb 2007 11:19:44 +0000
Subject: Method definition highlighting
In-Reply-To: <20070220154749.GB13167@tpope.us>
References: <20070220110236.GB15777@localhost.localdomain>
	<20070220154749.GB13167@tpope.us>
Message-ID: <06238001-79B8-49D3-AA60-D7E0FB0E58D6@airbladesoftware.com>


On 20 Feb 2007, at 15:47, Tim Pope wrote:
> Recently, I was
> working on cloning "vibrant ink," a TextMate theme popular with Rails
> users.

Any chance you could post your vibrant ink somewhere?

(Or should that be vimbrant ink?)

Thanks and regards,
Andy Stewart


From vim-ruby-devel at tpope.info  Wed Feb 21 10:08:13 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Wed, 21 Feb 2007 09:08:13 -0600
Subject: Method definition highlighting
In-Reply-To: <06238001-79B8-49D3-AA60-D7E0FB0E58D6@airbladesoftware.com>
References: <20070220110236.GB15777@localhost.localdomain>
	<20070220154749.GB13167@tpope.us>
	<06238001-79B8-49D3-AA60-D7E0FB0E58D6@airbladesoftware.com>
Message-ID: <20070221150812.GE13167@tpope.us>

On Wed, Feb 21, 2007 at 11:19:44AM +0000, Andrew Stewart wrote:
> Any chance you could post your vibrant ink somewhere?
> 
> (Or should that be vimbrant ink?)

I'm calling it vividchalk :).  I'm attaching what is still a work in
process.  I've decided not to go for an exact clone, after seeing how
the HTML highlighting in TextMate is rather ugly, in my opinion.
Feedback welcome; I'm still deciding how to do a lot of the Vim
specific stuff like the statusline and completion menu.

Cheers,

Tim
-------------- next part --------------
" Vim color scheme
" Name:         vividchalk.vim
" Maintainer:   Tim Pope <vim at tpope.info>
" Last Change:  19 Feb 2007

if has("gui_running")
    set background=dark
endif
hi clear
if exists("syntax_on")
   syntax reset
endif

let colors_name = "vividchalk"

" First two functions adapted from inkpot.vim

" map a urxvt cube number to an xterm-256 cube number
fun! s:M(a)
    return strpart("0135", a:a, 1) + 0
endfun

" map a urxvt colour to an xterm-256 colour
fun! s:X(a)
    if &t_Co == 88
        return a:a
    else
        if a:a == 8
            return 237
        elseif a:a < 16
            return a:a
        elseif a:a > 79
            return 232 + (3 * (a:a - 80))
        else
            let l:b = a:a - 16
            let l:x = l:b % 4
            let l:y = (l:b / 4) % 4
            let l:z = (l:b / 16)
            return 16 + s:M(l:x) + (6 * s:M(l:y)) + (36 * s:M(l:z))
        endif
    endif
endfun

function! s:choose(good,mediocre)
    if &t_Co != 88 && &t_Co != 256
        return a:mediocre
    else
        return s:X(a:good)
    endif
endfunction

function! s:hifg(group,guifg,ctermfg,backup)
    let ctermfg = s:choose(a:ctermfg,a:backup)
    exe "highlight ".a:group." guifg=".a:guifg." ctermfg=".ctermfg
endfunction

function! s:hibg(group,guibg,ctermbg,backup)
    let ctermbg = s:choose(a:ctermbg,a:backup)
    exe "highlight ".a:group." guibg=".a:guibg." ctermbg=".ctermbg
endfunction

hi link railsMethod         PreProc
hi link rubyDefine          Keyword
hi link rubySymbol          Constant
hi link rubyAccess          rubyMethod
hi link rubyAttribute       rubyMethod
hi link rubyEval            rubyMethod
hi link rubyException       rubyMethod
hi link rubyInclude         rubyMethod
hi link rubyStringDelimiter rubyString
hi link rubyRegexp          Regexp
hi link rubyRegexpDelimiter rubyRegexp
"hi link rubyConstant        Variable
"hi link rubyGlobalVariable  Variable
"hi link rubyClassVariable   Variable
"hi link rubyInstanceVariable Variable
hi link javascriptRegexpString  Regexp
hi link javascriptNumber        Number
hi link javascriptNull          Constant

if &background == "light" || has("gui_running")
    hi Normal guifg=White guibg=Black ctermfg=White ctermbg=Black
else
    hi Normal guifg=White guibg=Black ctermfg=White ctermbg=NONE
endif
highlight StatusLine   guifg=Black guibg=White gui=bold ctermfg=Black ctermbg=White cterm=bold
highlight StatusLineNC guifg=Black guibg=Grey gui=italic ctermfg=Black ctermbg=Grey cterm=none
highlight Cursor     guifg=Black guibg=White ctermfg=Black ctermbg=White
highlight CursorLine guibg=#333333 guifg=NONE
highlight CursorColumn guibg=#333333 guifg=NONE
highlight NonText    guifg=#404040 ctermfg=8
highlight SpecialKey guifg=#404040 ctermfg=8
highlight Directory  none
high link Directory  Identifier
highlight ErrorMsg   guibg=Red ctermbg=DarkRed guifg=NONE ctermfg=NONE
highlight Search     guibg=#101000 ctermbg=Black guifg=NONE ctermfg=NONE gui=italic cterm=underline
highlight MoreMsg    guifg=#00AA00 ctermfg=Green
highlight LineNr     guifg=#DDEEFF ctermfg=White
call s:hibg("LineNr"        ,"#222222",80,"DarkBlue")
highlight Question   none
high link Question   MoreMsg
highlight Title      guifg=Magenta ctermfg=Magenta
hi VisualNOS gui=none cterm=none
call s:hibg("Visual"        ,"#888888",83,"LightBlue")
call s:hibg("VisualNOS"     ,"#555555",81,"DarkBlue")
highlight WarningMsg    guifg=Red ctermfg=Red
highlight Folded        guibg=#1100aa ctermbg=DarkBlue
call s:hibg("Folded"        ,"#110077",17,"DarkBlue")
call s:hifg("Folded"        ,"#aaddee",63,"LightCyan")
highlight FoldColumn    none
high link FoldColumn    Folded
highlight Pmenu         guifg=White ctermfg=White gui=bold cterm=bold
highlight PmenuSel      guifg=White ctermfg=White gui=bold cterm=bold
call s:hibg("Pmenu"     ,"#000099",18,"Blue")
call s:hibg("PmenuSel"  ,"#5555ff",39,"DarkCyan")
highlight PmenuSbar     guibg=Grey ctermbg=Grey
highlight PmenuThumb    guibg=White ctermbg=White
highlight TabLine       gui=underline cterm=underline
call s:hifg("TabLine"   ,"#bbbbbb",85,"LightGrey")
call s:hibg("TabLine"   ,"#333333",80,"DarkGrey")
highlight TabLineSel    guifg=White guibg=Black ctermfg=White ctermbg=Black
highlight TabLineFill   gui=underline cterm=underline
call s:hifg("TabLineFill"   ,"#bbbbbb",85,"LightGrey")
call s:hibg("TabLineFill"   ,"#808080",83,"Grey")

hi Type gui=none
hi Statement gui=none
"highlight PreProc       guifg=#EDF8F9
call s:hifg("Comment"       ,"#9933CC",51,"DarkMagenta") " 92
call s:hifg("Constant"      ,"#339999",21,"DarkCyan") " 30
call s:hifg("rubyNumber"    ,"#CCFF33",60,"Yellow") " 190
call s:hifg("String"        ,"#66FF00",44,"LightGreen") " 82
call s:hifg("Identifier"    ,"#FFCC00",72,"Yellow") " 220
call s:hifg("Statement"     ,"#FF6600",68,"LightRed") " 202
call s:hifg("PreProc"       ,"#AAFFFF",47,"LightCyan") " 213
call s:hifg("Type"          ,"#999966",57,"Brown") " 101
call s:hifg("Special"       ,"#AAAAAA", 7,"Grey") " 7
call s:hifg("Regexp"        ,"#44B4CC",21,"DarkCyan") " 74
call s:hifg("rubyMethod"    ,"#DDE93D",77,"Yellow") " 191
"highlight railsMethod   guifg=#EE1122 ctermfg=1

From vim-ruby-devel at tpope.info  Thu Feb 22 12:32:36 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Thu, 22 Feb 2007 11:32:36 -0600
Subject: More syntax highlighting fun
Message-ID: <20070222173236.GA28979@tpope.us>

Okay, I've followed up on several changes I mentioned earlier.  Most
obvious is the change of rubyConstant to Type and rubySymbol to
Constant.  I think the first looks great and I strongly advocate
keeping it.  The second is more debatable but after trying it for a
few hours, I like it enough to tenatively add it.  I'm not trying to
force anything here but since nobody raised any objections, I figured
I'd be bold.

More important than a few cosmetic changes is the overhaul I gave to
method, module, and class definitions.  Try all of the following with
the new syntax file: 

def bar

def
  bar

def foo.bar

def @foo.bar

def Foo.bar

def Foo::bar

def self.bar

I think this will be win-win for everyone.  We can also turn off the
rubyFunction highlghting by default.  I'm not sure whether that's a
better choice so I left it on for now to demonstrate what's possible.

I also did a lot of clean-up, so let me know if you find anything that
breaks.  Things like if/unless are in the Conditional group and
while/until in the Loop group.  Oh, and I had to resolve a conflict
between Doug Kearns' and my ways of highlighting interpolated
variables.

Is there any reason for keeping around config options like
ruby_no_identifiers?  I don't see what

let ruby_no_identifiers = 1

offers over

hi link rubyIdentifer NONE

Both work fine in a vimrc.  Maybe this is a holdover from the 5.x
days?

Cheers,

Tim Pope

From dougkearns at gmail.com  Fri Feb 23 03:47:33 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 23 Feb 2007 19:47:33 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070219020721.GF18070@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
Message-ID: <20070223084733.GA11127@localhost.localdomain>

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, at rubyExtendedStringSpecial,rubyTodo nextgroup=rubyFunction fold
-  syn region rubyBlock start="\<class\>"  matchgroup=rubyDefine end="\<end\>" contains=ALLBUT, at rubyExtendedStringSpecial,rubyTodo nextgroup=rubyClass   fold
-  syn region rubyBlock start="\<module\>" matchgroup=rubyDefine end="\<end\>" contains=ALLBUT, at rubyExtendedStringSpecial,rubyTodo nextgroup=rubyModule  fold
+  syn region rubyBlock start="\<class\>"  matchgroup=rubyType   end="\<end\>" contains=ALLBUT, at rubyExtendedStringSpecial,rubyTodo nextgroup=rubyClass   fold
+  syn region rubyBlock start="\<module\>" matchgroup=rubyType   end="\<end\>" contains=ALLBUT, at rubyExtendedStringSpecial,rubyTodo nextgroup=rubyModule  fold

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

<snip>

Regards,
Doug

From dougkearns at gmail.com  Fri Feb 23 03:49:52 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 23 Feb 2007 19:49:52 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070223084733.GA11127@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070223084733.GA11127@localhost.localdomain>
Message-ID: <20070223084952.GB11127@localhost.localdomain>

Tim,

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

Regards,
Doug

From dougkearns at gmail.com  Fri Feb 23 03:56:03 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 23 Feb 2007 19:56:03 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070222173236.GA28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
Message-ID: <20070223085603.GC11127@localhost.localdomain>

On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:

<snip>

> More important than a few cosmetic changes is the overhaul I gave to
> method, module, and class definitions.

Thanks!

> Try all of the following with the new syntax file: 
> 
> def bar
> 
> def
>   bar
> 
> def foo.bar
> 
> def @foo.bar
> 
> def Foo.bar
> 
> def Foo::bar
> 
> def self.bar
> 
> I think this will be win-win for everyone.  We can also turn off the
> rubyFunction highlghting by default.  I'm not sure whether that's a
> better choice so I left it on for now to demonstrate what's possible.
> 
> I also did a lot of clean-up, so let me know if you find anything that
> breaks.

>From a quick inspection I noticed that the following are not being
highlighted properly:

def foo    ; end  # whitespace after method name
def foo(x);  end  # with parameter list (also empty list)
def Foo::bar;end  # specified with ::
def [];      end  # all redefinable operator methods

Otherwise it looks great.

> Things like if/unless are in the Conditional group and
> while/until in the Loop group.

Shouldn't that be the Repeat group?

> Oh, and I had to resolve a conflict
> between Doug Kearns' and my ways of highlighting interpolated
> variables.
> 
> Is there any reason for keeping around config options like
> ruby_no_identifiers?  I don't see what
> 
> let ruby_no_identifiers = 1
> 
> offers over
> 
> hi link rubyIdentifer NONE
> 
> Both work fine in a vimrc.  Maybe this is a holdover from the 5.x
> days?

It's really just the "Vim Way" of doing things - at least as I
understand it.  Generally the configuration options are there to allow
people to customize the highlighting without any need to understand
syntax files.  I think you'd be surprised how many people use Vim with
absolutely no understanding of these details. ;-)
 
Regards,
Doug

From hgs at dmu.ac.uk  Fri Feb 23 06:44:38 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Fri, 23 Feb 2007 11:44:38 +0000 (WET)
Subject: More syntax highlighting fun
In-Reply-To: <20070223085603.GC11127@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
Message-ID: <Pine.GSO.4.64.0702231140560.17252@brains.eng.cse.dmu.ac.uk>

On Fri, 23 Feb 2007, Doug Kearns wrote:

> It's really just the "Vim Way" of doing things - at least as I
> understand it.  Generally the configuration options are there to allow
> people to customize the highlighting without any need to understand
> syntax files.  I think you'd be surprised how many people use Vim with
> absolutely no understanding of these details. ;-)

Well, it *is* rather frightening when you prise the lid off.  I
still don't fully unerstand these things, even though I have meddled
with -- er, I mean sent patches for this stuff before.  Think of it
as the Facade Pattern :-)
>  
> Regards,
> Doug

        Hugh

From dougkearns at gmail.com  Fri Feb 23 09:31:21 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 24 Feb 2007 01:31:21 +1100
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070220161024.GC13167@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
Message-ID: <20070223143121.GB17370@localhost.localdomain>

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

From vim-ruby-devel at tpope.info  Fri Feb 23 13:10:53 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 23 Feb 2007 12:10:53 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070223085603.GC11127@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
Message-ID: <20070223181052.GB28979@tpope.us>

On Fri, Feb 23, 2007 at 07:56:03PM +1100, Doug Kearns wrote:
> On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:
> > More important than a few cosmetic changes is the overhaul I gave to
> > method, module, and class definitions.
> From a quick inspection I noticed that the following are not being
> highlighted properly:
> 
> def foo    ; end  # whitespace after method name
> def foo(x);  end  # with parameter list (also empty list)
> def Foo::bar;end  # specified with ::

Fixed all 3.  Turns out the difference between .\@<! and \.\@<! is
quite large :).

> def [];      end  # all redefinable operator methods

You may not have intended it, but this is by far the best case I have
heard for highlighting method names:  indicating whether they are
valid, including the appropriate operators.  I've added matching for
all operators that can be overloaded; the list is hopefully both
exhaustive and exclusive.  Building on this, I added highlighting for
aliases as well.  The way I did this is a little crude and may need
some refining, so let me know if there are problems.

> 
> > Things like if/unless are in the Conditional group and
> > while/until in the Loop group.
> 
> Shouldn't that be the Repeat group?

Doh, shows how often I use these primitive constructs.  I see you
fixed the hi link; I renamed the group as well.

> It's really just the "Vim Way" of doing things - at least as I
> understand it.  Generally the configuration options are there to allow
> people to customize the highlighting without any need to understand
> syntax files.  I think you'd be surprised how many people use Vim with
> absolutely no understanding of these details. ;-)

True to an extent, but some of this strikes me as "giving a man a
fish".  Actually, I think in my example, the "hi link" is *easier* to
understand.  You don't have to know how "let" differs from "set", and
why it sometimes but not always needs a "g:" in there to work.  Plus,
having such config variables in place sends the message, "the changes
you can make are limited to these config variables".

I'm updating the documentation in the repository to recommend my
alternative instead ruby_no_identifiers.  There is precedent for this
in other syntax file documentation, including ft-c-syntax.  If nobody
reverts this change, I may do this for other options as well, but the
highlighting code needs to be restructured first in order to enable
this.  I'm leaving ruby_no_identifiers in syntax/ruby.vim itself for
backwards compatibility.

Cheers,

Tim

From vim-ruby-devel at tpope.info  Fri Feb 23 13:14:11 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 23 Feb 2007 12:14:11 -0600
Subject: rubyFunction, rubyClass, and rubyModule no longer highlighted
In-Reply-To: <20070223143121.GB17370@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070223143121.GB17370@localhost.localdomain>
Message-ID: <20070223181411.GC28979@tpope.us>

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

From dougkearns at gmail.com  Fri Feb 23 23:10:51 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 24 Feb 2007 15:10:51 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070223181052.GB28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
Message-ID: <20070224041050.GA4250@localhost.localdomain>

On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> On Fri, Feb 23, 2007 at 07:56:03PM +1100, Doug Kearns wrote:
> > On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:
> > > More important than a few cosmetic changes is the overhaul I gave to
> > > method, module, and class definitions.
> > From a quick inspection I noticed that the following are not being
> > highlighted properly:
> > 
> > def foo    ; end  # whitespace after method name
> > def foo(x);  end  # with parameter list (also empty list)
> > def Foo::bar;end  # specified with ::
> 
> Fixed all 3.  Turns out the difference between .\@<! and \.\@<! is
> quite large :).

Thanks.

> > def [];      end  # all redefinable operator methods
> 
> You may not have intended it, but this is by far the best case I have
> heard for highlighting method names:  indicating whether they are
> valid, including the appropriate operators.

I guess... It's probably the best to highlight them by default.  It
certainly seems to be what all the other kids are doing.

> I've added matching for
> all operators that can be overloaded; the list is hopefully both
> exhaustive and exclusive.

You missed == and & which I've added.

<snip>
 
> > It's really just the "Vim Way" of doing things - at least as I
> > understand it.  Generally the configuration options are there to allow
> > people to customize the highlighting without any need to understand
> > syntax files.  I think you'd be surprised how many people use Vim with
> > absolutely no understanding of these details. ;-)
> 
> True to an extent, but some of this strikes me as "giving a man a
> fish".  Actually, I think in my example, the "hi link" is *easier* to
> understand.  You don't have to know how "let" differs from "set", and
> why it sometimes but not always needs a "g:" in there to work.  Plus,
> having such config variables in place sends the message, "the changes
> you can make are limited to these config variables".

That's a good point.

<snip>

Regards,
Doug

From dougkearns at gmail.com  Sat Feb 24 05:14:52 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 24 Feb 2007 21:14:52 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070223181052.GB28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
Message-ID: <20070224101452.GB4250@localhost.localdomain>

On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> On Fri, Feb 23, 2007 at 07:56:03PM +1100, Doug Kearns wrote:
> > On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:
> > > More important than a few cosmetic changes is the overhaul I gave to
> > > method, module, and class definitions.
> > From a quick inspection I noticed that the following are not being
> > highlighted properly:
> > 
> > def foo    ; end  # whitespace after method name
> > def foo(x);  end  # with parameter list (also empty list)
> > def Foo::bar;end  # specified with ::
> 
> Fixed all 3.  Turns out the difference between .\@<! and \.\@<! is
> quite large :).

The following are incorrect at the moment:

def end?; end
def end=; end
def end!; end

Here's a couple of quick fixes:

Index: syntax/ruby.vim
===================================================================
RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
retrieving revision 1.104
diff -u -b -r1.104 ruby.vim
--- syntax/ruby.vim	24 Feb 2007 04:02:50 -0000	1.104
+++ syntax/ruby.vim	24 Feb 2007 10:08:08 -0000
@@ -163,7 +163,7 @@
   syn match  rubyDefine "\<def\>"		nextgroup=rubyMethodDeclaration skipwhite skipnl
   syn match  rubyClass  "\<class\>"		nextgroup=rubyClassDeclaration  skipwhite skipnl
   syn match  rubyModule "\<module\>"		nextgroup=rubyModuleDeclaration skipwhite skipnl
-  syn region rubyBlock start="\<def\>"		matchgroup=rubyDefine end="\<end\>" contains=TOP fold
+  syn region rubyBlock start="\<def\>"		matchgroup=rubyDefine end="\<end\>[?!=]\@!" contains=TOP fold
   syn region rubyBlock start="\<class\>"	matchgroup=rubyClass  end="\<end\>" contains=TOP fold
   syn region rubyBlock start="\<module\>"	matchgroup=rubyModule end="\<end\>" contains=TOP fold
 

Index: syntax/ruby.vim
===================================================================
RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
retrieving revision 1.104
diff -u -b -r1.104 ruby.vim
--- syntax/ruby.vim	24 Feb 2007 04:02:50 -0000	1.104
+++ syntax/ruby.vim	24 Feb 2007 10:09:34 -0000
@@ -163,7 +163,7 @@
   syn match  rubyDefine "\<def\>"		nextgroup=rubyMethodDeclaration skipwhite skipnl
   syn match  rubyClass  "\<class\>"		nextgroup=rubyClassDeclaration  skipwhite skipnl
   syn match  rubyModule "\<module\>"		nextgroup=rubyModuleDeclaration skipwhite skipnl
-  syn region rubyBlock start="\<def\>"		matchgroup=rubyDefine end="\<end\>" contains=TOP fold
+  syn region rubyBlock start="\<def\>"		matchgroup=rubyDefine end="\<end\>" contains=TOP fold skip="\<end[?!=]"
   syn region rubyBlock start="\<class\>"	matchgroup=rubyClass  end="\<end\>" contains=TOP fold
   syn region rubyBlock start="\<module\>"	matchgroup=rubyModule end="\<end\>" contains=TOP fold
 
<snip>

Regards,
Doug

From dougkearns at gmail.com  Sat Feb 24 05:16:47 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 24 Feb 2007 21:16:47 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070223181052.GB28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
Message-ID: <20070224101647.GC4250@localhost.localdomain>

On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:

<snip>
 
> I'm updating the documentation in the repository to recommend my
> alternative instead ruby_no_identifiers.  There is precedent for this
> in other syntax file documentation, including ft-c-syntax.  If nobody
> reverts this change, I may do this for other options as well, but the
> highlighting code needs to be restructured first in order to enable
> this.  I'm leaving ruby_no_identifiers in syntax/ruby.vim itself for
> backwards compatibility.

It might also be an idea to, at least, rename that awkwardly named
ruby_no_expensive variable.  Any ideas?

Regards,
Doug

From dougkearns at gmail.com  Sat Feb 24 07:22:48 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 24 Feb 2007 23:22:48 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070223181052.GB28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
Message-ID: <20070224122248.GD4250@localhost.localdomain>

On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:

<snip>

> Building on this, I added highlighting for
> aliases as well.  The way I did this is a little crude and may need
> some refining, so let me know if there are problems.

It can't be disabled by setting ruby_no_special_methods anymore.  Is
that intentional?

<snip>

Regards,
Doug

From vim-ruby-devel at tpope.info  Sat Feb 24 20:29:03 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sat, 24 Feb 2007 19:29:03 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070224122248.GD4250@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224122248.GD4250@localhost.localdomain>
Message-ID: <20070225012903.GD28979@tpope.us>

On Sat, Feb 24, 2007 at 11:22:48PM +1100, Doug Kearns wrote:
> On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> > Building on this, I added highlighting for
> > aliases as well.  The way I did this is a little crude and may need
> > some refining, so let me know if there are problems.
> 
> It can't be disabled by setting ruby_no_special_methods anymore.  Is
> that intentional?

Well, I hadn't really considered that, but alias is not a method.
It's syntax, just like def, class, and module.

Cheers,

Tim

From vim-ruby-devel at tpope.info  Sat Feb 24 20:47:22 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sat, 24 Feb 2007 19:47:22 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070224101452.GB4250@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
Message-ID: <20070225014722.GE28979@tpope.us>

On Sat, Feb 24, 2007 at 09:14:52PM +1100, Doug Kearns wrote:
> The following are incorrect at the moment:
> 
> def end?; end
> def end=; end
> def end!; end

I missed these because apparently Debian patches the ftplugin to set
iskeyword+=!,? .  The merits of this are debatable so I'm not copying
that, but I will be copying the keywordprg=ri they also patched in.

To further the original point, even the following is valid:

def end; end

Yes, end really can be a method name.  So I'll be changing the pattern
to something like "\%(\<def\s\+\)\@<!\<end\>".  This still doesn't fix
the indenting, but that's a much tougher nut to crack.

Cheers,

Tim

From dougkearns at gmail.com  Sun Feb 25 03:27:59 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sun, 25 Feb 2007 19:27:59 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225012903.GD28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224122248.GD4250@localhost.localdomain>
	<20070225012903.GD28979@tpope.us>
Message-ID: <20070225082759.GA4954@localhost.localdomain>

On Sat, Feb 24, 2007 at 07:29:03PM -0600, Tim Pope wrote:
> On Sat, Feb 24, 2007 at 11:22:48PM +1100, Doug Kearns wrote:
> > On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> > > Building on this, I added highlighting for
> > > aliases as well.  The way I did this is a little crude and may need
> > > some refining, so let me know if there are problems.
> > 
> > It can't be disabled by setting ruby_no_special_methods anymore.  Is
> > that intentional?
> 
> Well, I hadn't really considered that, but alias is not a method.
> It's syntax, just like def, class, and module.

Which is a good reason to exclude from that group. ;-)
 
Regards,
Doug

From dougkearns at gmail.com  Sun Feb 25 03:30:15 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sun, 25 Feb 2007 19:30:15 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225014722.GE28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
Message-ID: <20070225083015.GB4954@localhost.localdomain>

On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:
> On Sat, Feb 24, 2007 at 09:14:52PM +1100, Doug Kearns wrote:
> > The following are incorrect at the moment:
> > 
> > def end?; end
> > def end=; end
> > def end!; end
> 
> I missed these because apparently Debian patches the ftplugin to set
> iskeyword+=!,? .  The merits of this are debatable so I'm not copying
> that, but I will be copying the keywordprg=ri they also patched in.

Aren't they supposed to send these changes 'upstream'?  I wasn't aware
they were patching these files...it might explain a few bug reports.
*sigh*
 
<snip>

Regards,
Doug

From dougkearns at gmail.com  Sun Feb 25 03:45:28 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sun, 25 Feb 2007 19:45:28 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225082759.GA4954@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224122248.GD4250@localhost.localdomain>
	<20070225012903.GD28979@tpope.us>
	<20070225082759.GA4954@localhost.localdomain>
Message-ID: <20070225084528.GA12686@localhost.localdomain>

On Sun, Feb 25, 2007 at 07:27:59PM +1100, Doug Kearns wrote:
> On Sat, Feb 24, 2007 at 07:29:03PM -0600, Tim Pope wrote:
> > On Sat, Feb 24, 2007 at 11:22:48PM +1100, Doug Kearns wrote:
> > > On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> > > > Building on this, I added highlighting for
> > > > aliases as well.  The way I did this is a little crude and may need
> > > > some refining, so let me know if there are problems.
> > > 
> > > It can't be disabled by setting ruby_no_special_methods anymore.  Is
> > > that intentional?
> > 
> > Well, I hadn't really considered that, but alias is not a method.
> > It's syntax, just like def, class, and module.
> 
> Which is a good reason to exclude from that group. ;-)

And even luckier it was never a part of it anyway. It's such a worry...
  
Regards,
Doug

From dougkearns at gmail.com  Sun Feb 25 04:23:25 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sun, 25 Feb 2007 20:23:25 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070223181052.GB28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
Message-ID: <20070225092325.GA12797@localhost.localdomain>

On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:

<snip>

> Building on this, I added highlighting for
> aliases as well.  The way I did this is a little crude and may need
> some refining, so let me know if there are problems.

It seems it's not currently highlighting symbol or global variable
args.

<snip>

Regards,
Doug

From dougkearns at gmail.com  Sun Feb 25 04:38:54 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sun, 25 Feb 2007 20:38:54 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225092325.GA12797@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070225092325.GA12797@localhost.localdomain>
Message-ID: <20070225093854.GB12797@localhost.localdomain>

On Sun, Feb 25, 2007 at 08:23:25PM +1100, Doug Kearns wrote:
> On Fri, Feb 23, 2007 at 12:10:53PM -0600, Tim Pope wrote:
> 
> <snip>
> 
> > Building on this, I added highlighting for
> > aliases as well.  The way I did this is a little crude and may need
> > some refining, so let me know if there are problems.
> 
> It seems it's not currently highlighting symbol or global variable
> args.

...or capitalised method names.

Regards,
Doug

From vim-ruby-devel at tpope.info  Sun Feb 25 11:50:50 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sun, 25 Feb 2007 10:50:50 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070225083015.GB4954@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070225083015.GB4954@localhost.localdomain>
Message-ID: <20070225165050.GF28979@tpope.us>

On Sun, Feb 25, 2007 at 07:30:15PM +1100, Doug Kearns wrote:
> On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:
> > On Sat, Feb 24, 2007 at 09:14:52PM +1100, Doug Kearns wrote:
> > > The following are incorrect at the moment:
> > > 
> > > def end?; end
> > > def end=; end
> > > def end!; end
> > 
> > I missed these because apparently Debian patches the ftplugin to set
> > iskeyword+=!,? .  The merits of this are debatable so I'm not copying
> > that, but I will be copying the keywordprg=ri they also patched in.
> 
> Aren't they supposed to send these changes 'upstream'?  I wasn't aware
> they were patching these files...it might explain a few bug reports.
> *sigh*

Yes, generally they should be.  I know a rather active Debian package
maintainer for Vim; I'll see if I can get some answers out of him.

Cheers,

Tim

From vim-ruby-devel at tpope.info  Sun Feb 25 13:03:29 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sun, 25 Feb 2007 12:03:29 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070225093854.GB12797@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070225092325.GA12797@localhost.localdomain>
	<20070225093854.GB12797@localhost.localdomain>
Message-ID: <20070225180328.GG28979@tpope.us>

On Sun, Feb 25, 2007 at 08:38:54PM +1100, Doug Kearns wrote:
> On Sun, Feb 25, 2007 at 08:23:25PM +1100, Doug Kearns wrote:
> > It seems it's not currently highlighting symbol or global variable
> > args.

Fixed.  I forgot the former because it's so strange, and I never knew
about the latter.

> ...or capitalised method names.

I fixed these in aliases and in method declarations as well.

Cheers,

Tim

From anibalrojas at gmail.com  Sun Feb 25 20:12:28 2007
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Sun, 25 Feb 2007 21:12:28 -0400
Subject: Error detected while processing function <SNR>5_LoadFTPlugin:
Message-ID: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>

Hello,

    I am quite new to vim. Just installed ruby-vim using ruby gems,
and the install script as indicated. And now, whenever I open a .rb
file I get the following error:

Error detected while processing function <SNR>5_LoadFTPlugin:
line 3:
E518: Unknow option ofu<

    After hitting ENTER I can edit the file.

    This error is displayed both in vim and gvim, version
1:6.4-006+2ubuntu. At the bottom of the mail is the output of $ gem
specification vim-ruby

    I am not sure if this is the correct place to write this message,
please let me know if you would prefer this information being posted
as a bug.

    Thanks id advance,

--
An?bal Rojas
http://www.rubycorner.com
http://www.hasmanydevelopers.com

$ gem specification vim-ruby
--- !ruby/object:Gem::Specification
rubygems_version: 0.9.1
specification_version: 1
name: vim-ruby
version: !ruby/object:Gem::Version
  version: 2006.07.11
date: 2006-07-10 00:00:00 -04:00
summary: Ruby configuration files for Vim.  Run 'vim-ruby-install.rb'
to complete installation.
require_paths:
- .
email: gsinclair at soyabean.com.au
homepage: http://vim-ruby.rubyforge.org
rubyforge_project: vim-ruby
description: Ruby configuration files for Vim.  Run
'vim-ruby-install.rb' to complete installation.  This package doesn't
contain a Ruby library.
autorequire:
default_executable: vim-ruby-install.rb
bindir: bin
has_rdoc: false
required_ruby_version: !ruby/object:Gem::Version::Requirement
  requirements:
  - - ">="
    - !ruby/object:Gem::Version
      version: 1.8.0
  version:
platform: ruby
signing_key:
cert_chain:
post_install_message:
authors:
- Gavin Sinclair et al.
files:
- ChangeLog
- CONTRIBUTORS
- FAQ
- INSTALL
- NEWS
- README
- bin/vim-ruby-install.rb
- doc/ft-ruby-syntax.txt
- doc/ft-ruby-omni.txt
- autoload/rubycomplete.vim
- compiler/ruby.vim
- compiler/eruby.vim
- compiler/rubyunit.vim
- ftdetect/ruby.vim
- ftplugin/eruby.vim
- ftplugin/ruby.vim
- indent/eruby.vim
- indent/ruby.vim
- syntax/eruby.vim
- syntax/ruby.vim
test_files: []

rdoc_options: []

extra_rdoc_files: []

executables:
- vim-ruby-install.rb
extensions: []

requirements:
- RubyGems 0.8+
- Vim 6.0+
dependencies: []

From vim-ruby-devel at tpope.info  Sun Feb 25 22:12:44 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sun, 25 Feb 2007 21:12:44 -0600
Subject: Error detected while processing function <SNR>5_LoadFTPlugin:
In-Reply-To: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>
References: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>
Message-ID: <20070226031243.GI28979@tpope.us>

On Sun, Feb 25, 2007 at 09:12:28PM -0400, An?bal Rojas wrote:
> Hello,
> 
>     I am quite new to vim. Just installed ruby-vim using ruby gems,
> and the install script as indicated. And now, whenever I open a .rb
> file I get the following error:
> 
> Error detected while processing function <SNR>5_LoadFTPlugin:
> line 3:
> E518: Unknow option ofu<
> 
>     After hitting ENTER I can edit the file.
> 
>     This error is displayed both in vim and gvim, version
> 1:6.4-006+2ubuntu. At the bottom of the mail is the output of $ gem
> specification vim-ruby
> 
>     I am not sure if this is the correct place to write this message,
> please let me know if you would prefer this information being posted
> as a bug.

The problem relates to Vim trying to set up omnicompletion, a Vim 7
feature.  The version of ftplugin/ruby.vim in CVS already has this
fixed.

Speaking of which, Doug, any chance of finally doing that release in
the next couple of release?  The ERB indent file still hasn't seen the
light of day yet. :)

Cheers,
Tim

From dougkearns at gmail.com  Mon Feb 26 04:56:47 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 26 Feb 2007 20:56:47 +1100
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <20070220161024.GC13167@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
Message-ID: <20070226095647.GA16545@localhost.localdomain>

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

From dougkearns at gmail.com  Mon Feb 26 04:57:17 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 26 Feb 2007 20:57:17 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225014722.GE28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
Message-ID: <20070226095717.GB16545@localhost.localdomain>

On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:

<snip>
 
> To further the original point, even the following is valid:
> 
> def end; end
> 
> Yes, end really can be a method name.  So I'll be changing the pattern
> to something like "\%(\<def\s\+\)\@<!\<end\>".  This still doesn't fix
> the indenting, but that's a much tougher nut to crack.

I changed this to use \_s to allow for:

def
  end
end

...since we're being thorough. ;-)

Regards,
Doug

From dougkearns at gmail.com  Mon Feb 26 05:01:59 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 26 Feb 2007 21:01:59 +1100
Subject: Error detected while processing function <SNR>5_LoadFTPlugin:
In-Reply-To: <20070226031243.GI28979@tpope.us>
References: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>
	<20070226031243.GI28979@tpope.us>
Message-ID: <20070226100159.GC16545@localhost.localdomain>

On Sun, Feb 25, 2007 at 09:12:44PM -0600, Tim Pope wrote:

<snip>
 
> Speaking of which, Doug, any chance of finally doing that release in
> the next couple of release?  The ERB indent file still hasn't seen the
> light of day yet. :)

Oh that old chestnut. ;-)  I was wondering about the status of
rubycomplete.vim which wasn't working for me at all.  Since it now is,
for reasons unknown to me, it seems like a good idea. :)

I just want to have a look through a patch to rubyunit.vim tonight.
 
Regards,
Doug

From dougkearns at gmail.com  Mon Feb 26 06:40:51 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Mon, 26 Feb 2007 22:40:51 +1100
Subject: Error detected while processing function <SNR>5_LoadFTPlugin:
In-Reply-To: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>
References: <dd83951f0702251712k483387e4t6299e13b0d44c7a2@mail.gmail.com>
Message-ID: <20070226114051.GD16545@localhost.localdomain>

G'day An?bal,

On Sun, Feb 25, 2007 at 09:12:28PM -0400, An?bal Rojas wrote:
> Hello,
> 
>     I am quite new to vim.

If you can, I'd suggest you update to the latest version Vim 7 for all
the usual reasons.

<snip>
 
>     I am not sure if this is the correct place to write this message,
> please let me know if you would prefer this information being posted
> as a bug.

Either here or the bug tracker is fine - what ever is easiest for you.

Thanks,
Doug

From dougkearns at gmail.com  Mon Feb 26 08:09:12 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 27 Feb 2007 00:09:12 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070222173236.GA28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
Message-ID: <20070226130911.GE16545@localhost.localdomain>

On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:

<snip>
 
> I also did a lot of clean-up, so let me know if you find anything that
> breaks.

self isn't being highlighted in these two examples.

class <<self  
end

class<<self  
end

<snip>

Regards,
Doug

From dougkearns at gmail.com  Mon Feb 26 08:31:28 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 27 Feb 2007 00:31:28 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070226130911.GE16545@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070226130911.GE16545@localhost.localdomain>
Message-ID: <20070226133128.GF16545@localhost.localdomain>

On Tue, Feb 27, 2007 at 12:09:12AM +1100, Doug Kearns wrote:

<snip>
 
> self isn't being highlighted in these two examples.
> 
> class <<self  
> end
> 
> class<<self  
> end

I've fixed this with the following.  Let me know if I'm overlooking
something.

Regards,
Doug


Index: syntax/ruby.vim
===================================================================
RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
retrieving revision 1.111
diff -u -b -r1.111 ruby.vim
--- syntax/ruby.vim	26 Feb 2007 09:51:06 -0000	1.111
+++ syntax/ruby.vim	26 Feb 2007 13:33:26 -0000
@@ -155,8 +155,8 @@
 syn match  rubyAliasDeclaration    "[^[:space:];#.()]\+"  contained contains=rubySymbol,rubyGlobalVariable,rubyPredefinedVariable nextgroup=rubyAliasDeclaration2 skipwhite
 syn match  rubyAliasDeclaration2   "[^[:space:];#.()]\+"  contained contains=rubySymbol,rubyGlobalVariable,rubyPredefinedVariable
 syn match  rubyMethodDeclaration   "[^[:space:];#(]\+" contained contains=rubyConstant,rubyBoolean,rubyPseudoVariable,rubyInstanceVariable,rubyClassVariable,rubyGlobalVariable
-syn match  rubyClassDeclaration    "[^[:space:];#(]\+" contained contains=rubyConstant
-syn match  rubyModuleDeclaration   "[^[:space:];#(]\+" contained contains=rubyConstant
+syn match  rubyClassDeclaration    "[^[:space:];#<]\+"	  contained contains=rubyConstant
+syn match  rubyModuleDeclaration   "[^[:space:];#]\+"	  contained contains=rubyConstant
 syn match  rubyFunction "\<[_[:alpha:]][_[:alnum:]]*[?!=]\=[[:alnum:].:?!=]\@!" contained containedin=rubyMethodDeclaration
 syn match  rubyFunction "\%(\s\|^\)\@<=[_[:alpha:]][_[:alnum:]]*[?!=]\=\%(\s\|$\)\@=" contained containedin=rubyAliasDeclaration,rubyAliasDeclaration2
 syn match  rubyFunction "\%([[:space:].]\|^\)\@<=\%(\[\]=\=\|\*\*\|[+-]@\=\|[*/%|&^~]\|<<\|>>\|[<>]=\=\|<=>\|===\|==\|=\~\|`\)\%([[:space:];#(]\|$\)\@=" contained containedin=rubyAliasDeclaration,rubyAliasDeclaration2,rubyMethodDeclaration

From vim-ruby-devel at tpope.info  Mon Feb 26 09:45:55 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 26 Feb 2007 08:45:55 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070226133128.GF16545@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070226130911.GE16545@localhost.localdomain>
	<20070226133128.GF16545@localhost.localdomain>
Message-ID: <20070226144555.GJ28979@tpope.us>

On Tue, Feb 27, 2007 at 12:31:28AM +1100, Doug Kearns wrote:
> I've fixed this with the following.  Let me know if I'm overlooking
> something.

Exactly how I would have done it, thanks.

Cheers,
Tim

From vim-ruby-devel at tpope.info  Mon Feb 26 10:15:29 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 26 Feb 2007 09:15:29 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070226095717.GB16545@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070226095717.GB16545@localhost.localdomain>
Message-ID: <20070226151529.GK28979@tpope.us>

On Mon, Feb 26, 2007 at 08:57:17PM +1100, Doug Kearns wrote:
> On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:
> 
> <snip>
>  
> > To further the original point, even the following is valid:
> > 
> > def end; end
> > 
> > Yes, end really can be a method name.  So I'll be changing the pattern
> > to something like "\%(\<def\s\+\)\@<!\<end\>".  This still doesn't fix
> > the indenting, but that's a much tougher nut to crack.
> 
> I changed this to use \_s to allow for:
> 
> def
>   end
> end
> 
> ...since we're being thorough. ;-)

Actually, this omission was intentional.  I figure if the end is on
the next line, the far more likely explanation is the user simply
hasn't typed the method name yet.  But we can try it this way too.

Cheers,
Tim

From vim-ruby-devel at tpope.info  Mon Feb 26 10:21:40 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 26 Feb 2007 09:21:40 -0600
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <20070226095647.GA16545@localhost.localdomain>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
Message-ID: <20070226152139.GL28979@tpope.us>

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

From now at bitwi.se  Mon Feb 26 11:44:56 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Mon, 26 Feb 2007 17:44:56 +0100
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <20070226152139.GL28979@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
	<20070226152139.GL28979@tpope.us>
Message-ID: <dbfc82860702260844j8d4232cy24c8bc3c5d4e1059@mail.gmail.com>

On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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

From vim-ruby-devel at tpope.info  Mon Feb 26 13:59:04 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 26 Feb 2007 12:59:04 -0600
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <dbfc82860702260844j8d4232cy24c8bc3c5d4e1059@mail.gmail.com>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
	<20070226152139.GL28979@tpope.us>
	<dbfc82860702260844j8d4232cy24c8bc3c5d4e1059@mail.gmail.com>
Message-ID: <20070226185904.GN28979@tpope.us>

On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:
> On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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

From now at bitwi.se  Mon Feb 26 15:15:06 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Mon, 26 Feb 2007 21:15:06 +0100
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <20070226185904.GN28979@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
	<20070226152139.GL28979@tpope.us>
	<dbfc82860702260844j8d4232cy24c8bc3c5d4e1059@mail.gmail.com>
	<20070226185904.GN28979@tpope.us>
Message-ID: <dbfc82860702261215q4f565f2h2968065bfc5b2478@mail.gmail.com>

On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> wrote:
> On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:
> > On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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

From vim-ruby-devel at tpope.info  Mon Feb 26 18:46:55 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 26 Feb 2007 17:46:55 -0600
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <dbfc82860702261215q4f565f2h2968065bfc5b2478@mail.gmail.com>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
	<20070226152139.GL28979@tpope.us>
	<dbfc82860702260844j8d4232cy24c8bc3c5d4e1059@mail.gmail.com>
	<20070226185904.GN28979@tpope.us>
	<dbfc82860702261215q4f565f2h2968065bfc5b2478@mail.gmail.com>
Message-ID: <20070226234654.GO28979@tpope.us>

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.

From anibalrojas at gmail.com  Mon Feb 26 19:48:23 2007
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Mon, 26 Feb 2007 20:48:23 -0400
Subject: Error detected while processing function
Message-ID: <dd83951f0702261648t76dd0bd0o10a0a2009f81430f@mail.gmail.com>

Thanks a lot, I'll be checking out the new version, or updating to 7.

-- 
An?bal Rojas
http://www.rubycorner.com
http://www.hasmanydevelopers.com

On 2/26/07, vim-ruby-devel-request at rubyforge.org
<vim-ruby-devel-request at rubyforge.org> wrote:
> Send vim-ruby-devel mailing list submissions to
>         vim-ruby-devel at rubyforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://rubyforge.org/mailman/listinfo/vim-ruby-devel
> or, via email, send a message with subject or body 'help' to
>         vim-ruby-devel-request at rubyforge.org
>
> You can reach the person managing the list at
>         vim-ruby-devel-owner at rubyforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vim-ruby-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Error detected while processing function
>       <SNR>5_LoadFTPlugin: (Doug Kearns)
>    2. Re: Error detected while processing function
>       <SNR>5_LoadFTPlugin: (Doug Kearns)
>    3. Re: More syntax highlighting fun (Doug Kearns)
>    4. Re: More syntax highlighting fun (Doug Kearns)
>    5. Re: More syntax highlighting fun (Tim Pope)
>    6. Re: More syntax highlighting fun (Tim Pope)
>    7. Re: String interpolation highlighting (was Re: rubyFunction,
>       rubyClass,        and rubyModule no longer highlighted) (Tim Pope)
>    8. Re: String interpolation highlighting (was Re: rubyFunction,
>       rubyClass,        and rubyModule no longer highlighted) (Nikolai Weibull)
>    9. Re: String interpolation highlighting (was Re: rubyFunction,
>       rubyClass,        and rubyModule no longer highlighted) (Tim Pope)
>   10. Re: String interpolation highlighting (was Re: rubyFunction,
>       rubyClass,        and rubyModule no longer highlighted) (Nikolai Weibull)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Feb 2007 21:01:59 +1100
> From: Doug Kearns <dougkearns at gmail.com>
> Subject: Re: Error detected while processing function
>         <SNR>5_LoadFTPlugin:
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226100159.GC16545 at localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Feb 25, 2007 at 09:12:44PM -0600, Tim Pope wrote:
>
> <snip>
>
> > Speaking of which, Doug, any chance of finally doing that release in
> > the next couple of release?  The ERB indent file still hasn't seen the
> > light of day yet. :)
>
> Oh that old chestnut. ;-)  I was wondering about the status of
> rubycomplete.vim which wasn't working for me at all.  Since it now is,
> for reasons unknown to me, it seems like a good idea. :)
>
> I just want to have a look through a patch to rubyunit.vim tonight.
>
> Regards,
> Doug
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Feb 2007 22:40:51 +1100
> From: Doug Kearns <dougkearns at gmail.com>
> Subject: Re: Error detected while processing function
>         <SNR>5_LoadFTPlugin:
> To: vim-ruby-devel at rubyforge.org
> Message-ID: <20070226114051.GD16545 at localhost.localdomain>
> Content-Type: text/plain; charset=iso-8859-1
>
> G'day An?bal,
>
> On Sun, Feb 25, 2007 at 09:12:28PM -0400, An?bal Rojas wrote:
> > Hello,
> >
> >     I am quite new to vim.
>
> If you can, I'd suggest you update to the latest version Vim 7 for all
> the usual reasons.
>
> <snip>
>
> >     I am not sure if this is the correct place to write this message,
> > please let me know if you would prefer this information being posted
> > as a bug.
>
> Either here or the bug tracker is fine - what ever is easiest for you.
>
> Thanks,
> Doug
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 27 Feb 2007 00:09:12 +1100
> From: Doug Kearns <dougkearns at gmail.com>
> Subject: Re: More syntax highlighting fun
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226130911.GE16545 at localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 22, 2007 at 11:32:36AM -0600, Tim Pope wrote:
>
> <snip>
>
> > I also did a lot of clean-up, so let me know if you find anything that
> > breaks.
>
> self isn't being highlighted in these two examples.
>
> class <<self
> end
>
> class<<self
> end
>
> <snip>
>
> Regards,
> Doug
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 27 Feb 2007 00:31:28 +1100
> From: Doug Kearns <dougkearns at gmail.com>
> Subject: Re: More syntax highlighting fun
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226133128.GF16545 at localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Feb 27, 2007 at 12:09:12AM +1100, Doug Kearns wrote:
>
> <snip>
>
> > self isn't being highlighted in these two examples.
> >
> > class <<self
> > end
> >
> > class<<self
> > end
>
> I've fixed this with the following.  Let me know if I'm overlooking
> something.
>
> Regards,
> Doug
>
>
> Index: syntax/ruby.vim
> ===================================================================
> RCS file: /var/cvs/vim-ruby/vim-ruby/syntax/ruby.vim,v
> retrieving revision 1.111
> diff -u -b -r1.111 ruby.vim
> --- syntax/ruby.vim     26 Feb 2007 09:51:06 -0000      1.111
> +++ syntax/ruby.vim     26 Feb 2007 13:33:26 -0000
> @@ -155,8 +155,8 @@
>  syn match  rubyAliasDeclaration    "[^[:space:];#.()]\+"  contained contains=rubySymbol,rubyGlobalVariable,rubyPredefinedVariable nextgroup=rubyAliasDeclaration2 skipwhite
>  syn match  rubyAliasDeclaration2   "[^[:space:];#.()]\+"  contained contains=rubySymbol,rubyGlobalVariable,rubyPredefinedVariable
>  syn match  rubyMethodDeclaration   "[^[:space:];#(]\+" contained contains=rubyConstant,rubyBoolean,rubyPseudoVariable,rubyInstanceVariable,rubyClassVariable,rubyGlobalVariable
> -syn match  rubyClassDeclaration    "[^[:space:];#(]\+" contained contains=rubyConstant
> -syn match  rubyModuleDeclaration   "[^[:space:];#(]\+" contained contains=rubyConstant
> +syn match  rubyClassDeclaration    "[^[:space:];#<]\+"   contained contains=rubyConstant
> +syn match  rubyModuleDeclaration   "[^[:space:];#]\+"    contained contains=rubyConstant
>  syn match  rubyFunction "\<[_[:alpha:]][_[:alnum:]]*[?!=]\=[[:alnum:].:?!=]\@!" contained containedin=rubyMethodDeclaration
>  syn match  rubyFunction "\%(\s\|^\)\@<=[_[:alpha:]][_[:alnum:]]*[?!=]\=\%(\s\|$\)\@=" contained containedin=rubyAliasDeclaration,rubyAliasDeclaration2
>  syn match  rubyFunction "\%([[:space:].]\|^\)\@<=\%(\[\]=\=\|\*\*\|[+-]@\=\|[*/%|&^~]\|<<\|>>\|[<>]=\=\|<=>\|===\|==\|=\~\|`\)\%([[:space:];#(]\|$\)\@=" contained containedin=rubyAliasDeclaration,rubyAliasDeclaration2,rubyMethodDeclaration
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 26 Feb 2007 08:45:55 -0600
> From: Tim Pope <vim-ruby-devel at tpope.info>
> Subject: Re: More syntax highlighting fun
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226144555.GJ28979 at tpope.us>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Feb 27, 2007 at 12:31:28AM +1100, Doug Kearns wrote:
> > I've fixed this with the following.  Let me know if I'm overlooking
> > something.
>
> Exactly how I would have done it, thanks.
>
> Cheers,
> Tim
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 26 Feb 2007 09:15:29 -0600
> From: Tim Pope <vim-ruby-devel at tpope.info>
> Subject: Re: More syntax highlighting fun
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226151529.GK28979 at tpope.us>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Feb 26, 2007 at 08:57:17PM +1100, Doug Kearns wrote:
> > On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:
> >
> > <snip>
> >
> > > To further the original point, even the following is valid:
> > >
> > > def end; end
> > >
> > > Yes, end really can be a method name.  So I'll be changing the pattern
> > > to something like "\%(\<def\s\+\)\@<!\<end\>".  This still doesn't fix
> > > the indenting, but that's a much tougher nut to crack.
> >
> > I changed this to use \_s to allow for:
> >
> > def
> >   end
> > end
> >
> > ...since we're being thorough. ;-)
>
> Actually, this omission was intentional.  I figure if the end is on
> the next line, the far more likely explanation is the user simply
> hasn't typed the method name yet.  But we can try it this way too.
>
> Cheers,
> Tim
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 26 Feb 2007 09:21:40 -0600
> From: Tim Pope <vim-ruby-devel at tpope.info>
> Subject: Re: String interpolation highlighting (was Re: rubyFunction,
>         rubyClass,      and rubyModule no longer highlighted)
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226152139.GL28979 at tpope.us>
> Content-Type: text/plain; charset=us-ascii
>
> 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
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 26 Feb 2007 17:44:56 +0100
> From: "Nikolai Weibull" <now at bitwi.se>
> Subject: Re: String interpolation highlighting (was Re: rubyFunction,
>         rubyClass,      and rubyModule no longer highlighted)
> To: "Vim-Ruby Devel ML" <vim-ruby-devel at rubyforge.org>
> Message-ID:
>         <dbfc82860702260844j8d4232cy24c8bc3c5d4e1059 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 26 Feb 2007 12:59:04 -0600
> From: Tim Pope <vim-ruby-devel at tpope.info>
> Subject: Re: String interpolation highlighting (was Re: rubyFunction,
>         rubyClass,      and rubyModule no longer highlighted)
> To: Vim-Ruby Devel ML <vim-ruby-devel at rubyforge.org>
> Message-ID: <20070226185904.GN28979 at tpope.us>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:
> > On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 26 Feb 2007 21:15:06 +0100
> From: "Nikolai Weibull" <now at bitwi.se>
> Subject: Re: String interpolation highlighting (was Re: rubyFunction,
>         rubyClass,      and rubyModule no longer highlighted)
> To: "Vim-Ruby Devel ML" <vim-ruby-devel at rubyforge.org>
> Message-ID:
>         <dbfc82860702261215q4f565f2h2968065bfc5b2478 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> wrote:
> > On Mon, Feb 26, 2007 at 05:44:56PM +0100, Nikolai Weibull wrote:
> > > On 2/26/07, Tim Pope <vim-ruby-devel at tpope.info> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/vim-ruby-devel
>
> End of vim-ruby-devel Digest, Vol 33, Issue 7
> *********************************************
>

From dougkearns at gmail.com  Tue Feb 27 03:54:49 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 27 Feb 2007 19:54:49 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070226151529.GK28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070226095717.GB16545@localhost.localdomain>
	<20070226151529.GK28979@tpope.us>
Message-ID: <20070227085449.GA3700@localhost.localdomain>

On Mon, Feb 26, 2007 at 09:15:29AM -0600, Tim Pope wrote:

<snip>
 
> Actually, this omission was intentional.  I figure if the end is on
> the next line, the far more likely explanation is the user simply
> hasn't typed the method name yet.  But we can try it this way too.

Given that I've never seen, and can't find, any of these 'multi-line'
method definitions feel free to change it back if you think it's too
distracting.

Thanks,
Doug

From dougkearns at gmail.com  Tue Feb 27 04:13:09 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 27 Feb 2007 20:13:09 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225014722.GE28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
Message-ID: <20070227091309.GB3700@localhost.localdomain>

On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:

<snip>
 
> I missed these because apparently Debian patches the ftplugin to set
> iskeyword+=!,? .  The merits of this are debatable so I'm not copying
> that, but I will be copying the keywordprg=ri they also patched in.

ruby.vim would then be the only ftplugin setting 'kp'.  Is there a
reason for that?  Is it considered too specific a setting?

<snip>

Regards,
Doug

From vim-ruby-devel at tpope.info  Tue Feb 27 10:49:03 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 27 Feb 2007 09:49:03 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070227091309.GB3700@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070227091309.GB3700@localhost.localdomain>
Message-ID: <20070227154902.GQ28979@tpope.us>

On Tue, Feb 27, 2007 at 08:13:09PM +1100, Doug Kearns wrote:
> On Sat, Feb 24, 2007 at 07:47:22PM -0600, Tim Pope wrote:
> > I missed these because apparently Debian patches the ftplugin to set
> > iskeyword+=!,? .  The merits of this are debatable so I'm not copying
> > that, but I will be copying the keywordprg=ri they also patched in.
> 
> ruby.vim would then be the only ftplugin setting 'kp'.  Is there a
> reason for that?  Is it considered too specific a setting?

Excellent observation, though I propose we proceed regardless.  Only a
handful of languages have a decent command-line tool for querying
documentation, so it's possible that we're just the first to try it.
If we do a release with it soon, we'll have plenty of time to pull it
back out before Vim 7.1, if it really must come to that.

Speaking of options that might be a bad idea, I've added a
'balloonexpr'.  This isn't set in any other ftplugins either, but
that's hardly surprising since it's a relatively new feature.  Since
you have to actually :set ballooneval to activate it,  I think the
impact of just configuring it will be minimal.  The expression I've
provided works well but all the process spawning is a bit much on
win32 systems.

Cheers,
Tim

From now at bitwi.se  Tue Feb 27 14:06:51 2007
From: now at bitwi.se (Nikolai Weibull)
Date: Tue, 27 Feb 2007 20:06:51 +0100
Subject: More syntax highlighting fun
In-Reply-To: <20070227154902.GQ28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070227091309.GB3700@localhost.localdomain>
	<20070227154902.GQ28979@tpope.us>
Message-ID: <dbfc82860702271106p1e482a5n49bf765c0f62d8cf@mail.gmail.com>

On 2/27/07, Tim Pope <vim-ruby-devel at tpope.info> wrote:
> On Tue, Feb 27, 2007 at 08:13:09PM +1100, Doug Kearns wrote:

> > ruby.vim would then be the only ftplugin setting 'kp'.  Is there a
> > reason for that?  Is it considered too specific a setting?

> Excellent observation, though I propose we proceed regardless.  Only a
> handful of languages have a decent command-line tool for querying
> documentation, so it's possible that we're just the first to try it.
> If we do a release with it soon, we'll have plenty of time to pull it
> back out before Vim 7.1, if it really must come to that.

I think that that's fine.  However, can't we try to detect fastri, as
it is preferable to the standard ri, if installed?

  nikolai

From dougkearns at gmail.com  Wed Feb 28 02:02:14 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 28 Feb 2007 18:02:14 +1100
Subject: NEWS update
Message-ID: <20070228070214.GA3655@localhost.localdomain>

Could someone who understands the user visible changes to
rubycomplete.vim, particularly Rails related, add a couple of small
notes to the NEWS file?

Thanks,
Doug

From boss at airbladesoftware.com  Wed Feb 28 04:14:32 2007
From: boss at airbladesoftware.com (Andrew Stewart)
Date: Wed, 28 Feb 2007 09:14:32 +0000
Subject: Method definition highlighting
In-Reply-To: <20070221150812.GE13167@tpope.us>
References: <20070220110236.GB15777@localhost.localdomain>
	<20070220154749.GB13167@tpope.us>
	<06238001-79B8-49D3-AA60-D7E0FB0E58D6@airbladesoftware.com>
	<20070221150812.GE13167@tpope.us>
Message-ID: <5C2ABAF5-47FD-4E8F-947C-431BD87008CE@airbladesoftware.com>


On 21 Feb 2007, at 15:08, Tim Pope wrote:
> On Wed, Feb 21, 2007 at 11:19:44AM +0000, Andrew Stewart wrote:
>> Any chance you could post your vibrant ink somewhere?
>>
>> (Or should that be vimbrant ink?)
>
> I'm calling it vividchalk :).  I'm attaching what is still a work in
> process.  I've decided not to go for an exact clone, after seeing how
> the HTML highlighting in TextMate is rather ugly, in my opinion.
> Feedback welcome; I'm still deciding how to do a lot of the Vim
> specific stuff like the statusline and completion menu.

Nice name.

Thanks for posting vividchalk.  It looks pretty good.

The only colour I changed was the one used for visual selections.  I  
found that the grey was sufficiently light to make the text  
underneath, for most colours, hard to read.  So I darkened it and  
that helped a lot.

Regards,
Andy Stewart

From dougkearns at gmail.com  Wed Feb 28 05:08:13 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 28 Feb 2007 21:08:13 +1100
Subject: String interpolation highlighting (was Re: rubyFunction, rubyClass,
	and rubyModule no longer highlighted)
In-Reply-To: <20070226152139.GL28979@tpope.us>
References: <20070218225841.GE18070@tpope.us>
	<20070219014343.GA6502@localhost.localdomain>
	<20070219020721.GF18070@tpope.us>
	<20070220103649.GA15777@localhost.localdomain>
	<20070220161024.GC13167@tpope.us>
	<20070226095647.GA16545@localhost.localdomain>
	<20070226152139.GL28979@tpope.us>
Message-ID: <20070228100813.GB3655@localhost.localdomain>

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

From vim-ruby-devel at tpope.info  Wed Feb 28 21:17:52 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Wed, 28 Feb 2007 20:17:52 -0600
Subject: NEWS update
In-Reply-To: <20070228070214.GA3655@localhost.localdomain>
References: <20070228070214.GA3655@localhost.localdomain>
Message-ID: <20070301021752.GR28979@tpope.us>

On Wed, Feb 28, 2007 at 06:02:14PM +1100, Doug Kearns wrote:
> Could someone who understands the user visible changes to
> rubycomplete.vim, particularly Rails related, add a couple of small
> notes to the NEWS file?

Well, since the changelog covers it, I will get it in 24 hours if our
friend Mark doesn't show up by then.

Cheers,
Tim

From vim-ruby-devel at tpope.info  Wed Feb 28 21:41:40 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Wed, 28 Feb 2007 20:41:40 -0600
Subject: More syntax highlighting fun
In-Reply-To: <dbfc82860702271106p1e482a5n49bf765c0f62d8cf@mail.gmail.com>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070227091309.GB3700@localhost.localdomain>
	<20070227154902.GQ28979@tpope.us>
	<dbfc82860702271106p1e482a5n49bf765c0f62d8cf@mail.gmail.com>
Message-ID: <20070301024140.GS28979@tpope.us>

On Tue, Feb 27, 2007 at 08:06:51PM +0100, Nikolai Weibull wrote:
> On 2/27/07, Tim Pope <vim-ruby-devel at tpope.info> wrote:
> > Excellent observation, though I propose we proceed regardless.  Only a
> > handful of languages have a decent command-line tool for querying
> > documentation, so it's possible that we're just the first to try it.
> > If we do a release with it soon, we'll have plenty of time to pull it
> > back out before Vim 7.1, if it really must come to that.
> 
> I think that that's fine.  However, can't we try to detect fastri, as
> it is preferable to the standard ri, if installed?

Go for it.  Just keep in mind executable() can be slow in some
circumstances (think Windows and/or network drives) so you have to
weigh the chances of fastri being installed versus the ever so slight
delay for a seldom used feature.

Cheers,
Tim

From vim-ruby-devel at tpope.info  Wed Feb 28 21:42:27 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Wed, 28 Feb 2007 20:42:27 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070224101647.GC4250@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101647.GC4250@localhost.localdomain>
Message-ID: <20070301024226.GT28979@tpope.us>

On Sat, Feb 24, 2007 at 09:16:47PM +1100, Doug Kearns wrote:
> It might also be an idea to, at least, rename that awkwardly named
> ruby_no_expensive variable.  Any ideas?

I've been thinking for days but I still can't do any better than
ruby_cheap.

Cheers,
Tim

From sroberts at uniserve.com  Thu Mar  1 00:04:45 2007
From: sroberts at uniserve.com (Sam Roberts)
Date: Wed, 28 Feb 2007 21:04:45 -0800
Subject: More syntax highlighting fun
In-Reply-To: <20070301024226.GT28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101647.GC4250@localhost.localdomain>
	<20070301024226.GT28979@tpope.us>
Message-ID: <20070301050445.GA577@ensemble.local>

Quoting vim-ruby-devel at tpope.info, on Wed, Feb 28, 2007 at 08:42:27PM -0600:
> On Sat, Feb 24, 2007 at 09:16:47PM +1100, Doug Kearns wrote:
> > It might also be an idea to, at least, rename that awkwardly named
> > ruby_no_expensive variable.  Any ideas?
> 
> I've been thinking for days but I still can't do any better than
> ruby_cheap.

ruby_uncut  ?

Sam


From dougkearns at gmail.com  Thu Mar  1 02:22:01 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Thu, 1 Mar 2007 18:22:01 +1100
Subject: NEWS update
In-Reply-To: <20070301021752.GR28979@tpope.us>
References: <20070228070214.GA3655@localhost.localdomain>
	<20070301021752.GR28979@tpope.us>
Message-ID: <20070301072201.GA3872@localhost.localdomain>

On Wed, Feb 28, 2007 at 08:17:52PM -0600, Tim Pope wrote:
> On Wed, Feb 28, 2007 at 06:02:14PM +1100, Doug Kearns wrote:
> > Could someone who understands the user visible changes to
> > rubycomplete.vim, particularly Rails related, add a couple of small
> > notes to the NEWS file?
> 
> Well, since the changelog covers it, I will get it in 24 hours if our
> friend Mark doesn't show up by then.

Thanks, some of it didn't mean too much to me.  I've only ever had a
very cursory look at Rails.  I'm just so uncool... ;-)

Thanks,
Doug

From dougkearns at gmail.com  Fri Mar  2 04:59:50 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 2 Mar 2007 20:59:50 +1100
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <20060711121438.GA1824@localhost.localdomain>
References: <20060711121438.GA1824@localhost.localdomain>
Message-ID: <20070302095950.GA3347@localhost.localdomain>

I've just sent up vim-ruby-2007.02.02.
  
Regards,
Doug

From dougkearns at gmail.com  Fri Mar  2 05:43:47 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 2 Mar 2007 21:43:47 +1100
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <20070302095950.GA3347@localhost.localdomain>
References: <20060711121438.GA1824@localhost.localdomain>
	<20070302095950.GA3347@localhost.localdomain>
Message-ID: <20070302104347.GB3347@localhost.localdomain>

On Fri, Mar 02, 2007 at 08:59:50PM +1100, Doug Kearns wrote:
> I've just sent up vim-ruby-2007.02.02.
                                  03.02 even...*sigh*

Regards,
Doug

From r.mark.volkmann at gmail.com  Fri Mar  2 15:59:44 2007
From: r.mark.volkmann at gmail.com (Mark Volkmann)
Date: Fri, 2 Mar 2007 14:59:44 -0600
Subject: ANN: New stable release - 2007.02.02
Message-ID: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>

On Mar 2, 2007, at 3:59 AM, Doug Kearns wrote:
I've just sent up vim-ruby-2007.02.02.

I just installed this with "gem install vim-ruby".
That's all I need to do, right?

The announcement contains this. "ri has been added as the  
'keywordprg' and 'balloonexpr' is set to return the
output of ri". How do you use ri from vim?

Is there a web page that explains how to use all the features of vim- 
ruby?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/vim-ruby-devel/attachments/20070302/ab75688c/attachment.html 

From vim-ruby-devel at tpope.info  Fri Mar  2 16:14:36 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 2 Mar 2007 15:14:36 -0600
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>
References: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>
Message-ID: <20070302211436.GX28979@tpope.us>

On Fri, Mar 02, 2007 at 02:59:44PM -0600, Mark Volkmann wrote:
> On Mar 2, 2007, at 3:59 AM, Doug Kearns wrote:
> I've just sent up vim-ruby-2007.02.02.
> 
> I just installed this with "gem install vim-ruby".
> That's all I need to do, right?

You also need to run vim-ruby-install.rb to copy the files where Vim
can find them.

> The announcement contains this. "ri has been added as the  
> 'keywordprg' and 'balloonexpr' is set to return the
> output of ri". How do you use ri from vim?
> 
> Is there a web page that explains how to use all the features of vim- 
> ruby?

Not that I'm aware of; most of what vim-ruby does happens
automatically anyways.  For the two features mentioned above, see the
Vim help:

:help 'keywordprg'
:help 'balloonexpr'

Cheers,
Tim

From r.mark.volkmann at gmail.com  Fri Mar  2 17:00:54 2007
From: r.mark.volkmann at gmail.com (Mark Volkmann)
Date: Fri, 2 Mar 2007 16:00:54 -0600
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <20070302211436.GX28979@tpope.us>
References: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>
	<20070302211436.GX28979@tpope.us>
Message-ID: <8895C31F-1241-41C6-BCEC-9BA9F09B8C33@gmail.com>

On Mar 2, 2007, at 3:14 PM, Tim Pope wrote:

> On Fri, Mar 02, 2007 at 02:59:44PM -0600, Mark Volkmann wrote:
>> On Mar 2, 2007, at 3:59 AM, Doug Kearns wrote:
>> I've just sent up vim-ruby-2007.02.02.
>>
>> I just installed this with "gem install vim-ruby".
>> That's all I need to do, right?
>
> You also need to run vim-ruby-install.rb to copy the files where Vim
> can find them.

Okay. I've done that now.

>> The announcement contains this. "ri has been added as the
>> 'keywordprg' and 'balloonexpr' is set to return the
>> output of ri". How do you use ri from vim?
>>
>> Is there a web page that explains how to use all the features of vim-
>> ruby?
>
> Not that I'm aware of; most of what vim-ruby does happens
> automatically anyways.  For the two features mentioned above, see the
> Vim help:
>
> :help 'keywordprg'

"Program to use for the K command." I read on further, but didn't see  
anything that helped me understand what this does. Maybe I'm just  
being dense.

> :help 'balloonexpr'

This seems like it could be cool. I'm guessing it will let me put the  
cursor on a Ruby module, class or method name, press some key, and  
see help in a popup tooltip. I tried to enable this with ":set  
ballooneval", but it says "E518: Unknown option: ballooneval".

Here's the version of Vim I'm using.

7.0 (2006 May 7, compiled May 8 2006 12:56:43)
MacOS X (unix) version

From vim-ruby-devel at tpope.info  Fri Mar  2 17:28:18 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 2 Mar 2007 16:28:18 -0600
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <8895C31F-1241-41C6-BCEC-9BA9F09B8C33@gmail.com>
References: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>
	<20070302211436.GX28979@tpope.us>
	<8895C31F-1241-41C6-BCEC-9BA9F09B8C33@gmail.com>
Message-ID: <20070302222818.GY28979@tpope.us>

On Fri, Mar 02, 2007 at 04:00:54PM -0600, Mark Volkmann wrote:
> On Mar 2, 2007, at 3:14 PM, Tim Pope wrote:
> > :help 'keywordprg'
> 
> "Program to use for the K command." I read on further, but didn't see  
> anything that helped me understand what this does. Maybe I'm just  
> being dense.

See how K is highlighted?  That means it's a tag you can follow.
Press CTRL-] on it.

> > :help 'balloonexpr'
> 
> This seems like it could be cool. I'm guessing it will let me put the  
> cursor on a Ruby module, class or method name, press some key, and  
> see help in a popup tooltip. I tried to enable this with ":set  
> ballooneval", but it says "E518: Unknown option: ballooneval".
> 
> Here's the version of Vim I'm using.
> 
> 7.0 (2006 May 7, compiled May 8 2006 12:56:43)
> MacOS X (unix) version

Apparently the Mac version doesn't support balloons.  Hardly
surprising given the sorry state of GUI support.

Cheers,
Tim

From dougkearns at gmail.com  Fri Mar  2 23:00:28 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 3 Mar 2007 15:00:28 +1100
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <20070302211436.GX28979@tpope.us>
References: <D15A1BC5-989A-4A00-A0A0-B8B7B0BD8429@gmail.com>
	<20070302211436.GX28979@tpope.us>
Message-ID: <20070303040028.GA3917@localhost.localdomain>

On Fri, Mar 02, 2007 at 03:14:36PM -0600, Tim Pope wrote:
> On Fri, Mar 02, 2007 at 02:59:44PM -0600, Mark Volkmann wrote:

<snip>
 
> > Is there a web page that explains how to use all the features of vim- 
> > ruby?
> 
> Not that I'm aware of; most of what vim-ruby does happens
> automatically anyways.

http://wiki.rubygarden.org/Ruby/page/show/VimRubySupport

<snip>

Regards,
Doug

From dougkearns at gmail.com  Sat Mar  3 04:24:01 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 3 Mar 2007 20:24:01 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070225165050.GF28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070225083015.GB4954@localhost.localdomain>
	<20070225165050.GF28979@tpope.us>
Message-ID: <20070303092401.GB3917@localhost.localdomain>

On Sun, Feb 25, 2007 at 10:50:50AM -0600, Tim Pope wrote:

<snip>
 
> Yes, generally they should be.  I know a rather active Debian package
> maintainer for Vim; I'll see if I can get some answers out of him.

Did you have any luck?

I noticed that you've made a recent change to account for them changing
'isk'.  A quick inspection reveals that setting it to their value (which
I find hard to fathom) also breaks highlighting in other ways.  I'd
really prefer that we didn't chase their changes...it's hard enough
getting this stuff right as it is. ;-)

Can anyone make a case for their 'isk' value???

Regards,
Doug

From vim-ruby-devel at tpope.info  Sat Mar  3 11:18:22 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Sat, 3 Mar 2007 10:18:22 -0600
Subject: More syntax highlighting fun
In-Reply-To: <20070303092401.GB3917@localhost.localdomain>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070225083015.GB4954@localhost.localdomain>
	<20070225165050.GF28979@tpope.us>
	<20070303092401.GB3917@localhost.localdomain>
Message-ID: <20070303161822.GZ28979@tpope.us>

On Sat, Mar 03, 2007 at 08:24:01PM +1100, Doug Kearns wrote:
> On Sun, Feb 25, 2007 at 10:50:50AM -0600, Tim Pope wrote:
> 
> <snip>
>  
> > Yes, generally they should be.  I know a rather active Debian package
> > maintainer for Vim; I'll see if I can get some answers out of him.
> 
> Did you have any luck?

I have word that it's going to be fixed.  I was waiting until the
change was officially committed before posting back.

> I noticed that you've made a recent change to account for them changing
> 'isk'.  A quick inspection reveals that setting it to their value (which
> I find hard to fathom) also breaks highlighting in other ways.  I'd
> really prefer that we didn't chase their changes...it's hard enough
> getting this stuff right as it is. ;-)

This change was for an even more ridiculous value of 'isk' that was a
side effect of a plugin.  In general I don't think it's worthwhile to
hack around this sort of thing but this was a really easy change so I
made it.

Cheers,
Tim

From segfault at hasno.info  Sat Mar  3 16:01:22 2007
From: segfault at hasno.info (Mark Guzman)
Date: Sat, 03 Mar 2007 16:01:22 -0500
Subject: ANN: New stable release - 2007.02.02
In-Reply-To: <20070302104347.GB3347@localhost.localdomain>
References: <20060711121438.GA1824@localhost.localdomain>	<20070302095950.GA3347@localhost.localdomain>
	<20070302104347.GB3347@localhost.localdomain>
Message-ID: <45E9E222.6010506@hasno.info>

Doug Kearns wrote:
> On Fri, Mar 02, 2007 at 08:59:50PM +1100, Doug Kearns wrote:
>   
>> I've just sent up vim-ruby-2007.02.02.
>>     
>                                   03.02 even...*sigh*
>   
Awesome. I've been traveling this past week, and stuck at a hotel with 
out net access. Great to see the release out the door.
  --mark

From dougkearns at gmail.com  Mon Mar  5 22:37:54 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 6 Mar 2007 14:37:54 +1100
Subject: More syntax highlighting fun
In-Reply-To: <20070303161822.GZ28979@tpope.us>
References: <20070222173236.GA28979@tpope.us>
	<20070223085603.GC11127@localhost.localdomain>
	<20070223181052.GB28979@tpope.us>
	<20070224101452.GB4250@localhost.localdomain>
	<20070225014722.GE28979@tpope.us>
	<20070225083015.GB4954@localhost.localdomain>
	<20070225165050.GF28979@tpope.us>
	<20070303092401.GB3917@localhost.localdomain>
	<20070303161822.GZ28979@tpope.us>
Message-ID: <20070306033754.GA27253@localhost.localdomain>

On Sat, Mar 03, 2007 at 10:18:22AM -0600, Tim Pope wrote:
> On Sat, Mar 03, 2007 at 08:24:01PM +1100, Doug Kearns wrote:
> > On Sun, Feb 25, 2007 at 10:50:50AM -0600, Tim Pope wrote:
> > 
> > <snip>
> >  
> > > Yes, generally they should be.  I know a rather active Debian package
> > > maintainer for Vim; I'll see if I can get some answers out of him.
> > 
> > Did you have any luck?
> 
> I have word that it's going to be fixed.  I was waiting until the
> change was officially committed before posting back.

Thanks for exercising your 'influence'... ;-)

<snip>

Regards,
Doug

From vim-ruby-devel at tpope.info  Fri Mar  9 10:47:38 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 9 Mar 2007 09:47:38 -0600
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML free
	eruby filetype
Message-ID: <20070309154737.GD28979@tpope.us>

The subject says it all.  The most common use of eruby is filling out
HTML templates, but this is by no means the only use.  I think it
would be a good idea to have an rhtml filetype for html templates, and
an eruby filetype for everything else.  There is precedent for this
elsewhere:  Vim has a django filetype for Django templates and
apparently will be getting a separate djangohtml filetype.

I am well aware that changing filetypes around is not something to be
taken lightly.  I would anticipate phasing this in over a couple of
*Vim* releases.  I have no intention of even starting such a
transition until Vim 7.1 draws nearer.  At this point, I'm looking for
objections other than "this would be hard to do."  If there were
no technical or backwards compatibility restrictions, and such a
change could be made with zero side-effects, would anybody disagree
with such a change?

An alternative to this is to have a new filetype for eruby files
without HTML.  Something like plaineruby or erubytext.  This would
work but it makes me cringe, much like the tex filetype being LaTeX
and the plaintex filetype being TeX.  I'd like to make my proposed
change while Vim support for eruby is still young and evolving.

Once again, I'm looking for idealistic objections at this point rather
than practical ones.  Does anyone object to the idea of two filetypes,
or of my suggested naming scheme?

Cheers,
Tim

From hgs at dmu.ac.uk  Fri Mar  9 11:39:20 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Fri, 9 Mar 2007 16:39:20 +0000 (WET)
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070309154737.GD28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
Message-ID: <Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>

On Fri, 9 Mar 2007, Tim Pope wrote:

> The subject says it all.  The most common use of eruby is filling out
> HTML templates, but this is by no means the only use.  I think it

No, see the book "Code Generation in Action" for example.  

http://www.codegeneration.net/tiki-index.php?page=GenerationBooks

> would be a good idea to have an rhtml filetype for html templates, and
> an eruby filetype for everything else.  There is precedent for this
> elsewhere:  Vim has a django filetype for Django templates and

OK, but I've not looked at that yet, so my comments aren't based on
deep knowledge...

> apparently will be getting a separate djangohtml filetype.
> 
> transition until Vim 7.1 draws nearer.  At this point, I'm looking for
> objections other than "this would be hard to do."  If there were

The difficulty I see is that when you mix syntaxes you have to pull
in the right syntax groups, and there isn't a *simple* way to do thig
in vim.  With lots of help from Doug and others I have, for example
in my .vimrc:

function RubyMetaMake()
  :unlet! b:current_syntax
  :syntax include @MAKESTUFF ~/.vimrc_include_make_syn
  :syntax region rubyC1 matchgroup=String start=+%Q{+ end=+}+ keepend contains=@CSTUFF
  :syntax region rubyMakeString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<-MAKESTRING\ze+hs=s+3    matchgroup=rubyStringDelimiter end=+^\s*\zsMAKESTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at MAKESTUFF fold keepend
endfunction

" To MetaProgram C using Ruby
function RubyMetaC1()
  :unlet! b:current_syntax
  :syntax include @CSTUFF ~/.vimrc_include_c_syn
  :syntax region rubyC1 matchgroup=String start=+%Q{+ end=+}+ keepend contains=@CSTUFF
  :syntax region rubyC2 matchgroup=String start=+%Q(+ end=+)+ keepend contains=@CSTUFF
  :syntax region rubyC3 matchgroup=String start=+%Q<+ end=+>+ keepend contains=@CSTUFF
  :syntax region rubyC3 matchgroup=String start=+%Q?+ end=+?+ keepend contains=@CSTUFF
"  :syntax on
endfunction
function RubyMetaC2()
  unlet b:current_syntax
  syn include @cTop syntax/c.vim
  let b:current_syntax = "ruby"

  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<CSTRING\ze+hs=s+2    matchgroup=rubyStringDelimiter end=+^CSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<"CSTRING"\ze+hs=s+2  matchgroup=rubyStringDelimiter end=+^CSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<'CSTRING'\ze+hs=s+2  matchgroup=rubyStringDelimiter end=+^CSTRING$+ contains=rubyHeredocStart, at cTop		      fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<`CSTRING`\ze+hs=s+2  matchgroup=rubyStringDelimiter end=+^CSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend

  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<-CSTRING\ze+hs=s+3    matchgroup=rubyStringDelimiter end=+^\s*\zsCSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<-"CSTRING"\ze+hs=s+3  matchgroup=rubyStringDelimiter end=+^\s*\zsCSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<-'CSTRING'\ze+hs=s+3  matchgroup=rubyStringDelimiter end=+^\s*\zsCSTRING$+ contains=rubyHeredocStart, at cTop		     fold keepend
  syn region rubyCString start=+\%(\%(class\s*\|\%(\.\|::\)\)\_s*\)\@<!<<-`CSTRING`\ze+hs=s+3  matchgroup=rubyStringDelimiter end=+^\s*\zsCSTRING$+ contains=rubyHeredocStart, at rubyStringSpecial, at cTop fold keepend

  syn cluster cCommentGroup contains=cTodo,rubyInterpolation
endfunction

There are 2 ways of doing it in there.
Well, I don't call that light reading, anyway. :-)
My point is that the OTHER syntax, outside of the ruby, is nontrivial
to cnnect to, and I expect that having a syntax file for ERB will 
raise the expectation that it is trivial to get the highlighting right
for that as well at the same time.

> no technical or backwards compatibility restrictions, and such a
> change could be made with zero side-effects, would anybody disagree
> with such a change?
> 
> An alternative to this is to have a new filetype for eruby files
> without HTML.  Something like plaineruby or erubytext.  This would

Is the extension .erb already taken?

> work but it makes me cringe, much like the tex filetype being LaTeX

Assuming that
:filetype detect 
is "indistinguishable from magic", could it tell the files apart by
the presence of /<%[#=].*?%>/ ?

> and the plaintex filetype being TeX.  I'd like to make my proposed
> change while Vim support for eruby is still young and evolving.
> 
> Once again, I'm looking for idealistic objections at this point rather
> than practical ones.  Does anyone object to the idea of two filetypes,

Drat! :-)  I've answered the wrong question.  Hope soemthing in here
is of use...  In principle I'm in favour of encouraging this use of
eruby, mainly because I keep forgetting about it, and doing code generation
the hard way.  Hence all that sfuff in my vimrc.

> or of my suggested naming scheme?
> 
> Cheers,
> Tim

        Hugh

From vim-ruby-devel at tpope.info  Fri Mar  9 14:49:06 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Fri, 9 Mar 2007 13:49:06 -0600
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
Message-ID: <20070309194906.GE28979@tpope.us>

On Fri, Mar 09, 2007 at 04:39:20PM +0000, Hugh Sasse wrote:
> > The subject says it all.  The most common use of eruby is filling out
> > HTML templates, but this is by no means the only use.  I think it
> 
> No, see the book "Code Generation in Action" for example.  
> 
> http://www.codegeneration.net/tiki-index.php?page=GenerationBooks

I'd say HTML templates are still the most common, due to Rails alone,
but okay, you're actually helping make my case.

> The difficulty I see is that when you mix syntaxes you have to pull
> in the right syntax groups, and there isn't a *simple* way to do thig
> in vim.  With lots of help from Doug and others I have, for example
> in my .vimrc:
> 
> <snip>

These look to be the opposite of ERB: other syntax embedded in Ruby
rather than Ruby embedded in other syntax.

> Is the extension .erb already taken?

The extension isn't the limiting factor, the filetype is.  Having erb
for plain text and eruby for HTML is confusing.  However, it might be
a good idea to use erb rather than eruby for the new file type, so
that we end up with erb and rhtml.

> Drat! :-)  I've answered the wrong question.  Hope soemthing in here
> is of use...  In principle I'm in favour of encouraging this use of
> eruby, mainly because I keep forgetting about it, and doing code generation
> the hard way.  Hence all that sfuff in my vimrc.

If you want to use ERB with C, attached is a proof of concept for you
to try.  Drop it in ~/.vim/syntax/erb.vim.  Edit somefile.c.erb and
and :set ft=erb.  This syntax file looks at the filename to determine
what to embed.  So foo.c.erb will embed in C, foo.html.erb will embed
in HTML, and foo.sql.erb will embed in SQL.  In fact, this script
could be renamed to eruby.vim and it would more or less be a drop-in
replacement, rendering my original suggestion moot.  But all the magic
going on in the background is probably a bad idea.  If we get rid of
the magic, having a file like this would still make using ERB with
other file types a lot easier.

if exists("b:current_syntax")
  finish
endif
runtime! syntax/c.vim
unlet b:current_syntax
runtime! syntax/erb.vim
let b:current_syntax = "erbc"

That's all you would need in an erbc.vim to get ERB C highlighting.

Anyways, this is just wild brainstorming at this point.

Cheers,
Tim
-------------- next part --------------
" Vim syntax file
" Language:		ERB
" Maintainer:		Tim Pope <rails at tpope.info>
" Info:			$Id$
" URL:			http://vim-ruby.rubyforge.org
" Anon CVS:		See above site
" Release Coordinator:	Doug Kearns <dougkearns at gmail.com>

" For version 5.x: Clear all syntax items
" For version 6.x: Quit when a syntax file was already loaded
if version < 600
  syntax clear
elseif exists("b:current_syntax")
  finish
endif

if !exists("main_syntax")
  let main_syntax = 'eruby'
endif

" Always check for this magic hearder
let s:type = matchstr(getline(1),'erb_syntax=\zs\w\+')
" Check extension if main_syntax wasn't set
if main_syntax == 'eruby' && s:type == ''
  let s:type = matchstr(substitute(expand("%:t"),'\.erb$','',''),'\.\zs\w\+$')
endif
if s:type == 'rhtml'
  let s:type = 'html'
endif

if version < 600
  syn include @rubyTop <sfile>:p:h/ruby.vim
else
  if s:type != ''
    exe "runtime! syntax/".s:type.".vim"
    unlet! b:current_syntax
  endif
  syn include @rubyTop syntax/ruby.vim
endif

syn cluster erbRegions contains=erbOneLiner,erbBlock,erbExpression,erbComment

syn region  erbOneLiner   matchgroup=erbDelimiter start="^%%\@!"    end="$"     contains=@rubyTop	     containedin=ALLBUT, at erbRegions keepend oneline
syn region  erbBlock      matchgroup=erbDelimiter start="<%%\@!-\=" end="-\=%>" contains=@rubyTop	     containedin=ALLBUT, at erbRegions
syn region  erbExpression matchgroup=erbDelimiter start="<%="       end="-\=%>" contains=@rubyTop	     containedin=ALLBUT, at erbRegions
syn region  erbComment    matchgroup=erbDelimiter start="<%#"       end="-\=%>" contains=rubyTodo, at Spell containedin=ALLBUT, at erbRegions keepend

" Define the default highlighting.
" For version 5.7 and earlier: only when not done already
" For version 5.8 and later: only when an item doesn't have highlighting yet
if version >= 508 || !exists("did_erb_syntax_inits")
  if version < 508
    let did_ruby_syntax_inits = 1
    command -nargs=+ HiLink hi link <args>
  else
    command -nargs=+ HiLink hi def link <args>
  endif

  HiLink erbDelimiter		Delimiter
  HiLink erbComment		Comment

  delcommand HiLink
endif
let b:current_syntax = "erb"

if main_syntax == 'eruby'
  unlet main_syntax
endif

" vim: nowrap sw=2 sts=2 ts=8 ff=unix:

From dougkearns at gmail.com  Sat Mar 10 00:52:02 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 10 Mar 2007 16:52:02 +1100
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070309154737.GD28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
Message-ID: <20070310055202.GF3155@localhost.localdomain>

On Fri, Mar 09, 2007 at 09:47:38AM -0600, Tim Pope wrote:
> The subject says it all.  The most common use of eruby is filling out
> HTML templates, but this is by no means the only use.  I think it
> would be a good idea to have an rhtml filetype for html templates, and
> an eruby filetype for everything else.  There is precedent for this
> elsewhere:  Vim has a django filetype for Django templates and
> apparently will be getting a separate djangohtml filetype.

What is special, other than its current predominance, of rhtml over
other files containing eRuby?  Why should rhtml files be given special
treatment and rfoo and rbar files be lumped together in some other
generic eRuby filetype?
 
> I am well aware that changing filetypes around is not something to be
> taken lightly.  I would anticipate phasing this in over a couple of
> *Vim* releases.  I have no intention of even starting such a
> transition until Vim 7.1 draws nearer.  At this point, I'm looking for
> objections other than "this would be hard to do."  If there were
> no technical or backwards compatibility restrictions, and such a
> change could be made with zero side-effects, would anybody disagree
> with such a change?

Allowing other 'host' filetypes to work is actually something on my ever
growing TODO list but I don't actually use eRuby so motivation can be
hard to come by... ;-)  I'm glad you're working on it - thanks.
 
> An alternative to this is to have a new filetype for eruby files
> without HTML.  Something like plaineruby or erubytext.  This would
> work but it makes me cringe,

YUCK!

> much like the tex filetype being LaTeX
> and the plaintex filetype being TeX.  I'd like to make my proposed
> change while Vim support for eruby is still young and evolving.
> 
> Once again, I'm looking for idealistic objections at this point rather
> than practical ones.  Does anyone object to the idea of two filetypes,
> or of my suggested naming scheme?

Well, again, it seems to me that there shouldn't really be an
"idealistic" need to make a special case for rhtml files.  What am I
missing?
 
The implementation is, as always, a whole other matter...

Regards,
Doug

From dougkearns at gmail.com  Sat Mar 10 00:58:39 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 10 Mar 2007 16:58:39 +1100
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070309194906.GE28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
Message-ID: <20070310055839.GG3155@localhost.localdomain>

On Fri, Mar 09, 2007 at 01:49:06PM -0600, Tim Pope wrote:
> On Fri, Mar 09, 2007 at 04:39:20PM +0000, Hugh Sasse wrote:

<snip>
 
> The extension isn't the limiting factor, the filetype is.  Having erb
> for plain text and eruby for HTML is confusing.  However, it might be
> a good idea to use erb rather than eruby for the new file type, so
> that we end up with erb and rhtml.

Isn't erb, along with eruby and possibly others, just an
_implementation_ of eRuby?
 
> > Drat! :-)  I've answered the wrong question.  Hope soemthing in here
> > is of use...  In principle I'm in favour of encouraging this use of
> > eruby, mainly because I keep forgetting about it, and doing code generation
> > the hard way.  Hence all that sfuff in my vimrc.
> 
> If you want to use ERB with C, attached is a proof of concept for you
> to try.  Drop it in ~/.vim/syntax/erb.vim.  Edit somefile.c.erb and
> and :set ft=erb.  This syntax file looks at the filename to determine
> what to embed.  So foo.c.erb will embed in C, foo.html.erb will embed
> in HTML, and foo.sql.erb will embed in SQL.  In fact, this script
> could be renamed to eruby.vim and it would more or less be a drop-in
> replacement, rendering my original suggestion moot.

This is what I had in mind but it's more difficult to get this right
with the ftplugins.

> But all the magic
> going on in the background is probably a bad idea.  If we get rid of
> the magic, having a file like this would still make using ERB with
> other file types a lot easier.

I like magic. :-)

<snip>
 
Regards,
Doug

From hgs at dmu.ac.uk  Mon Mar 12 05:55:43 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Mon, 12 Mar 2007 09:55:43 +0000 (WET)
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070309194906.GE28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
Message-ID: <Pine.GSO.4.64.0703120950580.18181@brains.eng.cse.dmu.ac.uk>

On Fri, 9 Mar 2007, Tim Pope wrote:

> On Fri, Mar 09, 2007 at 04:39:20PM +0000, Hugh Sasse wrote:
> > > The subject says it all.  The most common use of eruby is filling out
> > > HTML templates, but this is by no means the only use.  I think it
> > 
> > No, see the book "Code Generation in Action" for example.  
> > 
> > http://www.codegeneration.net/tiki-index.php?page=GenerationBooks
> 
> I'd say HTML templates are still the most common, due to Rails alone,
> but okay, you're actually helping make my case.
> 
> > The difficulty I see is that when you mix syntaxes you have to pull
> > in the right syntax groups, and there isn't a *simple* way to do thig
> > in vim.  With lots of help from Doug and others I have, for example
> > in my .vimrc:
> > 
> > <snip>
> 
> These look to be the opposite of ERB: other syntax embedded in Ruby
> rather than Ruby embedded in other syntax.

The principles still apply: to embed one syntax in another is not
trivial, except what you've written below challenges that.
> 
> > Is the extension .erb already taken?
> 
> The extension isn't the limiting factor, the filetype is.  Having erb
> for plain text and eruby for HTML is confusing.  However, it might be
> a good idea to use erb rather than eruby for the new file type, so
> that we end up with erb and rhtml.
> 
> > Drat! :-)  I've answered the wrong question.  Hope soemthing in here
> > is of use...  In principle I'm in favour of encouraging this use of
> > eruby, mainly because I keep forgetting about it, and doing code generation
> > the hard way.  Hence all that sfuff in my vimrc.
> 
> If you want to use ERB with C, attached is a proof of concept for you
> to try.  Drop it in ~/.vim/syntax/erb.vim.  Edit somefile.c.erb and
> and :set ft=erb.  This syntax file looks at the filename to determine
> what to embed.  So foo.c.erb will embed in C, foo.html.erb will embed
> in HTML, and foo.sql.erb will embed in SQL.  In fact, this script
> could be renamed to eruby.vim and it would more or less be a drop-in
> replacement, rendering my original suggestion moot.  But all the magic
> going on in the background is probably a bad idea.  If we get rid of
> the magic, having a file like this would still make using ERB with
> other file types a lot easier.
> 
> if exists("b:current_syntax")
>   finish
> endif
> runtime! syntax/c.vim
> unlet b:current_syntax
> runtime! syntax/erb.vim
> let b:current_syntax = "erbc"
> 
> That's all you would need in an erbc.vim to get ERB C highlighting.
> 
OK, I'll have to have a go with this, and it's variants.  Thank you.

> Anyways, this is just wild brainstorming at this point.
> 
> Cheers,
> Tim
> 

        Hugh

From vim-ruby-devel at tpope.info  Mon Mar 12 17:32:01 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 12 Mar 2007 16:32:01 -0500
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070310055202.GF3155@localhost.localdomain>
References: <20070309154737.GD28979@tpope.us>
	<20070310055202.GF3155@localhost.localdomain>
Message-ID: <20070312213201.GH28979@tpope.us>

On Sat, Mar 10, 2007 at 04:52:02PM +1100, Doug Kearns wrote:
> On Fri, Mar 09, 2007 at 09:47:38AM -0600, Tim Pope wrote:
> > The subject says it all.  The most common use of eruby is filling out
> > HTML templates, but this is by no means the only use.  I think it
> > would be a good idea to have an rhtml filetype for html templates, and
> > an eruby filetype for everything else.  There is precedent for this
> > elsewhere:  Vim has a django filetype for Django templates and
> > apparently will be getting a separate djangohtml filetype.
> 
> What is special, other than its current predominance, of rhtml over
> other files containing eRuby?  Why should rhtml files be given special
> treatment and rfoo and rbar files be lumped together in some other
> generic eRuby filetype?

<snip>

> Well, again, it seems to me that there shouldn't really be an
> "idealistic" need to make a special case for rhtml files.  What am I
> missing?
>  
> The implementation is, as always, a whole other matter...

I can't really name a good reason other than popularity and "they're
getting special treatment now anyways".  Idealistically, one filetype
to rule them all does indeed sounds grand.  But I was breaking my own
rule and taking the practicalities into account when I suggested two.

Cheers,
Tim

From vim-ruby-devel at tpope.info  Mon Mar 12 17:39:16 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Mon, 12 Mar 2007 16:39:16 -0500
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070310055839.GG3155@localhost.localdomain>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
	<20070310055839.GG3155@localhost.localdomain>
Message-ID: <20070312213916.GI28979@tpope.us>

On Sat, Mar 10, 2007 at 04:58:39PM +1100, Doug Kearns wrote:
> Isn't erb, along with eruby and possibly others, just an
> _implementation_ of eRuby?

I haven't managed to confirm either way with google.

> > If you want to use ERB with C, attached is a proof of concept for you
> > to try.  Drop it in ~/.vim/syntax/erb.vim.  Edit somefile.c.erb and
> > and :set ft=erb.  This syntax file looks at the filename to determine
> > what to embed.  So foo.c.erb will embed in C, foo.html.erb will embed
> > in HTML, and foo.sql.erb will embed in SQL.  In fact, this script
> > could be renamed to eruby.vim and it would more or less be a drop-in
> > replacement, rendering my original suggestion moot.
> 
> This is what I had in mind but it's more difficult to get this right
> with the ftplugins.

Yes, this is partially why I suggested a separate rhtml filetype.
Things like indenting may prove nearly impossible to hack together.
> 
> > But all the magic
> > going on in the background is probably a bad idea.  If we get rid of
> > the magic, having a file like this would still make using ERB with
> > other file types a lot easier.
> 
> I like magic. :-)

So long as it works properly.  If the one magic filetype detects the
embedded language incorrectly, it may prove difficult to override.

Perhaps we should start by making a list of common filetypes combined
with eruby, so we can see what the common cases are.  So far I have

HTML
YAML - used with ERB in Rails
C - as mentioned by Hugh Sasse

Cheers,
Tim

From dougkearns at gmail.com  Mon Mar 12 20:48:27 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 13 Mar 2007 11:48:27 +1100
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070312213916.GI28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
	<20070310055839.GG3155@localhost.localdomain>
	<20070312213916.GI28979@tpope.us>
Message-ID: <20070313004827.GB3290@localhost.localdomain>

On Mon, Mar 12, 2007 at 04:39:16PM -0500, Tim Pope wrote:
> On Sat, Mar 10, 2007 at 04:58:39PM +1100, Doug Kearns wrote:
> > Isn't erb, along with eruby and possibly others, just an
> > _implementation_ of eRuby?
> 
> I haven't managed to confirm either way with google.

I turned up these...

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/1731
"I wrote 'Tiny eRuby - ERb'. 
ERb is an implementation of eRuby (embedded ruby)."

http://www.modruby.net/en/index.rbx/eruby/whatis.html

http://en.wikipedia.org/wiki/Eruby
http://en.wikipedia.org/wiki/Erb
...so it must be true. ;-)

<snip>

Regards,
Doug

From dougkearns at gmail.com  Tue Mar 13 01:01:59 2007
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 13 Mar 2007 16:01:59 +1100
Subject: eRuby and matchit
Message-ID: <20070313050159.GA12843@localhost.localdomain>

Tim,

I noticed this recent ChangeLog entry.

2002-03-09  Tim Pope  <vim at tpope.info>

	* ftplugin/ruby.vim: Skip class= and for= with matchit (really
	  belongs in ftplugin/eruby.vim).

I've actually got a patch lying around for eRuby which I'll post later
that attempts to fix this by joining both the b:match_words and
b:match_skip values.  One of the problems with this approach, which I've
mentioned to Benji, is having to parse the s:, S:, r: and R:
abbreviations for b:match_skip.

This is a good example of where the 'magic' approach to the eRuby
filetype breaks down as, from memory, I had to manually add a couple of
extra HTML syntax groups to skip. :)

Regards,
Doug

From hgs at dmu.ac.uk  Tue Mar 13 06:08:38 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Tue, 13 Mar 2007 10:08:38 +0000 (WET)
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070312213916.GI28979@tpope.us>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
	<20070310055839.GG3155@localhost.localdomain>
	<20070312213916.GI28979@tpope.us>
Message-ID: <Pine.GSO.4.64.0703131003410.18181@brains.eng.cse.dmu.ac.uk>

On Mon, 12 Mar 2007, Tim Pope wrote:

> Perhaps we should start by making a list of common filetypes combined
> with eruby, so we can see what the common cases are.  So far I have
> 
> HTML
> YAML - used with ERB in Rails
> C - as mentioned by Hugh Sasse
  Java -- See Code Generation In Action, mentioned before.

  There is a school of thought that programmers consider
  [0, 1, Many] as the numbers that are important.  Thus I suggest
  C + Java  implies C#, C++, ... and any language which doesn't have
  it's own templater available.  Things like Perl and Lua may not
  need ERB...  Which doesn't mean someone won't use it anyway.

        Hugh

From hgs at dmu.ac.uk  Tue Mar 13 06:24:11 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Tue, 13 Mar 2007 10:24:11 +0000 (WET)
Subject: eRuby and matchit
In-Reply-To: <20070313050159.GA12843@localhost.localdomain>
References: <20070313050159.GA12843@localhost.localdomain>
Message-ID: <Pine.GSO.4.64.0703131020020.18181@brains.eng.cse.dmu.ac.uk>

On Tue, 13 Mar 2007, Doug Kearns wrote:

> Tim,
> 
> I noticed this recent ChangeLog entry.
> 
> 2002-03-09  Tim Pope  <vim at tpope.info>
> 
> 	* ftplugin/ruby.vim: Skip class= and for= with matchit (really
> 	  belongs in ftplugin/eruby.vim).
> 
> I've actually got a patch lying around for eRuby which I'll post later
> that attempts to fix this by joining both the b:match_words and
> b:match_skip values.  One of the problems with this approach, which I've
> mentioned to Benji, is having to parse the s:, S:, r: and R:
> abbreviations for b:match_skip.

Yes, the C embedded in Ruby stuff that I posted has a problem in that
any "if" in the C upsets the searches for mmatching (class|def|if|...)...end
in the surrounding ruby, but not as far as colouring is concerned, only
as far as % is concerned.  I wouldn't know where to start fixing that.

        Hugh

From vim-ruby-devel at tpope.info  Tue Mar 20 11:38:32 2007
From: vim-ruby-devel at tpope.info (Tim Pope)
Date: Tue, 20 Mar 2007 10:38:32 -0500
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <Pine.GSO.4.64.0703131003410.18181@brains.eng.cse.dmu.ac.uk>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
	<20070310055839.GG3155@localhost.localdomain>
	<20070312213916.GI28979@tpope.us>
	<Pine.GSO.4.64.0703131003410.18181@brains.eng.cse.dmu.ac.uk>
Message-ID: <20070320153831.GK5710@tpope.us>

On Tue, Mar 13, 2007 at 10:08:38AM +0000, Hugh Sasse wrote:
> On Mon, 12 Mar 2007, Tim Pope wrote:
> > Perhaps we should start by making a list of common filetypes combined
> > with eruby, so we can see what the common cases are.  So far I have
> > 
> > HTML
> > YAML - used with ERB in Rails
> > C - as mentioned by Hugh Sasse
>   Java -- See Code Generation In Action, mentioned before.
> 
>   There is a school of thought that programmers consider
>   [0, 1, Many] as the numbers that are important.  Thus I suggest
>   C + Java  implies C#, C++, ... and any language which doesn't have
>   it's own templater available.  Things like Perl and Lua may not
>   need ERB...  Which doesn't mean someone won't use it anyway.

I certainly agree, glad you're still keeping idealistic.  But when it
comes down to implementation supporting every possible filetype may
not be possible, so I want to get an idea of what to prioritize.  I
will keep all these "compiled" languages in mind.  As you point out,
uses of eruby with Perl and Lua are corner cases at best, and not
worth worrying about so much.

To all, thanks for the feedback.  I'm going to sit on this a while and
think things over.  Right now, I'm thinking something vaguely like the
following:

An eruby syntax file which highlights the non-Ruby parts as plain text.
This file can be :source'd and combined with other filetypes in a
relatively straightforward manner.

An rhtml syntax file that combines the eruby syntax file and html
syntax file.  This would serve both as an example of how to combine
filetypes and also fulfill the most common (according to me) need of
using html with eruby.

I still haven't decided about ftplugins and indent plugins.  Ideally
they could parallel the syntax files with combining but I haven't
looked into how feasible that is.

Cheers,
Tim

From hgs at dmu.ac.uk  Wed Mar 21 06:12:20 2007
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Wed, 21 Mar 2007 10:12:20 +0000 (WET)
Subject: Drastic proposal: rename eruby to rhtml to make way for an HTML
	free eruby filetype
In-Reply-To: <20070320153831.GK5710@tpope.us>
References: <20070309154737.GD28979@tpope.us>
	<Pine.GSO.4.64.0703091621120.25126@brains.eng.cse.dmu.ac.uk>
	<20070309194906.GE28979@tpope.us>
	<20070310055839.GG3155@localhost.localdomain>
	<20070312213916.GI28979@tpope.us>
	<Pine.GSO.4.64.0703131003410.18181@brains.eng.cse.dmu.ac.uk>
	<20070320153831.GK5710@tpope.us>
Message-ID: <Pine.GSO.4.64.0703211003330.26367@brains.eng.cse.dmu.ac.uk>

On Tue, 20 Mar 2007, Tim Pope wrote:

> On Tue, Mar 13, 2007 at 10:08:38AM +0000, Hugh Sasse wrote:
> > On Mon, 12 Mar 2007, Tim Pope wrote:
> > > Perhaps we should start by making a list of common filetypes combined
> > > with eruby, so we can see what the common cases are.  So far I have
> > > 
> > > HTML
> > > YAML - used with ERB in Rails
> > > C - as mentioned by Hugh Sasse
> >   Java -- See Code Generation In Action, mentioned before.
> > 
> >   There is a school of thought that programmers consider
> >   [0, 1, Many] as the numbers that are important.  Thus I suggest
> >   C + Java  implies C#, C++, ... and any language which doesn't have
> >   it's own templater available.  Things like Perl and Lua may not
> >   need ERB...  Which doesn't mean someone won't use it anyway.
> 
> I certainly agree, glad you're still keeping idealistic.  But when it

Idealistic?  :-)  I'm being cynical -- trying to think of ways 
people will break it before it exists :-)

> comes down to implementation supporting every possible filetype may

No, but allowing people to do their own support is another matter.
Leaving things open, and the idea of plugins...

> not be possible, so I want to get an idea of what to prioritize.  I
> will keep all these "compiled" languages in mind.  As you point out,
> uses of eruby with Perl and Lua are corner cases at best, and not
> worth worrying about so much.
> 
> To all, thanks for the feedback.  I'm going to sit on this a while and
> think things over.  Right now, I'm thinking something vaguely like the
> following:
> 
> An eruby syntax file which highlights the non-Ruby parts as plain text.
> This file can be :source'd and combined with other filetypes in a
> relatively straightforward manner.

With you so far...
> 
> An rhtml syntax file that combines the eruby syntax file and html
> syntax file.  This would serve both as an example of how to combine
> filetypes and also fulfill the most common (according to me) need of
> using html with eruby.

Yes, agree with this too...
> 
> I still haven't decided about ftplugins and indent plugins.  Ideally
> they could parallel the syntax files with combining but I haven't
> looked into how feasible that is.

Maybe we need an enhancement request, but it would be nice if there
were a way to pass "the other text" that we now treat as plain, to 
the 'filetype detect' system of Vim, like we'd pass stuff to a block
in Ruby.  No, I don't know how to do that at present.
> 
> Cheers,
> Tim
        Hugh