Support buffers outside of Vim's CWD

[okcompute]

This is a simplification of PR #2 and add support for buffers outside of Vim's CWD when autochdir is not enabled. This PR resolves the last issue reported in #3 that was still present even after @wincent committed 5016306.

Thank you @wincent!

[wincent]

Thanks @okcompute. I added a minor commit on top adjusting whitespace.

Bear with me, but we should think about this a bit more before merging it.

There are two competing models at play here, which at the very least suggests that we might want to control this behavior with an option, or employ some heuristic about when it should apply. The two models are:

1. You expect operations to apply based on the file you're currently editing (many such people have 'autochdir' set, but not all, because — among other reasons — 'autochdir' can cause plug-ins to behave oddly as you've previously stated).
2. You expect operations to apply based on the directory Vim is running inside (I doubt anybody who does this has 'autochdir' set).

Unfortunately, to complicate matters further, people might have a third "mixed" mode in mind such that they typically expect operations to apply to based on the current directory (model 2) but they also want to be able to edit files outside that directory from time to time and have the other model apply for those files (model 1). Unfortunately, I don't think there's any way to distinguish the intent of such people from another group that may prefer for that not to happen (eg. they might be working in "directory A" and open a file from "directory B" elsewhere, but they still want :VcsJump grep foo to search in "directory A").

So:

• I don't think we can choose to operate in model 1 or 2 based on whether 'autochdir' is set, because some people who want model 1 may not actually have it set.
• We could add an option to let people chose the behavior (eg. g:VcsJumpAutodir or something).
• We could try to be "smart" and:
  • Keep the current behavior if 'autochdir' is set (because it will work as expected anyway).
  • Otherwise, assume "model 2" if the file you're editing is inside the current working directory; or:
  • Assume "model 1" if the file is outside it.

Just thinking out loud there, so not sure if that makes sense. If we could make the "smart" thing work transparently and without quirks that would be my preference because then things would just work, but I fear we can't do that because of what I said above ("I don't think there's any way to distinguish the intent of such people from another group that may prefer for that not to happen")... So maybe a config option is the only way to be really sure about it, or even a variant command (eg. :VcsJump!) that could be used to temporarily force the other behavior.

[okcompute]

I understand your concern. As you can guess, I'm definitely in the model 1 camp. And I've seen a lot of people being on the model 2 camp (I sense you are in that camp otherwise your plugin would had match my model 1 expectation 😉 ).

I'm ok to make this optional. But first, a couple of points to help our discussion!

1. Vcs-Jump is a project oriented plugin. It gives an overview of the changes in the project your working on. The question is, what is a project? My understanding is the concept of a project doesn't exist in Vim. This is a concept introduced by plugins. I'm pretty sure Vim is buffer-centric and not project-centric. Hence, by default, Vim is closer to model 1 than model 2 .

2. I've look around to see how other project oriented plugin authors handle this. One popular plugin that could help us orient our design decision is vim-fugitive by the prolific Mr. @tpope. If I do :Git log on a specific buffer for example. It will return the commit log for the repository where the buffer associated file is located on disk. So, this plugin author has decided model 1 should be the default. Here is an excerpt from the documentation: These commands are local to the buffers in which they work (generally, buffers that are part of Git repositories). I've searched and could not find an option to change this default behaviour. It doesn't mean we have to copy Mr. @tpope plugin behaviour. But, he did set some expectation for me :P

3. IMHO, if we set on using model 2 by default for VCS-jump, it feels broken. I mean, I was really confused because nothing was happening when calling VCS-jump on a buffer outside of the pwd (either with autochdir enabled before your change or now with the new behaviour and autochdir disabled). The plugin would act as if there were no changes at all even though the current buffer had definitely changes in it! If we decide to support this model (either default or optional), I suggest we show a clear error message to let users know this buffer is not part of the current project tracked by Vcs-Jump.

All that said, I really don't mind to make model 1 optional. Just let me know and I'll update the PR this weekend!

Thank you!

[wincent]

Impossible to keep everybody happy all the time, so I think the best way forward is going to be an option. I suggest we actually do both of these:

• Add a setting to choose which mode you want; call it g:VcsJumpMode, with possible values "cwd" and "buffer", and default "cwd" (ie. default to existing behavior).
• Make :VcsJump! temporarily switch to the other mode for a single invocation; ie:
  • With g:VcsJumpMode set to "cwd", :VcsJump would operate relative to the current directory and :VcsJump! would operate relative to the current buffer.
  • With g:VcsJumpMode set to "buffer", :VcsJump would operate relative to the current buffer and :VcsJump! would operate relative to the current directory.

My understanding is the concept of a project doesn't exist in Vim. This is a concept introduced by plugins. I'm pretty sure Vim is buffer-centric and not project-centric.

Funnily, enough, I draw the opposite conclusion based on 'autochdir' not being the default. 😂

[wincent]

So I pushed a commit implementing the above proposal.

[okcompute]

Thank you @wincent. This is perfect :)