Handling differences in different plugins for the same type of operation

[Patrik Iselind]

I'm looking for refactoring support in Vim, specifically for C, Python, and Go. It would probably suffice with renaming functions/variables and extracting function/method. My problem is that of being forced to keep multiple mappings for the same things just depending on which file type i'm working on at the moment.

For Python i know there is a plug in that is built around rope, https://github.com/python-rope/ropevim.

In Go there are both the Go Doctor, http://gorefactor.org/, and vim-go, https://github.com/fatih/vim-go.

For C with relatives (C++, Java, ...) there seem to be vim-refactor, https://github.com/LucHermitte/vim-refactor.

Even if these work they are no where close to a uniform interface. How do you guys handle such issues, stick with the differences, remap until insane, or something else?

I think it would be great if i could have a uniform interface to use for refactoring regardless of which language i happen to use at the moment. Remembering three different mappings for refactoring and when each one applies steal my focus from what i would like to do.

[Luc Hermitte]

Hi,

> For C with relatives (C++, Java, ...) there seem to be vim-refactor,
> https://github.com/LucHermitte/vim-refactor.
>
> Even if these work they are no where close to a uniform interface.
> How do you guys handle such issues, stick with the differences,
> remap until insane, or something else?

I don't use multiple plugins providing a similar feature. Mainly because I'm implementing most of what I use regarding source code manipulation.

> I think it would be great if i could have a uniform interface to use
> for refactoring regardless of which language i happen to use at the
> moment. Remembering three different mappings for refactoring and
> when each one applies steal my focus from what i would like to do.

I can only speak for vim-refactor that I'm maintaining. Two things, the plugin tries to be as generic (i.e. language independent) as possible, and if your language isn't supported it could be added. However, this is a generic and vim based plugin. Dedicated plugins that rely on external tools will certainly do a better job.
The languages currently supported are the ones I'm working with (C++ and family, vim, and bash essentially)

Also, back to your concern, the mappings can be remapped as they are all `<plug>mappings` (1). However, they all work in two steps: first we extract, then we go manually where the extracted thing should be defined and we paste it there. I don't know how the extract-refactorings from the other plugins are meant to be used.


BTW, I'm becoming confident that the future of vim-refactor, and some other plugins, will be to leave its/their place to plugins compatible with Language Server Protocol.

(1) https://github.com/LucHermitte/vim-refactor/blob/master/plugin/refactor.vim#L127

--
Luc Hermitte

[mrx]

Hi,

Thanks a lot for your input.

Having one plugin for all languages sound great. Is there any documentation on how to add a language to your plugin?

I'd like Python and Go support specifically if at all possible.

Patrik

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/ZNjZiIhnYRM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luc Hermitte]

Hi,

> Having one plugin for all languages sound great. Is there any
> documentation on how to add a language to your plugin?

There is an embryo of documentation on the subject which I see is not up-to date :(

If you open the files in autoload/lh/refactor/{ft}.vim, you should see plenty examples.

An important point, the Extract-Method refactoring relies on ctags, and I need to work on it as I remember there is a pending bug.

> I'd like Python and Go support specifically if at all possible.

I don't know Go. In Python I only have Extract-Variable and a likely bugged Extract-Method -- I can't remember the last time I've using it.

But honestly, I suspect you'll have far better results with the two other plugins dedicated respectively to Python and to Go.

Currently, I'm spending my energy on other but sometimes related topics:
- https://github.com/LucHermitte/lh-style/
- and https://github.com/LucHermitte/lh-vim-lib/blob/master/doc/Project.md integration in buildToolsWrapper.

Regards,
--
Luc Hermitte

[Paul]

On Monday, 06 November, 2017 at 19:23:32 GMT, Patrik Iselind wrote:
>Even if these work they are no where close to a uniform interface. How do you guys handle such issues, stick with the differences, remap until insane, or something else?
>
>I think it would be great if i could have a uniform interface to use for refactoring regardless of which language i happen to use at the moment. Remembering three different mappings for refactoring and when each one applies steal my focus from what i would like to do.

When I was working with both Git (fugitive) and Subversion (svnj), it was very convenient to have my own mappings that would do the right thing depending on context. I had mappings that would call a function that would, depending on whether I was in a Git or Subversion repository, call the appropriate plugin's respective command.

For example, <leader>vb would end up calling either :Gblame (fugitive) or :SVNBlame (svnj), and I didn't need to think about it.