You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 29, 2023. It is now read-only.
I was wondering if you could edit the code so that there's a g:workspace_checkcompatible variable that can be set to 0 so the plugin doesn't need to check for whether that variable is set to 'compatible' or 'nocompatible' since setting this setting changes a host of other settings, specifically the whichwrap setting.
Problem:
The plugin doesn't properly store or reset the whichwrap variable, which is reset by set compatible or set nocompatible. I have in my .vimrc: set whichwrap+=<,>,h,l
The whichwrap setting makes the left and right arrows wrap to the previous or next lines when they hit the beginning or end of a line respectively, which is normal behavior in any other modern editor. Without it, vim reverts back to its Vi behavior, stopping the cursor when a h or l is used at the beginning or end of a line (or on a blank line), restricting movement for these keys to just one line.
Lines of Code:
The vim-workspace plugin by default sets vim to 'nocompatible' (g:workspace_nocompatible == 1). This is the best setting, but by default just setting the whichwrap setting again after .vimrc has been loaded wipes out the preset characters for 'whichwrap' set in .vimrc, resetting whichwrap to its defaults (whichwrap=b,s -- for just the backspace and space characters).
In workspace.vim, this global variable is checked for on Line 17. Then, when a previous session is loaded in vim by calling s:LoadWorkspace(), this variable is checked and noncompatible is set on line 127. The problem is that the plugin doesn't save or restore the settings in the whichwrap variable with the session.
Reproduction:
To recreate this problem, set the following whichwrap: set whichwrap+=<,>,h,l
This is the setting that is desired, so entering set whichwrap? will show whichwrap=b,s,<,>,h,l.
Save a session with the plugin, close vim, then open the directory in vim with the session.
The plugin fails to store whichwrap, so when line 127 is called, it sets the whichwrap setting back to its default: set whichwrap? will show whichwrap=b,s
What's in the .vimrc is also not taken into account since the plugin is setting set nocompatible after .vimrc is read.
At first, I was going to request that the plugin please be edited to include storing and restoring the whichwrap settings. But, I saw that you answered a similar issue here: #4
By including the g:workspace_nocompatible variable, one can set this to 0 and escape the whole problem. But, this confuses the setting in my .vimrc files so that it's not so clear what I'm trying to do (the variable name suggesting that I'm trying to set it to compatible). So my suggestion is to change line 127 to something to the effect of:
...
let l:filename = expand(@%)
if g:workspace_checkcompatible==1
if g:workspace_nocompatible | set nocompatible | endif
endif
execute 'source ' . escape(s:GetSessionName(), '%')
...
This way it's backwards compatible with everyone who has the setting set for the same purpose but also clarifies the compatible setting so that it can be skipped.
Is it possible to add this to the code?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I was wondering if you could edit the code so that there's a
g:workspace_checkcompatible
variable that can be set to 0 so the plugin doesn't need to check for whether that variable is set to 'compatible' or 'nocompatible' since setting this setting changes a host of other settings, specifically the whichwrap setting.Problem:
The plugin doesn't properly store or reset the whichwrap variable, which is reset by
set compatible
orset nocompatible
. I have in my .vimrc:set whichwrap+=<,>,h,l
The whichwrap setting makes the left and right arrows wrap to the previous or next lines when they hit the beginning or end of a line respectively, which is normal behavior in any other modern editor. Without it, vim reverts back to its Vi behavior, stopping the cursor when a h or l is used at the beginning or end of a line (or on a blank line), restricting movement for these keys to just one line.
Lines of Code:
The vim-workspace plugin by default sets vim to 'nocompatible' (g:workspace_nocompatible == 1). This is the best setting, but by default just setting the whichwrap setting again after .vimrc has been loaded wipes out the preset characters for 'whichwrap' set in .vimrc, resetting whichwrap to its defaults (
whichwrap=b,s
-- for just the backspace and space characters).In workspace.vim, this global variable is checked for on Line 17. Then, when a previous session is loaded in vim by calling s:LoadWorkspace(), this variable is checked and noncompatible is set on line 127. The problem is that the plugin doesn't save or restore the settings in the whichwrap variable with the session.
Reproduction:
set whichwrap+=<,>,h,l
set whichwrap?
will showwhichwrap=b,s,<,>,h,l
.set whichwrap?
will showwhichwrap=b,s
What's in the .vimrc is also not taken into account since the plugin is setting
set nocompatible
after .vimrc is read.At first, I was going to request that the plugin please be edited to include storing and restoring the
whichwrap
settings. But, I saw that you answered a similar issue here: #4By including the
g:workspace_nocompatible
variable, one can set this to 0 and escape the whole problem. But, this confuses the setting in my .vimrc files so that it's not so clear what I'm trying to do (the variable name suggesting that I'm trying to set it to compatible). So my suggestion is to change line 127 to something to the effect of:This way it's backwards compatible with everyone who has the setting set for the same purpose but also clarifies the compatible setting so that it can be skipped.
Is it possible to add this to the code?
The text was updated successfully, but these errors were encountered: