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.schedule
callback, 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 firstschedule
callback in the first place?Update: After more testing, the bug was still occurring in 7e00951. I force-pushed a new commit which sets
modifiable
inside the firstvim.schedue
callback, 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 ownschedule
callback? 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
modifiable
in a separate schedule callback? It seem like it might be predisposed to race conditions.