roman/golden-ratio

Automatic resizing of Vim windows to the golden ratio

Golden Ratio

When working with many windows at the same time, each window has a size that is not convenient for editing.

golden-ratio helps on this issue by resizing automatically the windows you are working on to the size specified in the "Golden Ratio". The window that has the main focus will have the perfect size for editing, while the ones that are not being actively edited will be re-sized to a smaller size that doesn't get in the way, but at the same time will be readable enough to know it's content.

You can also disable the automatic resizing and use a mapping to resize on demand.

For more info about the golden ratio check out Golden Ratio on Wikipedia.

Options

Refer to :help golden-ratio for options.

Installation

• With pathogen:

cd ~/.vim/bundle 
git clone git://github.com/roman/golden-ratio.git

• With Vundle:

" .vimrc
Bundle 'roman/golden-ratio'

Credits

This plugin was developed by Roman Gonzalez (romanandreg [at] gmail.com), if you have any suggestions to improve the code/functionality please send a pull request to the github repo:

http://github.com/roman/golden-ratio

Thanks particuarly to ujihisa for the inspiration to develop this plugin.

License

golden-ratio is released under the MIT license. Check LICENSE file.

golden-ratio's Issues

Always opens in right hand window when using FuzzyFinder

The below bug occurs when using golden-ratio in combination with FuzzyFinder.

To reproduce:

• Split the vim window into two panes using :vsplit
• Select the left-hand pane and use :FufFile to open a file.

Expected: The new buffer should open in the left-hand pane.
Actual: The new buffer opens in the right-hand pane.

This bug does not occur when opening files using :e, :b etc. nor does it occur when the golden-ratio plugin is disabled.

E11: Invalid in command-line window; <CR> executes, CTRL-C quits

When using golden-ratio with my setup, I get this error:

Error detected while processing function 51_resize_to_golden_ratio[17]..51_resize_ignored_windows:
line 4:
E11: Invalid in command-line window; executes, CTRL-C quits
E11: Invalid in command-line window; executes, CTRL-C quits
line 7:
E11: Invalid in command-line window; executes, CTRL-C quits

I commented out the corresponding lines (exec window . "wincmd w) and the error disappears, yet it still seems to work. (I only tested with a few splits.)

The loop seems to iterate over all windows, put the cursor in them, execute the command and then move back to the original window. I am not sure why it still works or why this error appears, but I am using the vim version in debian testing:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar 03 2020 16:41:00)
Included patches: 1-2269

Thanks!

No auto-resize when using liuchengxu/vista.vim

vim/gvim 8.1.1486 on Linux.

To reproduce:

1. Have a file with code opened in vim
2. :Vista
   vista's window opens and becomes active, golden-ratio resizes it successfully
3. Go to a function definition, hit Enter
   code file window becomes active, golden-ratio fails to resize it
4. If I do Ctrl w - w twice, to change to vista's window, then back to code file window, golden-ratio resizes the window properly

Focus jumps to last window

When using the vim-fugitive, the :Gstatus followed by the commit command cc, makes the focus jump to the last open split file.

Commenting out this line makes things work fine again:

golden-ratio/plugin/golden_ratio.vim

Line 139 in 934eea9

call s:resize_ignored_windows(l:parallel_windows, l:bw, l:bh)

Sudden resizing of splits when using user commands

I have this user command in my vimrc:

command! -bang W w<bang>

When I use it, all the splits get resized. Even though the resizing of the current split is correct, it's annoying to have the other splits resized...

Option to not set a keybind

The autocommands are awesome (if you will set up some avoidance code for NerdTree, etc) but I already have some other key bound to <Leader>g -- I'd like to avoid golden-ratio overwriting that keybind.

Using golden-ratio will confuse nerdtree about the last activated window

When golden-ratio is activated, nerdtree will not open file in the last activated window.

steps to reproduce

minimum vimrc:

call plug#begin('~/.vim/plugged')
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle'  }
Plug 'roman/golden-ratio'
call plug#end()

$ nvim -u .nvimrc.mini -o file1.txt, file2.txt
:NERDTree
# press enter to open up another file
# according to [nerdtree docs](https://stackoverflow.com/a/3607843/2810981), it should be opened in the upper pane since it's the last activated buffer
# but instead, it's gonna appear in the lower pane

Unknown function: win_gettype

It looks like #40 added a call to win_gettype(), which I believe was added to neovim somewhat recently. Maybe 0.6? I couldn't find it in the release notes, but found reference to it in this commit. Anyway, when running an older neovim version, you will get an error like:

Unknown function: win_gettype

Or possibly:

Invalid expression: win_gettype(winnr()) == 'popup'

The solution is obviously to update neovim. I'm just adding this issue to make it searchable and potentially save others a few minutes of debugging.

There's nothing the maintainer needs to do here, although mentioning a minimum neovim version in the Readme might be helpful.

Install details

Could you put some install details in the readme?

ie. Pathogen support

thanks 👍

Some screenshots would be great to have in the readme.

golden ratio segfaults vim 8.2.150

Actually from 8.2.149 to 8.2.159

see vim/vim#5541

8.2.150 is one of the homebrew vim release.

Error when using golden-ratio in Vim 8.1

I have been using your plugin for the past couple of years (great work by the way 😄) but after I upgraded to Vim 8.1.500 I get this error when starting up Vim.

Error detected while processing function <SNR>18_resize_to_golden_ratio[10]..<SNR>18_golden_ratio_height:
line    1:
E806: using Float as a String
E15: Invalid expression: &lines / 1.618
Error detected while processing function <SNR>18_resize_to_golden_ratio:
line   11:
E806: using Float as a String
E15: Invalid expression: l:ah / 1.618
Error detected while processing function <SNR>18_resize_to_golden_ratio[13]..<SNR>18_golden_ratio_width:
line    1:
E806: using Float as a String
E15: Invalid expression: &columns / 1.618
Error detected while processing function <SNR>18_resize_to_golden_ratio:
line   14:
E806: using Float as a String
E15: Invalid expression: l:aw / 1.618
line   17:
E121: Undefined variable: l:bw
E116: Invalid arguments for function <SNR>18_resize_ignored_windows
line   18:
E121: Undefined variable: l:bw
E116: Invalid arguments for function <SNR>18_resize_main_window
Press ENTER or type command to continue

Erratic horizontal sibling resizing behavior

If the intention is for horizontal siblings of the focused window to all have the same width that behavior appears to be broken for certain frame width / window combinations. Here we have three windows in a frame with a width of 239 (focused window on the right):

Note that the focused window is the right size, but the middle window is abnormally small.

This function and advice appears to fix the behavior by balancing the widths of all the focused window's siblings from the outside in (order matters, otherwise you wind up resizing the focused window as well). I imagine there's a more elegant solution, but this is what worked for me:

(defun zane/window-siblings-at-side-list (side &optional window)
  (let ((window (or window (selected-window))))
    (let ((next (cond ((eq side 'left)
                       (window-left window))
                      ((eq side 'right)
                       (window-right window)))))
      (if (eq next nil)
          nil
        (cons next
              (zane/window-siblings-at-side-list side next))))))

(defun zane/balance-sibling-widths (&optional window)
  "Even widths of all provided windows other than the selected window."
  (let* ((window (or window (selected-window)))
         (siblings (append (reverse (zane/window-siblings-at-side-list 'left window))
                           (reverse (zane/window-siblings-at-side-list 'right window))))
         (total-width (apply '+ (mapcar 'window-width siblings))))
    (dolist (sibling siblings)
      (condition-case nil
          (window-resize sibling
                         (- (/ total-width (length siblings))
                            (window-width sibling))
                         t)
        (error nil)))))

(defadvice golden-ratio
  (after horizontally-balance-after-golden)
  (zane/balance-sibling-widths))

(ad-activate 'golden-ratio)

Here is the desired effect of the above advice on a frame with the same width/number of windows:

Disable golden ratio for NERDtree

Thanks for a great Vim extension! I absolutely love it.

I'm wondering if it's possible to disable golden ratio in NERDtree.

Without golden ratio:

With golden ratio:

cc @roman

Ignore file management (NERDTree etc.) windows

You've got a really nice plugin. I've been looking for something like this for a while.

One thing I've noticed is that it automatically resizes the windows created by NERDTree (Vim Script 1658). Normally you'd have a slim vertical NERDTree window alongside your main file. Ideally you'd ignore sizing the NERDTree window and just size the window you're editing.

Same thing with the bufferlist plugin (Vim script 1325).

I'm not really a vim scripter, but I think what I'm really asking for is for buffers with a non-empty buftype (:help buftype) to be excluded from the automatic resizing. Or maybe with just the buftype set to 'nofile' - I think it may be useful to have help buffers autoresized.

Support :verbose in s:toggle_global_golden_ratio to echo current value

Looking at your script, this variable is only used at startup. Afterwards, only a script variable.

I would like to use g:golden_ratio_autocommand for visual feedback when toggling (echo g:golden_ratio_autocommand), so how about using this one instead?

feature-request: add support for a black list of buffer name patterns

Hi,

I really like this plugin, as it removes the hassling necessity to continuously change window size.

However, in my specific case, I use NERDTree and Tagbar and I want that only Tagbar (since symbols might be quite long) gets resized when it gains focus. I don't want NERDTree window to be affected by this plugin.

Thus I'm asking whether it could be possible a have a blacklist (array) of patterns (e.g. NERD_tree_*)
represeting buffer names. So buffers, whose name matches a item in the blacklist, are ignored by this plugin.

P.s. I've read of

let g:golden_ratio_exclude_nonmodifiable = 1

but I only want one of the nonmodifiable buffers to be excluded.

don't expand when focusing on nerdtree?

Is there a way to avoid expanding when focusing on the nerdtree split ?

quickfix window height should not exceed its number of lines

quickfix window can be resized by golden-ratio just like any other windows, if I didn't let g:golden_ratio_exclude_nonmodifiable = 1.

But resizing a quickfix window that contains 11 lines to fill 2/3 of the whole screen makes no sense, and causes waste of screen spaces. can we add some kind of constraint to quickfix windows so that the height do not exceed their number of lines?

Even splits when jumping the end splits

Golden Ratio splits nicely when moving between panes with Ctrl+W, h/l, but resets widths to even when moving with H/L (Shift)

Not a big deal, as it continues as normal if you move again.

Let me know if you need more clarity.

Generating documentation with pathogen yields errors

When using pathogen, you call 'Helptags' to generate documentation for all the plugins.

This is the output I get when I call 'Helptags' more than once after installing the golden=ratio plugin:

Error detected while processing function pathogen#helptags:                          

line    4:                                                                           

E154: Duplicate tag "'golden_ratio_autocommand'" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                          

E154: Duplicate tag "'loaded-golden-ratio'" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                               

E154: Duplicate tag "golden-ratio" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                        

E154: Duplicate tag "golden-ratio-contents" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                               

E154: Duplicate tag "golden-ratio-credits" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                

E154: Duplicate tag "golden-ratio-intro" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                  

E154: Duplicate tag "golden-ratio-license" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                

E154: Duplicate tag "golden-ratio-mappings" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                               

E154: Duplicate tag "golden-ratio-options" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                

E154: Duplicate tag "golden-ratio-resize" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt                                                                 

E154: Duplicate tag "golden_ratio.txt" in file /home/alg/.vim/bundle/golden-ratio/doc/golden_ratio.txt  

View is moved if switching windows when cursor is far right

Made a gif to be clear:

When the cursor is on the 'z' and the window is toggled back and forth, the view changes. I've gotten around this with autocmd WinEnter * :normal ze, but there's probably a better way.

`set wrap` does not work in inactive window/pane/splits

I have two files open in vertical splits. Each one is set to "wrap" and "linebreak" and it works fine for the split that's in focus, but only for that split. The non-focused split will not wrap lines at all.

When I switch from one split to the other, the newly focused-on split will wrap and linebreak successfully while the formerly in-focus (and now out-of-focus) split will cease wrapping lines.

Can a split that's not actively being worked in (not in focus, or whatever the terminology is) be configured to acknowledge the :set wrap setting?

Great little plugin btw, thanks :)