Skip to content

Moved from plugin to ftplugin #79

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Moved from plugin to ftplugin #79

wants to merge 5 commits into from

Conversation

dhruvasagar
Copy link

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.

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.
@astashov
Copy link
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
Copy link
Author

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
Copy link
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
Copy link
Author

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants