Open melMass opened 1 month ago
For reference, this is the same config without lumen:
I have since read your rant on this commit 😅
I guess it's not a huge deal? As I said I don't need it on Windows, it was mostly to let you know
Process startup time is known to be a little longer on Windows, however 837ms is still a bit too much (by about two orders of magnitude). I'd have to boot into my Windows install again to check out if and why it takes so long.
That being said, I've been thinking about reverting 03521684e78d1c88513428dca2b2b0b29e578fe6 for quite some time now. I'd have to check out if vim's implementation of background detection is not as buggy anymore as it was back then (plus it also assumes the terminal emulator follows the system theme) and if that is the case, the blocking check at startup could be avoided, which would make startup instant on all platforms.
I guess background checcking could also make vim.lumen works when ssh-ing? That would be great to have (should I open another issue for that)?
I guess background checking could also make vim.lumen works when ssh-ing?
Yes, if the terminal follows the system theme. You can already get that behaviour with let g:lumen_startup_overwrite=0
.
It's difficult to pick a default option here, because checking the background of terminal obviously will pick the wrong color if the terminal emulator does not follow the system theme (which is the case for most users with default settings).
Describe the bug
I'm not using lumen on Windows but as I was profiling my config I stumble upon this:![image](https://github.com/vimpostor/vim-lumen/assets/7041726/d278c446-21d4-4f07-a170-48aa96ba19b4)
I will test later today on mac and report if it's in the same range there.
To reproduce
--startup-time
or check lazyExpected behavior
to be confirmed if it's OS specific but I expect shorter startup times
Debug output
No response