Feature request: specify buffer type per command
See original GitHub issueI have a small feature request that I’d like to take a stab at if it’s a change you’d be willing to merge.
I use the splits mode for buffers in this plugin, which works great for jumping to definitions. However refactoring in this mode on a larger project will often end up creating 4+ splits which is an annoyance to deal with. So I propose these new configuration settings:
jedi#use_tabs_not_buffers_goto
jedi#use_splits_not_buffers_goto
jedi#use_tabs_not_buffers_refactor
jedi#use_splits_not_buffers_refactor
The above settings would override the current g:jedi#use_(tabs/splits)_not_buffers
options if set, but otherwise the current option in place would not be modified.
Thanks for your work on jedi and jedi-vim!
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (4 by maintainers)
Top Results From Across the Web
Feature Request Form
Thank you for using Buffer. We would love to hear your ideas on how we can make our products even better for you!...
Read more >Creating a buffer around a feature—ArcMap | Documentation
Click the feature around which you want to create a buffer. Click the Editor menu and click Buffer. Type the distance in map...
Read more >Buffer Polylines Command - CivilGEO Knowledge Base
The Buffer Polylines command of CivilGEO's software allows the user to create new polygons around the selected polylines using a specified buffer distance....
Read more >Language Guide | Protocol Buffers
The SearchRequest message definition specifies three fields (name/value pairs), one for each piece of data that you want to include in this type...
Read more >TUXEDO System/T Buffer Types
MAXBUFSTYPE in the *RESOURCES section specifies the maximum number of buffer subtypes that can be accommodated in the buffer subtype table in the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think we should probably just not split in case a refactoring happens. IMO that’s the best way forward. People that want splits want one split and not a lot of them.
I guess
let g:jedi#use_splits_not_buffers = 1
should default tosplit
maybe (which would respect thesplitbelow
/splitright
setting then)?