ANN: New stable release

[Doug Kearns]

On Fri, Sep 16, 2005 at 11:59:32AM +0100, Hugh Sasse wrote:
> On Fri, 16 Sep 2005, Doug Kearns wrote:

<snip>

> I don't think there's an official definition for these extensions,
> but I use .erb for _any_ other filetype, when .rhtml is not
> appropriate.  I don't know what others do.  (Ruby is very Unixy (for
> want of a word!) and people don't discuss extension names that much
> :-))

Right, well this is going to be 'interesting' to implement. I guess we'd
need to run scripts.vim to determine the main filetype...

<snip>
 
> I'll see if I can find a more concise example.  There's lots of junk
> in it, but it was the first that I was playing with.  Will you still
> need this if the ".erb implies html" assumption is false?

No, thanks. A simple XML file with .erb extension is exhibiting this
behaviour. I may just be misunderstanding the way filetype detection
works.

<snip>
 
> I only have one a/c on the machine just now, but I'd like others to
> get the benefit.  Similary on Unix.  I usually put the vim stuff to
> be system wide so everyone benefits, and if I have to help them I
> can spin up vim and have it work sensibly.  [cf the PragProg advice
> about use one edior and learn it well: you don't want it to change
> too much just because you're logged in as someone else (who never
> uses that editor, anyway).]

Right. Obviously the installer allows you to install it anywhere you
like but, I would think, the scenario you describe is best served by an
install in $VIM/vimfiles.
 
> > multiple versions of Vim and trying to restrict the use of the vim-ruby
> 
> I was running 62 and 63 at the same time for a while, but I thought
> it would install in the latest.

If you install in $VIM/vimfiles then these files will be available,
system-wide, to all versions. However, the ftdetect mechanism was
introduced in 6.3 so earlier versions will require a filetype.vim to be
constructed as per :help new-filetype. So even if you didn't manually
add a new filetype.vim, 6.2 would still have access to all the updated
vim-ruby files. The only difference would be that eRuby files weren't
autodetected.

I can't really see a down side to this setup. Perhaps this is where we
should start rambling about POLS? ;-)
 
> > files to a single version, perhaps? If you keep it in $VIMRUNTIME the
> > next time you update Vim you'll overwrite the vim-ruby files. While the
> 
> Which is fair enough.  I know we've had problems with keeping in
> sync with the vim distro before, so I usually install again after
> updating vim.  Not that I've updated vim that often, only been using
> it since about 5.7.

You are but a young pup. ;-)
 
> > Vim release might have the latest files it's certainly not going to have
> > newer versions than this project. ;-)
> >
> >>          * * *
> >>
> >> Now, earlier today I installed the gem on a sun system.  It told me
> >> to run the installer afterwards, but didn't remind me where it was
> >> hidden.  Is that relatively easy to fix?  When I get a moment I'll
> >> poke around with gem environment....
> >
> > I'm assuming that people running rubygems will have $GEM_HOME/bin in
> > their PATH. Have you just blown that assumption out of the water? ;-)
> 
> Ah. Maybe I've not configured my settings correctly:
> GEM_HOME: Undefined variable.

<snip>

Nope - sky high! ;-)

It seems that GEM_HOME is only required for a 'user' install. Though the
core assumption is still correct.

> > When you say "remind me" are you referring to the INSTALL instructions?
> gem query -l -n vim =>
> 
> *** LOCAL GEMS ***
> 
> vim-ruby (2005.09.15, 2005.07.27)
>      Ruby configuration files for Vim.  Run 'vim-ruby-install.rb' to
>      complete installation.
> 
> So it has detected the need for this?

This is all Gavin's work and I assume that he knew what he was doing as
he's a rubygems developer. ;-)

I just performed a default system-wide install of rubygems and it
appears to install the executable scripts in /usr/bin - the same place
'gem' is located. So there shouldn't be any need to specify a location
for the installer script.

If it's not in your PATH maybe your installation is, in some way,
'corrupted'?

<snip>

> > PS. We haven't had the usual flood of post-release discussion so I'm
> > hoping all is, generally, running smoothly...
> 
> Or those in .ac.?? and .edu are going nuts in preparation for the
> start of the academic year and have not had chance to tackle this.

I'll await their return to these matters then. ;-)

Thanks,
Doug