Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
There is no way to save the current colorscheme to a session.
Describe the solution you'd like
I'd like colorscheme
to be added to 'sessionoptions'
Describe alternatives you've considered
Could possibly write to the session file an additional line when SessionWritePost
fires, but that seems a bit hacky
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
I am not sure this is a good idea. Wouldn't it be better we use whatever you had configured in your .vimrc? I'd guess if you have an old session file you had created with a different colorscheme but nowadays you prefer a different color scheme, I'd argue it's a bad idea to overwrite the old colorscheme. I think this is a setting that belongs into your .vimrc and it does not belong into a session file. (for the same reason I argue, saving options in your session file is not recommended)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
I think it would be good as an option that is not enabled by default. There are times where I am frequently exiting Vim and re-opening the same session, and if I was using a different colorscheme than what I have set in my .vimrc I have to switch back on each reopen.
I am with you on the options, but there's no real chance that changing the color scheme is a harmful operation so I don't see why it couldnt be allowed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
I am with you on the options, but there's no real chance that changing the color scheme is a harmful operation so I don't see why it couldnt be allowed.
What if you delete a colorscheme? And then install a new one with the same name but completely different (was dark, now it is light)? What to do with colorscheme
autocommand that might override the colors? What to do with direct highlight
overrides in your vimrc?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
What if you delete a colorscheme? And then install a new one with the same name but completely different (was dark, now it is light)? What to do with colorscheme autocommand that might override the colors? What to do with direct highlight overrides in your vimrc?
I would think there wouldn't be any special behaviour for any of that stuff. The autocmds and overrides would still be applied. Am I missing something about the operations here? I figured the session file would just call colorscheme <name>
and it would be that simple.
As far as colorscheme deletion, I figured that would be handled the same as if you invoked a colorscheme with an invalid name from command mode.
I guess I don't see this stuff as any different from if your session has a working directory that is no longer a valid path. That is certainly possible but we don't prevent that as an option. Let me know if I'm missing something here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Hello,
Just in case, this of course is not your request, but you can do a small workaround writing the colorscheme (or any other option) in your session file after mksession (using a command, function etc with all the checks that you need)
example:
vim9script
var ses = '/tmp/mysession.vim'
execute $'mksession! {ses}'
var body = readfile(ses)
insert(body, $'colorscheme {g:colors_name}', -3)
writefile(body, ses)
This will write the "current colorscheme" in the session file, and it will be loaded when you do :source /tmp/mysession.vim
Of course, this is an example/idea only.
Regards,
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.