fix: schedule setting buffer modifiable #18
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #17.
Outdated
I'm mostly following the existing pattern in the
Component:modify_buffer_content, but I'm wondering if a better solution would be to just move theself:set_buffer_option("modifiable", true)into the uppervim.schedulecallback, instead of wrapping the whole thing in an additional one:~~I've tested the above and it seems to work just as well, but I imagine there was a reason
self:set_buffer_option("modifiable", true)was outside of the firstschedulecallback in the first place?Update: After more testing, the bug was still occurring in 7e00951. I force-pushed a new commit which sets
modifiableinside the firstvim.scheduecallback, right before callingmodify_fn(). This seems to work 100% of the time.However, I question whether it's necessary for the
self:set_buffer_option("modifiable", false)to be inside of its ownschedulecallback? I have tested this and it works just as well, and seems to be the more straightforward, "atomic", solution:Out of curiosity, what's the reasoning for changing
modifiablein a separate schedule callback? It seem like it might be predisposed to race conditions.