Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ Bug ] cmdheight after restore is incorrect #64

Closed
Chaitanyabsprip opened this issue Sep 2, 2021 · 24 comments
Closed

[ Bug ] cmdheight after restore is incorrect #64

Chaitanyabsprip opened this issue Sep 2, 2021 · 24 comments

Comments

@Chaitanyabsprip
Copy link
Contributor

Screenshot 2021-09-02 at 18 34 46

If neovim is closed with nvim-tree open, this is caused.

@jameshiew
Copy link

On Linux, working around this currently by putting 'silent !kill -s SIGWINCH $PPID' in post_restore_cmds during plugin setup, so Neovim gets resized after a session is restored.

See neovim/neovim#11330

@Chaitanyabsprip
Copy link
Contributor Author

I am using MacOS Big Sur 11.5.2

@rmagatti
Copy link
Owner

rmagatti commented Sep 5, 2021

This happens to me too (though not all the time). I just quickly resize the terminal and get the correct sizes back. I don't think it's something this plugin can solve though.

A better idea is what @jameshiew mentions so the resizing happens automatically instead of doing it manually.

@kunzaatko
Copy link

kunzaatko commented Mar 17, 2022

This happens to me too (though not all the time). I just quickly resize the terminal and get the correct sizes back. I don't think it's something this plugin can solve though.

A better idea is what @jameshiew mentions so the resizing happens automatically instead of doing it manually.

I think I figured out what is causing this issue. This is either a popupwindow or a notification from the nvim-notify plugin. When the session is saved when a popup or the notify buffer is open (a notification is visible) it saves it too. I currently do not have any idea how to solve this but I guess this issue should be reopened @rmagatti. It could possibly be solved by calling automatic :bd on the buffers of the notifications in the pre_save_callback function but I don't currently know, how to distinguish them from the other buffers (I don't know how to get the buffertypes, but that could probably be a distinguishing feature)... Any idea?

@rmagatti
Copy link
Owner

I actually feel pretty strongly about adding specific code to work around what/how other plugins do things. As in I don't think it's the right call to do so. The hooks exist for this very reason, so people can customize things before and after session loading happens, auto-session can't conceivably cover every possible edge case for every possible plugin.

As for how one would do this through the hooks, by quickly looking at nvim-notify code, I can't really see a specific thing that can be used to identify a notification buffer, at least from a quick skim. The author of that plugin might be able to tell you more about it.

@kunzaatko
Copy link

kunzaatko commented Mar 18, 2022

I actually fully back you in this. I agree that it wouldn't be hygienic to specify exceptions for other plugins.
To clarify, I am suggesting to reopen the issue, until we find a solution using hooks and then documenting the solution in the wiki or the docs under Troubleshooting. I also browsed the code of nvim-notify and I didn't land on any straightforward solution.
How do you feel about this?

@rmagatti
Copy link
Owner

I'm okay with that suggestion. Reopening 👍

@rmagatti rmagatti reopened this Mar 18, 2022
@ok-nick
Copy link

ok-nick commented Apr 19, 2022

I had this issue with neovim 0.6.0, but after upgrading to 0.7.0 the issue was fixed.

EDIT: nvm I just got lucky

@rockyzhang24
Copy link

This issue exists in not only this plugin, but other session management plugins like vim-startify. Floating window is the culprit. When we save the session, if there are floating windows open, then the floating window information will be recored into the session file and they cannot be restored correctly when we load the session in the future.

I am using nvim-treesitter-context, fidget.nvim and nvim-scrollview and all of them will bring about this problem. One workaround is close all the floating windows before saving the session. The code below can be a reference.

function M.close_all_floating_wins()
  for _, win in ipairs(vim.api.nvim_list_wins()) do
    local config = vim.api.nvim_win_get_config(win)
    if config.relative ~= "" then
      vim.api.nvim_win_close(win, false)
      -- print('Closing window', win)
    end
  end
end

@kunzaatko
Copy link

I will test this and if it works well for this issue, will add it under troubleshooting. @rmagatti, could you enable wiki for this repo? I don't think this and any other issue fix should pollute the README... right?

@rmagatti
Copy link
Owner

Sounds good!

@kunzaatko
Copy link

kunzaatko commented Apr 27, 2022

Unfortunately, I still cannot add a wikipage it seems. The wiki exists but there must be some kind of switch for letting people add pages...
However, here is what I am suggesting:


Issue: cmdheight after restore is incorrect

description: On restore the cmdheight (location where ex commands can be written) spans almost the full window.

Issue: cmdheight after restore is incorrect

cause: Floating windows are not saved correctly in sessions. This means that when a floating window is present when the session is saved the parameters of the window are saved into the session but it does not include the window being floating.

fix: You can register a callback function for removing all the floating windows on save of a session. auto-session allows to do this by the conf key pre_save_cmds.

function _G.close_all_floating_wins()
  for _, win in ipairs(vim.api.nvim_list_wins()) do
    local config = vim.api.nvim_win_get_config(win)
    if config.relative ~= '' then
      vim.api.nvim_win_close(win, false)
    end
  end
end

-- ...

require('auto-session').setup {
  -- ...
  pre_save_cmds = { _G.close_all_floating_wins },
  -- ...
}

(credits: @rockyzhang24)


I have it now in my forked repo wiki entry here: https://github.com/kunzaatko/auto-session/wiki/Troubleshooting

@rmagatti could you either flip the switch in the settings (if there is any) so that I can add it by myself or copy it in? Thanks :)

@rockyzhang24
Copy link

An addition:

If the floating windows were closed by pre_save hook, we can restore them (or part of) by post_save hook. For example, nvim-treesitter-context and nvim-scrollview show context information and scrollbar via floating windows. Before saving a session, we use the script above to close them. After saving, we can enable them by their builtin commands like TSContextEnable and ScrollViewEnable via post_save hook.

Thanks.

@rmagatti
Copy link
Owner

@kunzaatko odd, wiki is enabled, I wonder if there are any permission settings. 🤔

@rmagatti
Copy link
Owner

I guess I had to add the first page? I'll copy that over tomorrow if you really can't add it there. 👍

@kunzaatko
Copy link

No, unfortunately it still does not allow me to add the page.

@0x7a7a
Copy link

0x7a7a commented May 2, 2022

This issue exists in not only this plugin, but other session management plugins like vim-startify. Floating window is the culprit. When we save the session, if there are floating windows open, then the floating window information will be recored into the session file and they cannot be restored correctly when we load the session in the future.

I am using nvim-treesitter-context, fidget.nvim and nvim-scrollview and all of them will bring about this problem. One workaround is close all the floating windows before saving the session. The code below can be a reference.

function M.close_all_floating_wins()
  for _, win in ipairs(vim.api.nvim_list_wins()) do
    local config = vim.api.nvim_win_get_config(win)
    if config.relative ~= "" then
      vim.api.nvim_win_close(win, false)
      -- print('Closing window', win)
    end
  end
end

@rmagatti
How about using this code as an option?

@rockyzhang24
Copy link

rockyzhang24 commented May 2, 2022

@0x7a7a Some floating windows cannot be closed completely using this piece of code. For example, I cannot close the floating windows of fidget.nvim using this code. I already posted an issue in fidget.nvim repo and am waiting for the author's response.

@0x7a7a
Copy link

0x7a7a commented May 3, 2022

@rockyzhang24
I saw your issue in fidget.
I think fidget's FidgetClose can only deal with the state of the fidget after it's finished running, not while it's running. This is a fidget problem, not auto-session.
Let's see how to solve this very distressing problem

@rmagatti
Copy link
Owner

rmagatti commented May 3, 2022

@kunzaatko I've updated the wiki, thanks for that!

@0x7a7a I don't use any of those plugins myself so I haven't really tested this but this does look like it should work! Some plugins including my goto-preview for example set properties on the floating windows so they are identifiable by the plugin, those could be used here if you can find out if any of those plugins do that too.

@rockyzhang24
Copy link

With this commit (neovim/neovim@3fe6bf3) merged, this issue is solved. It ignores the floating windows when we save the session, so no disordered layout when we restore it.

This issue can be closed.

@kunzaatko
Copy link

Great! This means that the page in the wiki is no longer necessary and can be dropped. Again, unfortunately, I can not edit it... Can you remove it, please, @rmagatti?

@rockyzhang24
Copy link

The page can still be left there for a while at least wait until neovim 0.8 release. I believe most users will persist on the stable neovim version or use an older one, and they still need that snippet.

@pronvis
Copy link

pronvis commented Dec 27, 2023

I have same issue with NVIM v0.9.4 and use('tpope/vim-obsession').
What is interesting - I have vim.opt.cmdheight = 2 at 41 line in set.lua and if I open nvim with nvim -S -V9nvimlog to restore session from Session.vim and save log file.
In log file I found:

  cmdheight=1
	Last set from ~/config_repo/nvim/lua/pronvis/set.lua line 41

which is weird...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants