question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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)?

Issue Analytics

  • State:open
  • Created 8 years ago
  • Comments:13 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
blueyedcommented, Apr 5, 2019

@lkhphuc Maybe give it a try yourself? 😃

0reactions
lkhphuccommented, Apr 5, 2019

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

How should the option 'switchbuf' work?
I have then used set switchbuf=useopen,usetab and the following commands in a new vim instance: Open a first buffer :e file1; Split the...
Read more >
[vim/vim] Misleading documentation for 'switchbuf' (#8215)
Otherwise: do not split, use current window (when used in the quickfix window: the previously used window or split if there is no...
Read more >
Vim documentation: quickfix - SourceForge
The 'switchbuf' settings are respected when jumping to a buffer. *:ll* :ll[!] [nr] Same as ":cc", except the location list for the current...
Read more >
Options - Neovim docs
See option-backslash for using white space and backslashes in {value} . ... Like ":set" but set only the value local to the current...
Read more >
jedi-vim - Bountysource
... when "goto" goes to another/existing window (in another tab), via _newtab . I think that jedi-vim should use Vim's switchbuf setting in...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found