Neovim: Feature: zoom windows.

[trusktr]

The ability to zoom a window (a toggle) so it fills up the whole space inside a tab would be nice. There could be a command like :zoomtoggle to fulfill the need. This would be similar to what tmux and screen do.

[splinterofchaos]

Does :only do what you want?

[ManIVIctorious]

@splinterofchaos: As i understood this he wants to toggle the behavior, only just closes everything except the wished puffer, so i don't think this does it for him.

I would also prefer such a switch

[splinterofchaos]

It's important to make note of how the expected functionality differs from the norm when adding a feature to any software, so please consider these questions:

Doest :only do at least the :zoom part of your request? :only can be set to hide buffers instead of close, The buffers can then be restored using normal commands.

Another possibility is to open the file you want to "zoom" on in a new tab with :tabnew % and close that when you're done, thus preserving the windows in the current tab.

These questions are relevant because if the feature is already half-written, nvim just needs an analogous to :only like (not seriously) :every, and then :onlytoggle could be added. If :only doesn't even come close, and there's no other command that does, a very different development strategy would be required.

[trusktr]

:only doesn't work. It closes the other windows and therefore the state of those windows (I.e. size, caret position, etc) is lost. To achieve this with a plugin currently, the plugin would need to rely on :set hidden and would also have to keep track of all the window states in the tab to be able to recreate them. It's not the same thing because I want my windows to stay open when I zoom, and I want set nohidden so when I actually close windows the buffers are gone, thus the behavior we need here shouldn't depend on having :set hidden.

I can see :only being convenient when you _do_ want to close all other windows, and a new command like :zoom being convenient for just zooming (all windows are still open and their states intact so when you :zoom back everything is just like it was).

Just zoom for the command name would be nice. It would zoom if unzoomed, and unzoom if zoomed.

[adelarsq]

I think that :zoom is too generic, looking like is the zoom from whole application. Something like :single would be better.

[splinterofchaos]

I'm still curious if the desired functionality would be similar or not to :tabnew % and :q.

[tarruda]

@splinterofchaos good idea, maybe it's possible to emulate tmux zoom feature using :tabnew %/:tabclose(a set of temporary buffer-local mappings could make it exit the "zoom" by simply moving to another window, like tmux does for panes)

The only problem right now is that the % expansion only seems to work with files(no unnamed buffer support)

[splinterofchaos]

The only problem right now is that the % expansion only seems to work with files(no unnamed buffer support)

That seems rather inconsistent, but I can see it's true.

1. make | vim -
2. :tabnew %

E499: Empty file name for '%' or '#', only works with ":p:h"

and yet commands like :%s/make/ekam/g still work like normal. Looks to me like a leaky abstraction.

Back on topic, this works: :tabnew | :b#. (Adapted from http://superuser.com/questions/66179/how-do-i-edit-an-existing-buffer-in-a-new-tab-in-vim)

[trusktr]

When you've :set nohidden, :only won't work if any of the buffers other than the one you 'only' want have unsaved changes. If you do have :set hidden, then :only followed by :unhide (:unhide doesn't work if you have :set nohidden) is the closest thing to the desired functionality, but when you :unhide the windows they won't return to their original configurations (they'll be all horizontal splits). And suppose you have 10 tabs with multiple split windows in each: if you use :tabnew % to zoom one window from each of those ten tabs then you'll create a mess of open tabs. It's just not ideal!

I think a new option would simply be the cleanest solution.

[justinmk]

I think a new option would simply be the cleanest solution.

What do you mean by "cleanest"? New options are a last resort for Neovim, it reduces harmony with Vim compatibility for little benefit. Especially for a feature that can be implemented as plugin (if I understand correctly).

[trusktr]

Besides, I also use autocmd BufEnter * set bufhidden=delete so when the last window of any buffer is closed it's buffer will be deleted from the buffer list. I like the buffer list for seeing which buffers I have open in all of vim, but I don't like having hidden buffers. So in my setup calling :only can't work as a partial solution.

The real solution will not manipulate tab, buffer, or window states, just merely toggle a zoomed view that has no inherent impact on any settings.

[trusktr]

@justinmk ^

Vim reduced harmony with Vi. I can already imagine NeoVim won't be fully comaptible with Vim at some point, based on conversations I've seen in other issues, and will need some option to toggle compatibilty if compatibility is still wanted.

[mar04]

@trusktr
There already is a plugin with that functionality: http://drchip.org/astronaut/vim/index.html#ZOOMWIN
Doesn't it cover your use case?

[khalidchawtany]

@mar04
I think ZoomWin does not work in NeoVim. When I use it, the application (NeoVim) hangs and if press Ctrl-C, I get a buffer filled with all sort of things (settings, mappings, functions etc.). So ZoomWin is not an option anymore. I also see the following error message.

Error detected while processing function ZoomWin#ZoomWin..<SNR>31_SaveWinSettings:
line    5:
E113: Unknown option: key
E15: Invalid expression: &key
E113: Unknown option: key
E15: Invalid expression: &key
E113: Unknown option: sn
E15: Invalid expression: &sn
E113: Unknown option: sn
E15: Invalid expression: &sn
E113: Unknown option: tx
E15: Invalid expression: &tx
E113: Unknown option: tx
E15: Invalid expression: &tx
"/var/folders/d4/444rzqvd29v4fcx77ls292vr0000gn/T/nvimm0wpFx/1" 262L, 6442C

What is funny is that, I don't know how to contact the owner of ZoomWin to ask him if he can fix this bug.

[trusktr]

@mar04 That's the concept. The thing about ZoomWin is that it seems like it destroys windows, then recreates them, instead of just changing the view. It could definitely conflict with various plugins relying on those same windows. Seems like it's work with a bare-bone vimrc, but I forsee trouble with many plugins and settings, it'd be a mess. Native would be the cleanest way to go.

[khalidchawtany]

I tried it with a minimal vimrc, which had only NeoBundle initialization stuff and set nocompatible in it and It failed/hanged with the same error message.

@trusktr have you tried it? Does it work for you (even with the barebone vimrc)?

[trusktr]

@khalidchawtany I just tried it. It's a neat proof-of-concept. I didn't have your error, but I already found another problem: run :ZoomWin, then make a new split. You've now lost all your previous windows because running :ZoomWin zooms in again, and then can only restore that very last configuration. WHat should happen is that splitting a window restores your view, then splits your window, just like in tmux (and screen too?).

[khalidchawtany]

Thanks @trusktr. I have to wait, till somebody comes up with a better solution.

[marlun]

Anyone who has taken a look at ZoomWin and why it's not working in neovim?

[khalidchawtany]

@marlun I have no idea why it was not working for me. However, I gave up trying to make it work. Currently, I use ZoomWinTab which zooms the buffer into a new tab.

[marlun]

@khalidchawtany ZoomWinTab seems to work great when trying it out, thanks!

Edit: ZoomWinTab seems a lot simpler so it wouldn't surprise me if it misses some "features" that ZoomWin has but so far for my use it's working fine.

[tarruda]

ZoomWinTab is a nice replacement for tmux zoom feature

[asgeo1]

The ZoomWin error messages mentioned above can be avoided, by setting a custom list of options for ZoomWin to save when it saves the window state:

if has('nvim')
    " removed 'key', 'oft', 'sn', 'tx' options which do not work with nvim
    let g:zoomwin_localoptlist = ["ai","ar","bh","bin","bl","bomb","bt","cfu","ci","cin","cink","cino","cinw","cms","com","cpt","diff","efm","eol","ep","et","fenc","fex","ff","flp","fo","ft","gp","imi","ims","inde","inex","indk","inf","isk","kmp","lisp","mps","ml","ma","mod","nf","ofu","pi","qe","ro","sw","si","sts","spc","spf","spl","sua","swf","smc","syn","ts","tw","udf","wfh","wfw","wm"]
endif

However, this does not fix the main issue - ZoomWin still hangs for 45 seconds or so when activating it.

I don't know what's causing the hanging unfortunately.

[marlun]

I'm not sure how ZoomWin solves the problem but using a tab seems like the perfect use of tabs since it's there to create alternative "views" in vim?

[trusktr]

ZoomWinTab is nice, but still a hack of sorts. The nicest solution will be
when windows zoom natively inside a tab (without making a new tab and
hiding the tab bar).

But :+1:! I'm using ZoomWinTab for now. :D

On Mon, Apr 6, 2015 at 7:23 PM, Adam George [email protected]
wrote:

The ZoomWin error messages mentioned above can be avoided, by setting a
custom list of options for ZoomWin to save when it saves the window state:

if has('nvim')
" removed 'key', 'oft', 'sn', 'tx' options which do not work with nvim
let g:zoomwin_localoptlist = ["ai","ar","bh","bin","bl","bomb","bt","cfu","ci","cin","cink","cino","cinw","cms","com","cpt","diff","efm","eol","ep","et","fenc","fex","ff","flp","fo","ft","gp","imi","ims","inde","inex","indk","inf","isk","kmp","lisp","mps","ml","ma","mod","nf","ofu","pi","qe","ro","sw","si","sts","spc","spf","spl","sua","swf","smc","syn","ts","tw","udf","wfh","wfw","wm"]
endif

However, this does not fix the main issue - ZoomWin still hangs for 20
seconds or so when activating it.

I don't know what's causing the hanging unfortunately.

—
Reply to this email directly or view it on GitHub
https://github.com/neovim/neovim/issues/997#issuecomment-90319571.

[mattboehm]

I use :tab split when I want to 'zoom' and have not had any problems with this approach so far.

[justinmk]

@mattboehm Nice tip

[tarruda]

Zooming in/out would be the same as switching the current frame_T structure, which is already what happens when switching to another tab, so there's no point in having another command just for this.

[trusktr]

@tarruda I disagree from a user experience perspective. Opening a new tab isn't conceptually the same as zooming a window inside of a tab and keeping all window layouts untouched when zooming back out.

In all current vimscript implementations I've tried, it's possible to do something or other to end up with a window layout that wasn't the same as you would expect when zooming back out. They are hacks, not solutions.

[justinmk]

@trusktr :tab split _does_ preserve the window layout. Simply close the new tab, and return to the previous tab, and the layout was not modified.

[hoschi]

When you treat your tabs as a containers for a bunch of buffers which belongs to a task, you get a new anonymous task with :tab split. ZoomWin for example gives you more screen spacen without modifying your currated tab list. Unfortunately it breaks in several circumstances, and imo this issue was to come up with an idea to get the same benefits of ZoomWin without the negatives.

[marlun]

I only used ZoomWin to temporarily get more viewing space and for that the :tab split solution works great and it works wherever you go since there's no need to install a plugin. As I understand it tabs are actually in vim to do this (not only this but this included). I much prefer learning to use something which is in n/vim by default instead of depending on a plugin.

I do however understand that it's weird if you're coming from other editors where opening a new file always means opening a new tab.

[justinmk]

ZoomWin for example gives you more screen spacen without modifying your currated tab list. Unfortunately it breaks in several circumstances, and imo this issue was to come up with an idea to get the same benefits of ZoomWin without the negatives

@hoschi What negatives? The tab is temporary. Once you close the tab your tab list is restored.

[hoschi]

@marlun @justinmk Tabs are the only way to group buffers together in vim, hence I wouldn't want to use them for a cheap "solution" for zooming a window. I actually use :tab split all day, since ZoomWin has its problems and there is no other way at the moment, but it would be great if there is a solution for this which only works with windows.

[justinmk]

@hoschi I use tabs to group buffers/windows as well. But I still do not understand your dissonance. :tab split is an elegant solution IMO.

[trusktr]

A UX designer might not agree. :D Opening a new tab isn't the same as zooming, otherwise it wouldn't be called opening a new tab. x) Tmux has the "zoom" feature down.

[hoschi]

@justinmk the negative is the additional tab itself. When you have 7 tabs and each of it has 3 windows, you get 14 tabs when you "zoom" one window of each original tab. This leads to additional negative points:

• tab list is very long and get cut because the neovim window is too small
• your tabline shows the active tab, so you don't know which tab holds your zoomed buffer and which tab holds the original 3 windows, this breaks [count]gt movements
• you can't cycle through tabs/groups any more, because you have now groups and "one thing of a group which seems to be a group with just one item"

As I said, I use :tab split every day, but only because it is the best _current_ solution .. not (imo) the best solution.

[trusktr]

@hoschi has it. We want to be able to zoom inside of as many tabs as we want, without duplicating the number of tabs. That'd be a nice actual "zoom" feature. :D

[trusktr]

:tab split breaks spacial organization.

[trusktr]

I can see that :tab split works for people who memory map their buffers or don't care so much about where buffer are actually located, but other people like to have a visual representation of their workspace.

UX

[ghost]

I think I understand, as I use tmux's zoom feature frequently and it's indeed very useful IMO

[marlun]

@hoschi if you have 7 different views for the same project I do understand that it gets hard to work with. Isn't that kind of an extreme though? Out of curiosity, how come you have that many? However, I'm not against a feature like tmux zoom.

Is it that you're working on 7 different task in the same project at the same time?

[justinmk]

I can't imagine why one would zoom more than _one_ window at the same time, or longer than briefly--but at least now there are _details_ which describe the shortcomings of :tab split. That's what was missing before.

[marlun]

How does sessions fit in to this problem? Could one not use sessions for the different tasks?

[trusktr]

The problem is that vim sessions aren't really... sessions. They are just scripts that open a bunch of windows, tabs, and set options.

[asgeo1]

I'm with @hoschi and @trusktr - this is exactly how I work too:

I have multiple tabpages open at once. Each tabpage has multiple split windows. Sometimes the same buffer may be visible across multiple tabpages.

So each tabpage is effectively a "view" - a group of windows and buffers which I am currently working on, in a particular arrangement which makes sense for the task I'm working on.

I am constantly cycling between my tabpages (views) as I'm working. I don't like to disrupt my tabpage window arrangements, other than to zoom in or out on a particular window if needed.

As others have said, :tab split sucks because it creates a new tabpage - this stuffs me up when I'm trying to cycle between my tabpages. It breaks the mental model of my project that I had carefully arranged into tabpages and windows, because now there is an extra tabpage in the list which makes it very difficult to adjust how I had ordered my tabpages in my head.

Further, when you close the new tabpage created from :tab split, you may not actually end back on the tabpage you started on, which is even more frustrating.

I would _love_ a native zoom feature in Vim! Please make this happen :)

[hoschi]

@marlun

• one tab for terminals, one terminal buffer for advanced git commands and others for long running programms e.g. gulp server or something
• one tab for project wide setting files, e.g. Grunt, .jshintrc, .git/config/exclude, ...
• one tab for a module, which has windows to show files which are used in this module and one window for the testfile

As it is really unusual that fixing a ticket includes only one module, I go usually have 4 to 8 tabs opened. This is not only the case for one projects, I work at 4 different projects recently and I use this workflow for all of it.

@justinmk The use case for zooming more than one window is for focusing of a part of a module tab. E.g. zoom at test file in module tab 1 because one test fails, zoom into source file of module tab 2 to see how to mock it correctly and eliminate side effects.

[marlun]

It makes sense and I can see how a more tmux like zoom feature could be really helpful for some people. Especially when neovim added the :terminal feature and people will start using it like tmux.

[hoschi]

Especially when neovim added the :terminal feature and people will start using it like tmux

Thats also right, I actually evaluate if neovim terminals could replace tmux and the missing zoom feature is one problem here.

[marlun]

I'm still where I feel neovim replacing tmux is a bad thing but a lot of people are loving it.

[tarruda]

@justinmk the negative is the additional tab itself. When you have 7 tabs and each of it has 3 windows, you get 14 tabs when you "zoom" one window of each original tab. This leads to additional negative points:

Zooming more than one tab isn't really useful since you can only see one tab at a time, and even if you need that for your workflow, such thing would be achievable as a plugin. But it is not our goal to support every possible workflow as native commands/features, which is why vimscript exists.

Opening a new tab isn't conceptually the same as zooming a window inside of a tab and keeping all window layouts untouched when zooming back out

It might not be conceptually the same, but it is the same from an implementation POV. Even if we were to add a command dedicated for zooming, it would simple invoke something like tab split under the hoods. I'd consider adding a plugin that manages zooming more efficiently than using tab split/tabclose directly, but won't implement a new zooming feature in C when vimscript can deal with it just fine.

[trusktr]

But it is not our goal to support every possible workflow as native commands/features, which is why vimscript exists.

But every attempt in vimscript has always been a hack. There's always some downside to the plugin, whereas a simple native zoom similar to tmux wouldn't have any such downsides.

it would simple invoke something like tab split under the hoods.

I think you're not imagining exactly what we are. We want to be able to have the views of tab of any number of tabs to be able to contain a zoomed window, while not affecting tab layout. :tab split doesn't follow this rule.

Every current plugin that "zooms a window" inside of a tab has to actually _close_ all the windows in the tab except for one, then (hopefully) restore all those windows when "zooming back out". That is by far a hack, it won't work with sessions (saving a session while a window is zoomed), and will certainly cause frustration when original windows aren't restored due to some user action that destroyed the plugin's state (f.e. splitting a "zoomed" window). It's definitely not a simple :tab split under the hood.

[justinmk]

But every attempt in vimscript has always been a hack.

Let's focus on making the API powerful and stable, so that plugins can implement these ideas.

[trusktr]

:+1:

[hoschi]

I'm a bit confused now.

from @tarruda

I'd consider adding a plugin that manages zooming more efficiently than using tab split/tabclose directly, but won't implement a new zooming feature in C when vimscript can deal with it just fine.

from @justinmk

Let's focus on making the API powerful and stable, so that plugins can implement these ideas.

So here is my question: Is it already possible to do a tmux like zoom feature (without creating new tab) with the current API (by e.g. vimscript)?

[justinmk]

Is it already possible to do a tmux like zoom feature (without creating new tab) with the current API (by e.g. vimscript)?

No. Let's focus on making the API powerful and stable, so that plugins can implement these ideas.

[hoschi]

Thanks for clarification.

[davidsteinberger]

@justinmk What's the timeline of this? Neovim is awesome, though I really like ZoomWin.

In the meantime I'm using a simple resize: http://stackoverflow.com/questions/13194428/is-better-way-to-zoom-windows-in-vim-than-zoomwin. Has somebody found a better solution?

" Zoom / Restore window.
function! s:ZoomToggle() abort
  if exists('t:zoomed') && t:zoomed
    execute t:zoom_winrestcmd
    let t:zoomed = 0
  else
    let t:zoom_winrestcmd = winrestcmd()
    resize
    vertical resize
    let t:zoomed = 1
  endif
endfunction
command! ZoomToggle call s:ZoomToggle()
nnoremap <silent> <C-A> :ZoomToggle<CR>

[justinmk]

@davidsteinberger Stabilizing the API with its current (minimal) feature set will hopefully be done this calendar year. Adding new features that would make zooming a window in the core, easy to do via the API, could happen next year.

[mattboehm]

Just out of curiosity, what would people expect :split to do when zoomed in? Or :q? If you can't split the zoom, you're missing out on a lot of capability. If you can, then people may expect to zoom again at some point. There are multiple answers to these questions, and I think each one might violate some peoples'/plugins' expectations. I agree with @justinmk that the exact behavior of zooming should therefore fall into the plugin territory.

Here's my current take on the issue:

While many people see tabs as a way to contain different arrangements of windows, they can hold a lot of other state too (file lists via ctrl-space and the behavior of various other plugins with tab-specific settings like accordion.) Some people want to separate the concept of views and tabs so that they can switch between multiple views within the same tab.

I think the ideal solution would be something like :mkview, but capable of dumping window layout/position into a vim variable. Plugins (or included commands) could then then provide a way to manage this list of views and switch between them (perhaps storing a stack of views in a t: variable).

No matter what happens, I'd probably continue to use :tab sp as I find it much simpler and less restrictive, but I understand why others would want alternative behavior. As someone else mentioned, splitting inserts a tab after the current tab and closing also goes to the next tab, which is a bit annoying. To circumvent this, you can split the current window into a new tab before the current one with :tab split | execute 'tabmove '. (tabpagenr() - 2)

[trusktr]

@mattboehm

what would people expect :split to do when zoomed in? Or :q?

The same thing that happens in tmux: when splitting, the view unzooms, showing the new split just as if you had done it without having been zoomed to begin with. Same with quitting, the view zooms out and the window closes just as if you weren't zoomed to begin with.

[davidsteinberger]

_ZoomWinTab_ is indeed a good solution. I'm still curious what makes _ZoomWin_ so slow in NeoVim. Does anyone know?

[willhoag]

_ZoomWinTab_ doesn't seem to work on unnamed buffers unfortunately. I'll be sticking with :tab split and :tab close for now. And I guess neither does _ZoomWin_...

[steadystatic]

Just a heads up Janus ships ZoomWin.vim by default (I'm slowly migrating away from it and cleaning up my vimrc), so you'll get that error with it and a slight hang in Neovim (though it does work despite the error). What I did was this in .vimrc.before call janus#disable_plugin('zoomwin') and update any of my mappings like so map <leader>z :ZoomWinTabToggle<CR>