Transfer of project ownership

[wsdjeg]

Hi, I am Wang Shidong. and I have use Vim for many years. I am also the author of SpaceVim. I just find this project via twitter. It is a useful plugin and I want to usd this project in SpaceVim. That means I will continue the work of this project.

Thanks for all your work of this project. :)

[kopischke]

Hello @wsdjeg, I am very happy to hear that; SpaceVim is quite an impressive project, I would be glad to see vim-fetch in such good hands. I am a bit busy ATM, but I aim to compile a set of cliff notes about the state of the plug-in this week, both about the how and why of its operation mode (beyond what is in the comments already, as these do not document all the false starts and inoperative variants I tried over time ;)) and the possibilities for, as well as caveats to, future enhancements. Needless to say, I would be available for you to pick my brains anytime after the transfer, of course.

[wsdjeg]

If you have any ideas or todo list about this project, you can also list them here. I will try to implement them. :)

[kopischke]

The gist of that is in the Future Plans milestone – I’ll expand on that in my notes.

[kopischke]

Hello @wsdjeg, and apologies for having taken so long, real life has been interfering quite a lot lately. In case your are still interested in taking over maintainership of vim-fetch, here are the cliff notes.

Windows support needs some love

• handling of backslashed / non-backslashed Windows paths is untested and probably unreliable. There is an open PR with a fix for one scenario that may need to be expanded to others (see my last comment on the issue thread): #21
• the gF command does not handle Windows paths suffixed with a spec using a colon (:num) because of the absurd way Vim handles &isf, which makes the inclusion of the colon under Windows to support X: paths treat a colon anywhere as a part of that path. I have an abortive branch trying to handle arbitrary &isf character overlaps with jump specs, but I would not recommend going down that rabbit hole (amongst other things, it depends on the +visual feature and it bloats the plugin’s code beyond salvation). I’ve been at a loss how to handle this best without replacing the whole gF functionality by a home rolled implementation, something I have always been loath to do: #9

OTOH, adding a home rolled gF version could allow for extending the functionality of vim-fetch to C-w f, which it currently does not do: #16

Spec formats could be expanded, new ones added

• expanding the handling of pytest specs to arbitrary node ids: #15
• irb style specs (/path/to/file:<line>:in <method / module>) could be added: no issue, that was sitting in my private project Trello.

Opening up functionality for extension / external usage

This has been requested and discussed several times, and might need some refactoring, but:

• with the last release, there is no technical reason to stop people add their own specs, as there is no coupling to autocommand event patterns anymore. Stopping people from shooting themselves in the foot by creating an endless reload loop, for instance, would still be an issue (there is no contract guaranteeing we only operate on spurious files, as BufNewFile is not the only event processed, and cannot be if the plugin ist to be reliable).
• the ability to use vim-fetch’s ability to resolve specs without actually operating on a buffer or file path in a buffer (i.e. a resolving API) has also been requested before: #6, #13

Oh and adding a testing framework would be useful to avoid missing the kind of regressions I completely failed to notice when Vim’s internals changed…

That is about it; please let me know if you are still willing to take over, and if so, when you are ready to do so so I can transfer the repo to you, tooth and nails 😉

[kopischke]

… as to the how and why the plug-in operates as it does, I could write a treatise, but the gist of it is in the comments to the autocommands in plugin/fetch.vim:

• manipulating buffers in autocommands during the Vim startup sequence does not work reliably, or mostly even not at all. This would not be an issue if the plugin only had to handle file specs passed in Vim commands, but as launching Vim with a spec is one of the most common scenarios, we need to dance around this. Older versions of fetch leveraged the fact BufWinEnter did not suffer from the startup issues, but as of Vim 8, this is not true anymore, so version 3 uses a delayed execution pattern while Vim starts up, then switches to direct execution once startup is finished. This allows it to rely almost exclusively on BufNewFile, which would be perfect
• except for the fact that launching a spec into a tab (-p switch, default in some GUI implementations of Vim) will create a buffer not reachable for the fetch#buffer() function (because it it has to switch between windows, something that can only be done on the current tab, and I didn’t want to cycle through all tabs for performance reasons), hence the need for the extra TabEnter logic.

As to the warts of the :xdo alternative approach used by file_line, the README says it all. That approach just opens a large cans of strange and interesting worms, as Vim takes very unkindly to buffers being switched out in such a sequence.

[wsdjeg]

of cause I would like to finish these features, I like the idea of this plugin. I could spend 5-10 hours a week for implementing feature and solving issue for this plugin.

• the test framework: I will use vader, travis for linux and Mac, appveyor for windows

[kopischke]

That sounds very good, @wsdjeg; I am glad to see fetch go to such good hands. ~I have initiated the transfer; if I read Github’s help on this correctly, you should be asked to approve the transfer, which you will need to do in 24 hours for it to complete.~

EDIT: Turns out I can’t transfer the repository because you have forked it; you will need to delete your fork before I can proceed, it seems. Sorry about that.

[wsdjeg]

OK I will delete the forked repo

[kopischke]

@wsdjeg transfer has been initiated.

[kopischke]

@wsdjeg looks like transferring left me with commit privileges, which I have availed myself of to update the README, the LICENSE and the plug-in documentation to acknowledge the transfer. Things that still need to be figured out:

• [x] I cannot transfer the Vim.org scripts page, but I could link to a new one on mine. Or one could drop the whole thing of course, that is up to you.
• [ ] The Code of Conduct needs a contact email address; I’ve left mine in for the time being.

[wsdjeg]

@kopischke I do not has vim.org account, and Maybe use the old link is enough. should I create a new account? I think the plugin in vim.org needs to be updated when we release new version.

[kopischke]

Maybe use the old link is enough.

Actually, I’m wondering how much mileage the plug-in gets out of Vim.org; do people really still use the scripts list that much in 2018? Maybe updating the old script page to say “anything from here on is Github only” would be enough?

the plugin in vim.org needs to be updated when we release new version.

Right, let’s defer that decision until you cut a new release.

[kopischke]

I have added an explanatory paragraph to the Vim.org listing

NOTE: Maintainership for vim-fetch has been talken over by Wang Shidong. Links on this page have been corrected or will redirect to the new GitHub repository. Please do refer to the above mentioned repository for future developments.

and corrected the links visible there (GitHub thankfully takes care of redirecting all links I cannot amend), which should hopefully be enough. All that is still needed is an email address for the CoC, and we can consider transfer complete and close this issue.

[wsdjeg]

Ok, I will update the email address in CoC.