goto: use current window; respect / use 'switchbuf' setting in general

[blueyed]

I find it irritating, when "goto" goes to another/existing window (in another tab), via _newtab.

I think that jedi-vim should use Vim's switchbuf setting in general:

'switchbuf' 'swb'   string  (default "") global {not in Vi}

  This option controls the behavior when switching between buffers.
  Possible values (comma separated list):

     useopen    If included, jump to the first open window that
      contains the specified buffer (if there is one).
      Otherwise: Do not examine other windows.
      This setting is checked with |quickfix| commands, when
      jumping to errors (":cc", ":cn", "cp", etc.).  It is
      also used in all buffer related split commands, for
      example ":sbuffer", ":sbnext", or ":sbrewind".

     usetab Like "useopen", but also consider windows in other tab
      pages.

     split  If included, split the current window before loading
      a buffer for a |quickfix| command that display errors.
      Otherwise: do not split, use current window.

     newtab Like "split", but open a new tab page.  Overrules
      "split" when both are present.

Using switchbuf could eliminate some of the settings (g:jedi#use_tabs_not_buffers and g:jedi#use_splits_not_buffers), or rather could derive their defaults from it (g:jedi#use_splits_not_buffers allows for providing left, right etc.)

I find jedi#use_tabs_not_buffers (enabled by default) an odd setting by itself: e.g. for the quickfix list for the usages, there should be no extra handling, just use the standard quickfix mechanisms (which uses switchbuf).

Apart from that, goto should just use the window where it was called from, at least by default.

Some concrete questions:

• should "rename" open new buffers? Probably yes, because these files have been changed.
• :Pyimport should behave like "goto", i.e. not open a new buffer by default (according to switchbuf)?

[davidhalter]

should "rename" open new buffers? Probably yes, because these files have been changed.

Yes, I want to be able to undo the changes.

I find jedi#use_tabs_not_buffers (enabled by default) an odd setting by itself: e.g. for the quickfix list for the usages, there should be no extra handling, just use the standard quickfix mechanisms (which uses switchbuf).

I'm not even sure where all of that stuff comes from. Most things have not been added by me, but by people that wanted a certain behavior. I therefore don't know how I feel about changing all of that.

jedi#use_tabs_not_buffers was added by me. I really hate how VIM treats tabs and love tabs in general, because they are just a very good way to organize "buffers". Some of the decisions about how I implemented it might seem very strange today, because I had absolutely no idea how buffers in VIM worked.

:Pyimport should behave like "goto", i.e. not open a new buffer by default (according to switchbuf)?

Don't understand that question. Sorry :)

---

I'm now trying to play with switchbuf, however I haven't really been able to make use of it properly. I set :jedi#use_tabs_not_buffers = 0 | set switchbuf=newtab (and also usetab), but it didn't affect anything.

[blueyed]

I'm not even sure where all of that stuff comes from. Most things have not been added by me, but by people that wanted a certain behavior. I therefore don't know how I feel about changing all of that.

I see. I will try to not change it dramatically, but e.g. nobody really wants a new window or tab when going to a definition. You can easily go back with <C-o>.

btw: tabs are meant to organize windows, not buffers.. :)

But I can see where you're coming from.
You can always do stuff in a new tab quite easily, e.g. tabnew | Pyimport os.
I have mapped nnoremap <C-space> :tab sp | set nodiff<CR> btw, and use it a lot. This allows to open the current window in a new tab, where I can then run :Gdiff on it etc.
(<A-space> for a blank tab)

:Pyimport

:Pyimport os would open the file in the current window - not open a new one (or tab).

switchbuf ... but it didn't affect anything

It's not used / respected yet.
It should make a difference in the quickfix window for "usages", if you have jedi#use_tabs_not_buffers=0.

[davidhalter]

I see. I will try to not change it dramatically, but e.g. nobody really wants a new window or tab when going to a definition. You can easily go back with .

I don't want that (for my VIM) :-) I agree with you that we should probably make the buffer option jedi#use_tabs_not_buffers=0 the default. However, I still like "my" tab option and I would continue to maintain it. So I guess it wouldn't be a problem to keep that an option? For buffers, I would just let you do your work. Since I'm not a heavy buffer user I trust that you have a better plan of simplifying it. Let me just know what options you're trying to get rid of.

btw: tabs are meant to organize windows, not buffers.. :)

I know that that's VIM's idea. But I feel different about this. I like tabs :-)

I personally never want any buffers open if they are not tabs. I always close open buffers (that are not tabs) with :bd because of that.

---

I have played around with switchbuf. It does not do what I want. I basically would like a mixed behavior of switchbuf=usetab and switchbuf=newtab that resembles the way how most modern IDE's tabs work. Either a new tab is opened (even if a tab exists) or a new buffer is opened if no tab exists. I dislike both of them. I think that it's not what anyone wants (especially newtab).

[blueyed]

I agree with you that we should probably make the buffer option jedi#use_tabs_not_buffers=0 the default.

Done in #430.

[blueyed]

I still don't get why you would want that "goto" opens a new tab or (and that's more irritating) jumps to some existing tab (where multiple windows might be opened).

The PR #409 changes this to use edit_buffer instead of new_buffer.
I think that for jedi#use_tabs_not_buffers=1 it needs to be adjusted.

I think we should get #430 merged, and then see how #409 fits your/this workflow.

[davidhalter]

I still don't get why you would want that "goto" opens a new tab or (and that's more irritating) jumps to some existing tab (where multiple windows might be opened).

Because it's how every major IDE works. And of course because I like it :)

[davidhalter]

use_tabs_not_buffers = 0 is now the default. But as I said, the tab setting is something that I really like. I don't like VIM tabs and I'm trying to work around them. So that will hopefully stay as is. However, I'm happy to discuss changes to the buffer logic.

Therefore I would not like to use switchbuf (for the tab logic), because it doesn't do what I really want. I want standard IDE behavior (which VIM doesn't offer). Is that ok? Does #409 still have any impact if that change falls away?

[ches]

👍 for respecting switchbuf whenever it intuitively applies, IMO it's just what a Vim user should expect since it's built-in for reasons very much like this. Many plugins apply switchbuf this way so it's frustrating when one does not (if you can't tell, I'm in the @blueyed camp with how I use Vim tabs and jump list or tag stack navigation like <C-o> 😄).

It still seems that switchbuf alone won't achieve @davidhalter's desired tab workflow, but really I think user-customized mappings are the solution for that, instead of a bunch of plugin options that merely duplicate what mappings can already do:

nmap <buffer> <silent> <Leader>d :tab split<CR> :call jedi#goto()<CR>

Create a new split or tab and Vim keeps the cursor where it was in the previous window, so you can immediately call goto there afterward. You can get whichever behavior you want, and even have multiple mappings for different behaviors if you wish.

(I would really like to rework how this plugin handles mapping configuration too, but that's a bit off-topic here…).

[ches]

I have played around with switchbuf. It does not do what I want. I basically would like a mixed behavior of switchbuf=usetab and switchbuf=newtab that resembles the way how most modern IDE's tabs work. Either a new tab is opened (even if a tab exists) or a new buffer is opened if no tab exists. I dislike both of them. I think that it's not what anyone wants (especially newtab).

@davidhalter Note that switchbuf actually takes a comma-separated list of the options, so I think that set switchbuf=usetab,newtab might achieve what you want.

There may still be a lot of cases where Vim will open "duplicate" tabs though, well beyond the scope of jedi-vim—as you concede, one-to-one tab-to-buffer mapping just isn't Vim's natural model 😄

I wouldn't want your own plugin to start to feel alien for your workflow, but it does seem like some redundant config options and special-case code could be eliminated if native features in the right combinations can meet everyone's wishes.

[davidhalter]

(I would really like to rework how this plugin handles mapping configuration too, but that's a bit off-topic here…).

You're welcome to mention them! (in a different thread). :)

@davidhalter Note that switchbuf actually takes a comma-separated list of the options, so I think that set switchbuf=usetab,newtab might achieve what you want.

This actually sounds interesting and I haven't tried that yet. I tried using #409 with :jedi#use_tabs_not_buffers = 0 | set switchbuf=newtab,usetab, but it didn't have any effect (on goto_definitions). cc @blueyed.

[ches]

You're welcome to mention them! (in a different thread). :)

Sure, once I find some time for it it'd be good if that thread came with a pull request I think :-)

[lkhphuc]

Hi all, just a gentle reminder on this one.
If anyone find some free time, I would really appreciate to see #409 done.

[blueyed]

@lkhphuc
Maybe give it a try yourself? :)