-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf: only execute on current buffer since this event is called on each buffer #246
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was originally intended for handling session files created with :mksession
. At the time I didn't know about :mkview
and :loadview
, and didn't know that they also fired the same autocmd. What do you think of instead adding an early return at the top of this?
if vim.g.SessionLoad ~= 1 then
return
end
Then it should only run when sourcing a session file, not when doing :loadview
(at least, in my testing the scripts created with :mkview
don't set this variable). Does that also fix the issue for you?
5bd5eb2
to
5bf8d1c
Compare
That change does work and adds another check to avoid the bug described in #245. It's definitely a good approach for avoiding running during Also just to clarify, this PR does resolve the problem that is described in #245 but does not directly resolve the bug in the Is there a chance when saving a session where an oil buffer could be saved while it doesn't belong to a window? If that's possible then this bug could still crop back up in the future if someone is an avid user of |
5bf8d1c
to
6129a3f
Compare
6129a3f
to
dd24c31
Compare
I removed my 2nd commit which checks if the filetype is For now it's best to just keep this PR minimal and implement the fix and performance improvements that make the most sense and are semantically sound. For now this PR only does two things:
What this does not do:
|
Thanks! |
When saving sessions, the file that you source (i.e.
Session.vim
) executesdoautoall SessionLoadPost
which will execute the autocmd eventSessionLoadPost
on each buffer. So we don't need to manually loop over each buffer ourselves, the autocmd execution actually handles it for us. This causes an exponential growth in the number of times these calculations are made.Also I found this while investigating #245 but sadly this doesn't fix the problem root there.
EDIT:
I just pushed another performance improvement to check ifoil
is already loaded by checking the filetype. When restoring a session withsource
like the original issue #29 the filetype is not set tooil
, but when loading views withloadview
which also callsSessionLoadPost
the oil buffers are already loaded and therefore the filetype is alreadyoil
. This allows us to optimize this out. There might be a better way to check if oil is already loaded in a buffer, if so let me know! Another thing is that with this performance update it circumvents the problem in #245 so that it never happens, but doesn't fix the root issue which seems to be a bug in theload_oil_buffer
function where even when it's only called on buffer numbers that belong tooil
buffers, they sometimes clobber details in other buffer numbers which I believe is coming from the fact that those buffers do not actively belong to a window. This should still be investigated by someone more familiar with the codebase. Because this doesn't actually fix the bug in that function, it might not be considered "closing" of #245 even though the symptoms of the problem go awayEDIT 2: Most up to date information on what this PR does and what it does not do can be found below: #246 (comment)
With the most recent changes we can also say this this resolves #245 since it should avoid the issue from ever happening, but it might come up down the road if someone gets into some complicated edge cases when using
mksession
. Chances are this is never going to happen though.