search

preservim / nerdtree

A tree explorer plugin for vim.
Do What The F*ck You Want To Public License
19.56k stars 1.44k forks source link

Error when loading a vim session: BufLeave NERD_tree_* autocommand: Variable b:NERDTree does not exist #1397

Closed terminatorul closed 8 months ago

terminatorul commented 9 months ago

Description

Hello,

When I save and load a session with NERDTree panel open, I always get errors on session restore, from BufLeave and FocustLost autocommands, saying variable b:NERDTree does not exist.

It feels as if the Vim session script restores the NERD_tree_1 buffer and window, the NERDTree plugin gets triggered as it sees the special buffer name, but then the buffer restored by the session script is not the same as a buffer created by NERDTree plugin, and is missing the buffer variables...

rzvxa commented 9 months ago

Hey @terminatorul, Thanks for reporting this. Restoring the exact same state will be really hard since we need to serialize the state of NERDTree somehow which I guess isn't going to be easy.

On the other hand, if we want to go the simple route, We can either close the buffer on load and suppress the errors, Or open a new buffer (with the initial state and not the previous state) and replace the old one.

I'll let this issue stay open for a while in case we get any ideas to do it the right way, Feel free to suggest any approach you may think of, Or even create a PR on this subject!

terminatorul commented 9 months ago

Yes, I had to update my macros to close NERDTree before mksession, and to open NERDTreeVCS on SessionLoadPost event...

I think the important detail is to avoid the error, in any way that looks good enough. So opening the current directory, as with :NERDTreeClose | NERDTree, is a good option...

If user enables globals flag in 'sessionoptions', a global string with the directory of each NERD_tree_# buffer could be used to save the all top directories in the session... if you think it is usefull

So my opinion re-creating the full state of the NERD tree buffers is not that usefull to an end user. It is still a nice-to-have, sure, but not that important as making the feature work.

If I can make a PR it will have to be at a later time, I am focused on some other thing at the moment and I grew to dislike how easy it is to get script errors in Vim ... it's so fragile

rzvxa commented 9 months ago

I haven't tested it but I guess setting sessionoptions to the buffer and global can provide enough information to restore the state. It certainly is something that we can not rely on since that's for users to decide (and it would be wrong if we make the decision for them).

So my opinion re-creating the full state of the NERD tree buffers is not that usefull to an end user. It is still a nice-to-have, sure, but not that important as making the feature work.

Yeah, I agree, for now just detecting the buffers and replacing them with fresh instances can work for most cases since it will drop the annoying errors on load, later on, we can follow up on this with support for restoring the state of the buffer whenever the appropriate options are set. There are still going to be a few edge cases that may happen in this process. For example, without any extra information, it may be impossible to detect whether or not 2 buffers are pointing to the same instance(I'm not sure about this part of the project but we can have mirror instances of NERDTree which are not independent of each other); If I'm not mistaken these mirrored instances live on separate buffers and if we go with this approach they are going to get separate instances after the session load. But of course, if that is the case we can workaround it with a more cleaver naming scheme for the buffers so we can get away with it without any extra information other than the buffer name itself!

If I can make a PR it will have to be at a later time, I am focused on some other thing at the moment and I grew to dislike how easy it is to get script errors in Vim ... it's so fragile

Yes vim script can be a pain in the rear at times, But on the other hand, NERDtree is surprisingly well-structured for a Vim plugin. It has a bit of an OOP feel to it; Even tho it isn't my favorite way of writing code it is a much better experience than the procedural way of doing things which is more popular among Vim plugins.

(PS: don't get me wrong procedural programming can be good at times, especially if done without coupling the data with the code which is something that I find impossible in OO. I don't want to say it is bad because that's a naive thing to say; I just think it is much easier to write unmaintainable code with procedural style if it is abused.)

TL;DR

A fix for this is going to be introduced in the next few minor versions; In case you found the time and needed the fix a bit sooner feel free to create a PR for it. Also, let me know if I can be of any help with that.

One more thing, If you think your macro can be used by the other users it would be nice for the time being if you create a PR adding that macro to the FAQ.