Addition of some new files

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Addition of some new files

Thomas Adam-2
 Hello all,

 I'm impressed with vim-ruby -- although I thought it would be nice to
 include some addition files, especially the ones on rubygarden.org.
 What I am proposing, isn't my own work.  Essentially they're vim files
 that I have seen on the web, although all of them are under the GPL.  I
 have made some modifications to some of the files.

 From what I can currently tell, vim-ruby has indent, syntax and
 compiler support, with ri support as well.  This is great, and it does
 exactly what I would have expected.  However the files I'd like to see
 distributed with it are the ones found in here:

 http://edulinux.homeunix.org/~n6tadam/vim-ruby/

 block_eval is really useful in that it converts a block of code, hence:

 [1,2,3].each {|a| p a}

 into:

 [1,2,3] do |a|
    p a
 end

 ... and vice-versa, via the mapping ":B".  

 vim_folding does something similar for method definitions, via ":R"
 (and :zi/:za).

 ruby_structure -- this was from rubygarden -- essentially it allows
 one to use Shift + Enter to ident and complete various code blocks.   I
 can't tell you how useful this has been in the past.

 ruby_xml -- probably my most favourite -- in-line evaluation.  Perhaps
 better than irb in many ways.   I have the various functions of it
 bound to F5, F6 and F7 -- this was shamelessly stolen from
 rubygarden.org again.

 You may consider this overkill -- I apologise in advance.  I certainly
 do not wish to tread on anyone's toes as it were.  I was also thinking
 of writing a simple menu vim file for gvim -- so that you could access
 the various functions of these scripts.  Might make it more appealing
 -- and I already have a something like it which I use for my own
 purposes.
 
 I am more than happy to help out however I can, of course.

-- Thomas Adam

--  
I've been too honest with myself, I should have lied like everybody else.
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: Addition of some new files

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

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.

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

Now it's me who's getting into overkill.  But anyway, this sort of
idea could be the basis for making it easy to manage all the tricks
that are implemented.  Of course, then you have key bindings to each
of those commands, like

  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.

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.

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.

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.

Cheers,
Gavin

On 2/10/06, Thomas Adam <[hidden email]> wrote:

>  Hello all,
>
>  I'm impressed with vim-ruby -- although I thought it would be nice to
>  include some addition files, especially the ones on rubygarden.org.
>  What I am proposing, isn't my own work.  Essentially they're vim files
>  that I have seen on the web, although all of them are under the GPL.  I
>  have made some modifications to some of the files.
>
>  From what I can currently tell, vim-ruby has indent, syntax and
>  compiler support, with ri support as well.  This is great, and it does
>  exactly what I would have expected.  However the files I'd like to see
>  distributed with it are the ones found in here:
>
>  http://edulinux.homeunix.org/~n6tadam/vim-ruby/
>
>  block_eval is really useful in that it converts a block of code, hence:
>
>  [1,2,3].each {|a| p a}
>
>  into:
>
>  [1,2,3] do |a|
>    p a
>  end
>
>  ... and vice-versa, via the mapping ":B".
>
>  vim_folding does something similar for method definitions, via ":R"
>  (and :zi/:za).
>
>  ruby_structure -- this was from rubygarden -- essentially it allows
>  one to use Shift + Enter to ident and complete various code blocks.   I
>  can't tell you how useful this has been in the past.
>
>  ruby_xml -- probably my most favourite -- in-line evaluation.  Perhaps
>  better than irb in many ways.   I have the various functions of it
>  bound to F5, F6 and F7 -- this was shamelessly stolen from
>  rubygarden.org again.
>
>  You may consider this overkill -- I apologise in advance.  I certainly
>  do not wish to tread on anyone's toes as it were.  I was also thinking
>  of writing a simple menu vim file for gvim -- so that you could access
>  the various functions of these scripts.  Might make it more appealing
>  -- and I already have a something like it which I use for my own
>  purposes.
>
>  I am more than happy to help out however I can, of course.
>
> -- Thomas Adam
>
> --
> I've been too honest with myself, I should have lied like everybody else.
> _______________________________________________
> vim-ruby-devel mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/vim-ruby-devel
>

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: Addition of some new files

Thomas Adam-2
Gavin, et al. --

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

Hello.

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

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.

or:

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

Kindly,

-- Thomas Adam

--  
I've been too honest with myself, I should have lied like everybody else.
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel