Moved from plugin to ftplugin #79

Open
wants to merge 5 commits into
from

Projects

None yet

2 participants

@dhruvasagar

Rdebugger specific mappings & commands make sense to be available only
in ruby files, so switched to a ftplugin instead and defined the
mappings & commands to be buffer localized so as to be available only
for those buffers and not for others for which it was not intended.

@dhruvasagar dhruvasagar Removed plugin and added ftplugin instead
Rdebugger specific mappings & commands make sense to be available only
in ruby files, so switched to a ftplugin instead and defined the
mappings & commands to be buffer localized so as to be available only
for those buffers and not for others for which it was not intended.
2ce60e8
@astashov
Owner

Hi!

Thanks for the pull request, but as for me, since it makes sense from the first view, you don't always want to start :Rdebugger from only the Ruby files. E.g. I'm working on Rails project, and I've got Javascript or YAML file opened, and I need to restart the server - I'm trying to do that, but it says - no such command, so I have to switch to some Ruby file first to actually restart the server.

What problem it actually solves? Why we don't want to have :Rdebugger command available in any file type?

@dhruvasagar

Hey,

I will work further on this and support rails applications as well, I will allow it to be used under a rails app :), i'll refer to rails.vim for the same.

As far as the reason for this, well the primary motivation I had for this is that this stalls vim for a bit when used without the right context be set. Or if I run it accidentally somewhere I didn't intend to.

Since this is meant to debug ruby to me, it made more sense to be available only for ruby projects, I did miss out for rails, so will work on that now.

The other thing (off topic), that I was thinking is what do you think about a rewrite of this plugin, but predominantly in ruby ? Since it is for debugging ruby, I think we will be able to write it better in ruby itself, surely dependence on ruby support is not an issue since after all we are debugging ruby.

@astashov
Owner

this stalls vim for a bit when used without the right context be set

That's actually weird, do you know the reason? It shouldn't even do anything until you explicitly run it by :Rdebugger.

The other thing (off topic), that I was thinking is what do you think about a rewrite of this plugin, but predominantly in ruby?

Why to do that? That is a lot of work, not sure what would be the win here. :)

@dhruvasagar

this stalls vim for a bit when used without the right context be set

That's actually weird, do you know the reason? It shouldn't even do anything until you explicitly run it by :Rdebugger.

The most common use case : I tend to launch gvim from gnome-do, an app launcher. I use nerdtree to switch to a bookmarked project directory, or I use vim-sessions and gvim then loads the project automatically remember last opened files when I was working on the same. And I launch ruby - debugger, and it will fail and stall (hang) vim for a couple or so seconds, since the ruby is not set at all, because of rvm. I have to switch / define the right ruby to be used with the help of rvm, for which I use vim-rvm plugin. Only after that is done, rdebugger works fine.

The other thing (off topic), that I was thinking is what do you think about a rewrite of this plugin, but predominantly in ruby?

Why to do that? That is a lot of work, not sure what would be the win here. :)

Here are my thoughts :

  • Being written in ruby, it should be easier to support latest ruby debugger api. (We can even go a step ahead and use our own ruby debugger that uses the ruby trace api to make it even faster.)
  • Being written in ruby, it should be a lot easier to deal with processes rather than relying on lsof or other such workarounds and again would perform better.
  • The very reason why I love Ruby is the fact that it is extremely expressive, writing this code in ruby will surely mean that the code is a lot more beautiful, easier to understand and hence will attract a lot more community support in the long run.

Who knows, maybe we could even debug ruby-debugger using itself ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment