[vim/vim] Session restoration breaks mappings (Issue #16688)
Maxim Kim
habamax created an issue (vim/vim#16688)Steps to reproduce
- create following configuration
~/.vimrc
vim9script
import autoload 'test.vim'
nnoremap <space>h <scriptcmd>test.Test()<cr>
~/.vim/autoload/test.vim
vim9script
export def Test()
echo "Test"
enddef
- run vim, check
<space>hmapping works, and you can see "Test" message:
- Create a session with
:mks! - restart vim and restore session with
:so Session.vim - press
<space>h
Expected behaviour
Mappings should not be broken after session restoration
Version of Vim
9.1.1129
Environment
debian12, alacritty, bash
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#16688)Also might be related to #16549
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#16688)I wonder how we would even fix this given the current way sessions work. They are just a series of commands and don't have a way to recreate the <scriptcmd> mapping. There's definitely a tension here regarding how much sessions should remember / restore as runtime states and what should be recreated by vimrc / plugins, as Vim doesn't really have that information. I guess we could make the session script not apply the mapping if one already exists due to the vimrc.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#16688)It does make me wonder if the sessionoptions are doing us a disservice here by providing a single localoptions that group mappings and local options together. Feels to me it could makes sense to preserve local options, but for most people mappings and usually provided by your own configuration (vimrc) or plugins and you don't usually want a session to muck with them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#16688)Hm, isn't the issue rather that <scriptcmd> mappings are stored in the Session file at all and thus break the script context where they should be defined? Should we rather skip saveing any mapping that starts with <scriptcmd> instead?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#16688)Not only scriptcmd but expr that uses imported functions
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#16688)And how would one detect if an expr in mapping is vim9script?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#16688)I think we would need to save and restore the SCRIPT_ITEM list (e.g. the list that is show with :scriptnames). If we can save and restore those sourced list, we should have the correct script context for the mappings and we could use maplist() and mapset() to save and restore those. That would be a bit of work however.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#16688)I am not sure how it would help to distinguish:
vim9script
import autoload "test.vim"
nnoremap <expr> a test.Func()
nnoremap <expr> b test#Func()
nnoremap <expr> c pumvisible() ? "<down>" : "c"
in this case only a wouldn't work if restored from Session.vim.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#16688)yeah, perhaps its best to skip vim9 scripts. Actually I think trying to restore options and mappings in Sessions causes more problems than what it is trying to solve. Perhaps we should remove options from sessionoptions?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Woods
mmrwoods left a comment (vim/vim#16688)And how would one detect if an expr in mapping is vim9script?
This will also apply outside of trying to restore sessions, as you can obtain information about a mapping using maparg(), and if you can determine that a mapping is an expr from mapping-dict, it seems reasonable to expect to be able to eval() that expression, which is exactly what vim-which-key does to show a menu of mappings and also then apply them (and this breaks vim-which-key)
vim-which-key similarly trips up on <scriptcmd> mappings, because it does not know how to apply them, and I don't think it currently can know as mapping-dict doesn't contain any info to tell it which scripts to import (just the id of the script where the mapping was defined).
I honestly have no idea what the answer to this is long term, in the short term maybe vim9script mappings should be discouraged, at least within plugins shipped with Vim as they cause problems with default Vim behaviour, both with sessions and programmatically examining and applying mappings.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#16688)I like vim9scipt aware mappings, so would be against discouraging them.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mark Woods
mmrwoods left a comment (vim/vim#16688)I guess <ScriptCmd> could be updated such that it can used with feedkeys() like <Cmd>, at the moment trying to use it like this results in errors, e.g.
:call feedkeys("\<scriptcmd>vim9.Open(GetWordUnderCursor())\<CR>", "nt")
E476: Invalid command: vim9.Open(GetWordUnderCursor())
Equivalent <Cmd> mappings work fine with feedkeys().
But that wouldn't solve the problem with <expr> mappings, maybe something like <scriptexpr> is required such that the context required to eval() the script can be stored with the mapping?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mark Woods
mmrwoods left a comment (vim/vim#16688)Although nothing to do with sessions, but for the record, using <Plug> mappings can fix the problems with plugins like vim-which-key that rely on applying the rhs of a mapping as they work fine with feedkeys(), e.g.
diff --git a/runtime/plugin/openPlugin.vim b/runtime/plugin/openPlugin.vim index ff9c5a385..df047d795 100644 --- a/runtime/plugin/openPlugin.vim +++ b/runtime/plugin/openPlugin.vim @@ -34,10 +34,12 @@ if !no_gx enddef if maparg('gx', 'n') == "" - nnoremap <unique> gx <scriptcmd>vim9.Open(GetWordUnderCursor())<CR> + nnoremap <Plug>(open-word-under-cursor) <scriptcmd>vim9.Open(GetWordUnderCursor())<CR> + nnoremap gx <Plug>(open-word-under-cursor) endif if maparg('gx', 'x') == "" - xnoremap <unique> gx <scriptcmd>vim9.Open(getregion(getpos('v'), getpos('.'), { type: mode() })->join())<CR> + xnoremap gx <Plug>(open-word-under-cursor) <scriptcmd>vim9.Open(getregion(getpos('v'), getpos('.'), { type: mode() })->join())<CR> + xnoremap gx <Plug>(open-word-under-cursor) endif endif
After these changes vim-which-key can apply the gx mapping using call feedkeys("\<Plug>(open-word-under-cursor)", "nt")
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.