zhimsel / vim-stay

Make Vim persist editing state without fuss

Stay at my cursor, boy!

vim-stay adds automated view session creation and restoration whenever editing a buffer, across Vim sessions and window life cycles. It also alleviates Vim's tendency to lose view state when cycling through buffers (via argdo, bufdo et al.). It is smart about which buffers should be persisted and which should not, making the procedure painless and invisible.

If you have wished Vim would be smarter about keeping your editing state, vim-stay is for you.

Installation

1. The old way: download and source the vimball from the releases page, then run :helptags {dir} on your runtimepath/doc directory. Updating the plug-in via :GetLatestVimScripts is supported. Or,
2. The plug-in manager way: using a git-based plug-in manager (Pathogen, Vundle, NeoBundle, Vim-Plug etc.), simply add zhimsel/vim-stay to the list of plug-ins, source that and issue your manager's install command. Or,
3. The Vim package way (requires Vim 7.4 with patch 1384): create a pack/vim-stay/start/ directory in your 'packagepath' and clone this repository into it. Run :helptags {dir} on the doc directory of the created repo. Run :runtime plugin/stay.vim to load vim-stay (or restart Vim).

Usage

Recommended: set viewoptions=cursor,folds,slash,unix (but at the very least do set viewoptions-=options). Edit as usual. See the documentation for more.

Rationale

Keeping editing session state should be a given in an editor; unluckily, Vim's solution for this, view sessions, are not easily automated without encountering painful bumps. As the one plug-in available that aimed to fix this, Zhou Yi Chao’s restore_view.vim, limited itself to Vim editing sessions, didn’t play well with other position setting plug-ins like vim-fetch and as there were some issues with its heuristics, vim-stay was born.

License

vim-stay is licensed under the terms of the MIT license according to the accompanying license file.

vim-stay's Issues

"vim-stay could not read the view session file" for new files

This is a regression today after upgrading to 1.4.0 of the plugin.

When opening an existing file that hasn't been opened before, or after clearing your view directory:

vim-stay could not read the view session file! Vim error E484: Can't open file /Users/eapache/.local/share/nvim/view/~=+test=

It doesn't seem to affect functionality, it's just annoying. It's gone subsequent openings of the file once the view file actually exists.

This is in Neovim from Homebrew on OSX:

NVIM v0.3.0
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -I/tmp/neovim-20180612-71518-1f95nfa/neovim-0.3.0/build/config -I/tmp/neovim-20180612-71518-1f95nfa/neovim-0.3.0/src -I/usr/local/include -I/usr/local/opt/gettext/include -I/usr/include -I/tmp/neovim-20180612-71518-1f95nfa/neovim-0.3.0/build/src/nvim/auto -I/tmp/neovim-20180612-71518-1f95nfa/neovim-0.3.0/build/include
Compiled by [email protected]

Features: +acl +iconv +jemalloc +tui

Stay should not load view state when re-editing buffer in another window

The original report by @fent in #45 read:

Often when editing the same file in multiple windows, I might go to another buffer in one of the windows to reference something, and then come back. But previously when I did, the cursor would jump to where the other window is.

As stated here, the PR in the submitted form does not seem the correct way to address things; this issue seeks to pinpoint the cause of the error and to develop a less destructive approach.

Can't create view folder in C:\Program Files\Vim/vimfiles/view

This should create in userhome directory instead, I use gvim 8 / 1-1214 on windows.
image here

Focus gets confused, ends up with no split focused

Twin bug to vim-airline/vim-airline#1131 as I'm still not sure which plugin is the actual culprit; they only seem to misbehave when together.

Plug-in initialisation failure with Vim version < 7.4.279

Error detected while processing function <SNR>47_integrate:
line    2:
E118: Too many arguments for function: globpath
E15: Invalid expression: globpath(&rtp, 'autoload/stay/integrate/*.vim', 1, 1)

This is due to globpath() not supporting the fourth argument requesting List output before 7.4.279. Reported by Thomas Sattler via email.

Slight incompatibility with Vimwiki plugin

Vimwiki maps <cr>, backspace, etc to its own functions, but it allows you to override this behavior by using hasmapto. (EDIT: What I mean is the vimwiki.vim script uses hasmapto, not that the user himself uses it, in case that wasn't clear.) If hasmapto sees that a mapping already exists (like if you mapped <cr> to something else in your .vimrc), then it won't commandeer it.

However, for some reason, this stops happening when vim-stay is installed. Now, vimwiki maps <cr> (and everything else it maps) regardless of whether I have my own mapping.

Any idea as to why this is happening? I'd like to fix this, as I like both plugins a lot.

vim-stay changes foldmethod

Hi,
I tried to use vim-stay to restore my folds, but apparently it changes the foldmethod to diff. I usually use foldmethod=syntax. Is there any way to keep my foldmethod?
thanks!

Avoid saving `lcd`

How could I make vim-stay avoid saving lcd variable?
Reading the doc, seems the Autocommand API might be a good direction,
but I'm not sure how to work it out. Could you help? :)

vim-stay in neovim produces E484 error when opening new file

If I open a file that doesn't already have a viewdir file (i.e. that vim-stay has not seen before), it produces an error stating that it can't open that file. This is expected, since it doesn't exist until the buffer is saved, and the viewdir file is created.

For example. I created a blank file, /tmp/test_file, and after confirming that there is no viewdir file for it already (clearing the viewdir), I open it in neovim: nvim /tmp/test_file. This produces the following error in the statusline message section:

vim-stay could not read the view session file! Vim error E484: Can't open file /Users/zhimsel/.local/share/nvim/view/=+private=+tmp=+test_file=

This is only present in neovim, not vim. Once the buffer is written, :w, a viewdir file is created in ~/.local/share/nvim/view for that file, and any subsequent times neovim opens that file, the error is not produced (since it exists).

I have a feeling it's related to this section, but I don't know vim-stay or vimscript well enough to troubleshoot.

I also noticed that there's a bunch of version specific conditionals that may be related as well.

Any ideas?

---

:version
NVIM 0.1.4
Build type: RelWithDebInfo
Compilation: /usr/local/Library/ENV/4.3/clang -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-p
rototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H -I/tmp/neovim-20160501-1882-n124ji/neovim
-0.1.4/build/config -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/src -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/deps-build/usr/include -I/tmp/neovim-20160501-1
882-n124ji/neovim-0.1.4/deps-build/usr/include -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/deps-build/usr/include/luajit-2.0 -I/tmp/neovim-20160501-1882-n124ji/neo
vim-0.1.4/deps-build/usr/include -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/deps-build/usr/include -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/deps-build/usr/
include -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/deps-build/usr/include -I/usr/local/opt/gettext/include -I/usr/include -I/usr/include -I/tmp/neovim-20160501-18
82-n124ji/neovim-0.1.4/build/src/nvim/auto -I/tmp/neovim-20160501-1882-n124ji/neovim-0.1.4/build/include
Compiled by zach@randir

Optional features included (+) or not (-): +acl   +iconv    +jemalloc
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/Cellar/neovim/0.1.4/share/nvim"

Prevent changing directory when restoring view.

According to my observations and Vim's help mkview always adds lcd ... command to created file. This can lead to unexpected current directory changes when same file is opened in different "sessions" (projects etc.)
A possible workaround would be to remove lcd line from the generated script.

Error when using BufStayLoadPost autocmd

With .vimrc as

call plug#begin('~/.vim/plugged')
  Plug 'https://github.com/kopischke/vim-stay'
call plug#end()

autocmd User BufStayLoadPost * echomsg 'hello'

there appears the error message

Error detected while processing User Auto commands for "BufStayLoadPost":
E20: Mark not set

Add command to clear 'viewdir' [RFC]

Views sessions stored before changing viewoptions can lead to confusing misbehaviour like that seen in #3. Possible solution:

• add a ClearViewDir command
• maybe also add a SetViewOptions command calling the above when changing viewoptions

Ideas and comments welcome!

sessionoptions

it cost me a while to realize that mksession also saves folds. With vim-stay that's doubled functionality. So how about proposing

set sessionoptions-=folds

in the readme and doc?

Duplicate help tag

Pathogen error when starting Vim:

Error detected while processing function pathogen#helptags:
line    4:
E154: Duplicate tag "BufStayLoadPost" in file /home/jln/.vim/bundle/vim-stay/doc/vim-stay.txt
Press ENTER or type command to continue

Reported by @senft in a comment to #3.

Handling of reloading through ":checktime"

When a buffer is open in multiple windows (across multiple tabs), and the file gets changed from outside, calling :checktime and reloading the file will not keep the cursor position in the non-current window - it will move to the first line.

Is there anything vim-stay could do about this?

vim-stay breaks vim-fetch

See wsdjeg/vim-fetch#34

comparison to restore_view

Hello Martin,

Thanks for the plugin.

Could you explain the errors you found in restore_view's heuristics which buffer views to save and restore?

For example, restore_view excludes all non-modifiable buffers wheras vim-stay seems to include them but explicitely disables netrw buffers.

It makes me wonder if non-modifiable buffers happen to be file buffers?

Does this plugin automatically clear out views beyond a certain date

The restore_view.vim plugin doesn't automatically clear views as a result the view folder grows in size. At some point or other its starts causing problems. For example.. I started having problems with buffexplorer because I had a large view folder.

It seems there is no development on the restore_view plugin. Last commit was in 2014/5: https://github.com/vim-scripts/restore_view.vim, https://github.com/senderle/restoreview depending in which one you look at.

So, either I have to write a function in VIM which automatically takes care of this or start a cron job.

It seems this plugin is similar to restore_view but attempts to improve on it. Does this plugin automatically removes view files beyond a certain time.. to cause less issues: jlanzarotta/bufexplorer#72, amix/vimrc#426.

I also use the vim-obsession plugin for session management. Does this plugin attempt to do both sessions and view management simultaneously? Are there any clashes between this plugin and vim-obsession?

Add command or option to `:CleanViewdir`'s only nonexisting files.

Would it be possible to add a command or an option to the existing command :CleanViewdir that will delete only the view files which do not exist in the file-system? That will help users to clean their view dir from the garbage that may clutter there after a long time usage.

Amalgam of restore_view and vim-stay

So after our discussion I amalgated both persistency check functions of vim-stay and restore_view . I leave it here for reference. Maybe a persistency check by the file name can be made an option in vim-stay, understood that this goes against vim-stay's philosophy. Here it is:

function! s:isPersistent()
    " From VIM-STAY:

    let bufnr = bufnr('%')
    if !(bufexists(bufnr)
    \ && getbufvar(bufnr, 'stay_ignore', 0) isnot 1
    \ && index(['', 'acwrite'], getbufvar(bufnr, '&buftype')) isnot -1
    \ && getbufvar(bufnr, '&previewwindow') isnot 1
    \ && getbufvar(bufnr, '&diff') isnot 1
    \ && getbufvar(bufnr, '&bufhidden') isnot# 'wipe'
    \ && filereadable(fnamemodify(bufname(bufnr), ':p')))
        return 0
    endif

    " From RESTORE_VIEW.Vim:

    " Recognize a volatile buffer by its name. Works in
    " pratice most of the time but strictly speaking incorrect because the
    " buffer name is file name independent. See discussion at
    " https://Github.Com/kopischke/vim-stay/issues/2
    if expand('%') =~ '\[.*\]' | return 0 | endif
    if empty(glob(expand('%:p'))) | return 0 | endif
    if len($TEMP) && expand('%:p:h') == $TEMP | return 0 | endif
    if len($TMP) && expand('%:p:h') == $TMP | return 0 | endif

    return 1
endfunction

getbufvar signature incompatible with vim < v7.4

vim --version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 15 2012 00:31:26)
Included patches: 1-330

Error detected while processing function stay#ispersistent:                                               
line    2:                                                                                                
E118: Too many arguments for function: getbufvar                                                          
E15: Invalid expression: bufexists(a:bufnr) && !empty(l:bufpath) && getbufvar(a:bufnr, 'stay_ignore', 0) i
snot 1 && getbufvar(a:bufnr, '&buflisted') is 1 && index(['', 'acwrite'], getbufvar(a:bufnr, '&buftype')) 
isnot -1 && getbufvar(a:bufnr, '&previewwindow') isnot 1 && getbufvar(a:bufnr, '&diff') isnot 1 && index([
'', 'hide'], getbufvar(a:bufnr, '&bufhidden')) isnot -1 && filereadable(l:bufpath) && stay#isftype(a:bufnr
, a:volatile_ftypes) isnot 1 && stay#istemp(l:bufpath) isnot 1

Error when opening a file (v1.4.0)

Hi, I was testing the 1.4.0 release branch and sometimes I'm getting this error when opening a file.

Sorry for reporting issues on a unreleased version, but some of the bug fix included in that are really useful for me!

Errors from mkview with view files written through "sudo vim"

If sudo vim has been used initially for a file (where the view file gets created), you will end up with files that are owned by root.

When editing it without sudo later, the following error happens (through the call to mkview):

Error detected while processing function stay#view#make:
line   14:     
E190: Cannot open "/home/user/.nvim/view/=+etc=+apt=+sources.list.d=+nodesource.list=" for writing

It might be feasible to skip creation of views (calling :mkview) in case there is no view file already (and therefore a new one would be created). But I don't know if that can be detected.

Neomru uses the following code to detect usage of sudo and then skips writing its MRU list:

function! s:is_sudo() "{{{
  return $SUDO_USER != '' && $USER !=# $SUDO_USER
        \ && $HOME !=# expand('~'.$USER)
        \ && $HOME ==# expand('~'.$SUDO_USER)
endfunction"}}}

(source)

I think it might be fine to skip

fastfold integration

Here's an edge case:

Suppose you open a file with fdm=syntax, but then issue ":set fdm=marker". Then after :bd %, still w:lastfdm=syntax. Only if an additional trigger, like saving, fold movements, or zuz is issued, the fdm is correctly restored to marker.

I guess w:lastfdm should only be saved instead of &l:fdm if the latter is manual, to exclude the case that the user manually changed but hasn't triggered any FastFold autocmd before storing the view.

Activates wrong window of multiple buffer windows

stay will always jump back to the first (numerically lowest) window displaying a buffer when a window is closed, instead of the last window that was active. This causes issues like:

• junegunn/fzf#532
• junegunn/fzf.vim#105

The root cause is naive usage of bufwinnr() to get the window number to jump to.

vim-stay error E867: (NFA) Unknown operator '\zh'

Hi Developer,
When I use this plugin in Windows, I tend to get this error when opening files.

I tried to debug it, and comment out the catch "other errors block of stay#view#load(winid), I get the following verbose output of vim:

E867: (NFA) Unknown operator '\zh'
E68: Invalid character after \z
No matching autocommands

Error detected while processing function <SNR>9_LoadView[8]..stay#view#load:
line   31:
E867: (NFA) Unknown operator '\zh'
E68: Invalid character after \z

The "zh" string is the starting of my username, so I think it's caused by the un-escape window path.
Would you please give it a fix ?

Thanks

outsource persistency check

Hello,

I noticed that the persistency check is quite utile. So much that I put it in a separate file at

https://github.com/Konfekt/FastFold/blob/master/ftdetect/persistent.vim

How about checking for the same b:isPersistent variable in both plugins to avoid redundancy.

I realize that for your plugin, I got to tear that check apart though into a separate persistent and temp.vim ?!

Should this plugin save the arglist?

I have set viewoptions=folds (only folds) so didn't expected this.

Thanks

Edit: checking :help :mkview

The output of ":mkview" contains these items:
1. The argument list used in the window.  When the global argument list is
   used it is reset to the global list.
   The index in the argument list is also restored.
...

also in :help vim-stay-troubleshooting

MY CURRENT WORKING DIRECTORY / MY ARGLIST CHANGES WHEN OPENING A FILE

vim-stay uses |mkview| and |loadview|, which persist the local arglist and
local working directory. This can be a bit disorienting at first, but it is by
(Vim's) design. If this really irks you, you may be able to work around it
using vim-stay's autocommand API (see |vim-stay-autocommands|).

Sorry, another case of rtfm

Check for sourcing of view session files is too naive

As the Investigation into the root cause of #25 showed, recognising the sourcing of a view session file fails when viewdir is set to /view//; other corner cases may lurk in the quirks of Vim’s settings directory syntax. In such cases, b:stay_loaded_view is never set and SessionLoadPost fails to fire.

view files for files in &backupskip

With

backupskip=/tmp/*,/tmp/*,*.tmp,*~

vim-stay still creates a view file for the file /tmp/mutt-linux-5msm-1000-2981-5594735571973679250, that is there is a file

.local/share/vim/view/=+tmp=+mutt-linux-5msm-1000-2981-5594735571973679250=

This happens von Vim 8.03 compiled with +wildignore and with glob2regpat() available.

Avoid doubling on Session Load

When loading a session, a SessionLoad variable is defined. Vim-Stay, if sessionoptions includes folds and cursorposition, should check for the existence of this variable and skip restore view, as restore session already takes care of everything.

View session state intermittently gets out of sync with view

Sometimes I modify files when viewing/filtering -- like retab, etc.
After that I undo all changes (in some cases -- undo only after reopening file).
But vim-stay keeps my previous view modifications, which in unwanted behaviour.
We have only general :CleanViewdir command to clear all at once, but I have only one bad view.
Therefore it's needed to go into far-far-away path, search in >1000 files for current one and delete.
Maybe, you will add convenient command like :CleanStayCurrent or :CleanCurrentView?

Integrate with FastFold

FastFold by @Konfekt leverages the same events as vim-stay:

Regarding compatability with FastFold, vim-stay must be loaded after FastFold so that mkview in vim-stay's BufWinLeave and BufWinEnter autocmds saves the syntax or expression foldmethod and not the manual foldmethod FastFold artificially imposes.

The BufLeave autocmd is curious as it seems accounted for by the BufWinLeave autocmd ?! If vim-stay only used that autocmd, than the timing would always be wrong, because the BufLeave autocmd is invoked too early. However, as things stand, the erroneous (that is, incompatible to FastFold) view file created by the BufLeave autocmd is overriden by the correct one from the BufWinLeave autocmd.

The problem is that when quitting a window, BufWinLeave sometimes fires after the window has been destroyed (the window number returned by getbufwinnr(bufnr) is -1 – see :h BufWinLeave, which warns of this, albeit a bit cryptically), which makes view creation impossible (:mkview needs a valid window). BufLeave OTOH always fires in a valid window, so both events are needed to catch “buffer leaving a view” situations. This also means vim-stay will at times save the spurious manual folds set by FastFold.

View session files override modelines

We fire SessionLoadPost without evaluating modelines, which leads to stale settings from a previously saved view session file taking precedence over modeline values added or removed after the saving of the view. As the view uses the actual setting state of the buffer, the modeline values will not be stored in subsequent saves of the view session either.

This is one of the causes of the “out of sync” behavior reported in #24.