Addition of some new files

Thomas Adam thomas at
Wed Feb 15 07:39:28 EST 2006

Gavin, et al. --

On Wed, Feb 15, 2006 at 06:12:06PM +1100, Gavin Sinclair wrote:
> Hi Thomas,


> Thanks for the contribution. It's not overkill and you're not treading
> on anyone's toes. I'd love to see all of those things in the vim-ruby
> distribution.

Hehe.  OK.  :)

> One issue is organising all those features: would they be switched on
> by default? I don't think so, because we don't want to trash people's
> existing settings, like key-bindings. So then, how do we make it
> really easy to enable the features? And I mean _really_ easy.

Well, this is something I have given a lot of thought to.  I
whole-heartedly agree that we cannot just turn on these features by
default, since that would effectively break existing methods of working
with people that:  a)  Use different folding techniques, and b)  Have a
different set of key-bindings.

The only way I can see this being any use (such that things don't break
with existing settings) is having some sort of wrapper script, akin to
vim-ruby-install.rb.  I know this is a real kludge, but it would
effectively allow the explicit denial or customisations of certain
features.  But then there are issues with it --- the assumption here is
that people are already using Vim as a default editor.  It might be some
are not -- at least not to the extent such that they'd _know_ the
differences between the various different folding techniques, for

It's a tricky one, alright.  I wouldn't want them to be 'on' by default.
I suppose you could have some option of "plugins" made available.  I
assume this is what you were getting at with your suggestion below with:

:ruby-vim convert-block

command?  (That would probably have to start with a capital letter, as
it's a potential user-command, of course.)  That would at least allow
for optional pieces of functionality to be loaded, and presumably
wouldn't break too much by way of existing settings a particular #{user}
might have.

> Also to do with organisation is a good set of keybindings that covers
> everything, making them kind of predictable. Perhaps it would be nice
> to have one interface command, like :ruby_vim which takes arguments
> like the following:
>   :ruby_vim convert-block :ruby_vim fold-on-method ... :ruby_vim
>   list-commands :ruby_vim help fold-on-method

I agree.  There's two options that I can see we have here:

1.  We don't supply any default key-bindings at all, in preference of a
    #{user} selecting them for his/her self to maintain non-breakage.


2.  We just provide a default set of key-bindings that would allow
    certain functionality to be present -- and hence load *all* the
    plugins to suit a necessary environment.

Quite honestly, I know that (2) is used a lot in EMACS.  I've not used
it -- but I know that its plugins provides various different
key-bindings irrespective of them already being defined.

>   nunmap <M-r> :ruby-vim fold-on-method<CR>
> as a completely made-up example. The point is that it would be easy
> for someone to see what the key bindings were, and change them if they
> wanted.

Absolutely.  Maybe having an interface such as this would be a good
thing -- it would certainly make maintainability quite easy, no?  And it
would mean that the potential user probably doesn't have to relearn
different :commands, just to satisfy different plugins because they each
have their own 'interface', as it were.

> The next issue is documentation. Of course, the great benefit of
> incorporating this stuff into ruby-vim is that it can be documented
> all in one place, with consistent layout and quality, etc. The
> downside is that someone has to do it.

But to me, that's part and parcel of any proposal.  I am *more* than
willing to document the necessary features/changes so that things are
made clear to anyone who might need help with a certain feature, etc.

> So if you want to follow up on these ideas, Thomas, or invent a
> management and documentation approach of your own, I'd love to see it.
> It would be included in an instant -- providing there's no serious
> dissent from other list members.

This is something I'd like input on from others -- perhaps we can flesh
these ideas out a bit more?  I'm more than happy to devote time to
design and/or documenting whatever is necessary.

> One last thing, Thomas. Are you aware of the snippets implementation
> for Vim being worked on by Jeff Rose? It's very powerful, very cool,
> and another thing that will hopefully be worked into the distribution
> before long.

I am not aware of it, although as I type this I see an email from Jeff
that looks like it might well mention 'snippets'.  Expect a follow-up
email to that thread.  :)


-- Thomas Adam

I've been too honest with myself, I should have lied like everybody else.

More information about the vim-ruby-devel mailing list