Fix Paste Override Not Pasting in File Preview Editor and Race Condition in YAML Timestamp
Updates via User Edits
#1221
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 #1219
There was an issue reported where when a user tries to paste into a markdown file preview it was pasting in the current document instead. This was caused by not using the editor provided by the
editor-paste
event. Using that editor, fixed the issue. However it showed another issue.Using the editor from an
editor-paste
event is not 100% reliable for the Linter since it only provides the content linked to by the internal link. That is fine if it links to a file. However if it links to a header, paragraph, or otherwise, it would insert the timestamp change at the start of the linked to text. So there needed to be branching logic in the Linter to handle when the editor was a whole file versus it being in a part of the file. This also showed another issue.The Linter was occasionally logging a warning saying that it was trying to run a debounce function on a file that was no longer in the map. This was odd since the logic for adding to the map first checked if the value was present. Well, the issue was that between the first
editor-change
event and the second you could have a situation where the cached read of the file's contents had not yet completed. This resulted in two plus additions to the map instead of one. To fix this, the cached read was moved to after the value was added to the map. The reason it needed to move is that theeditor-change
event does not seem to handle waiting async callbacks to complete before starting the nexteditor-change
event.Changes Made:
editor-change
's debounced function to make sure it handled partial file editors vs full file editors properlyeditor-changed
file info to after the addition to the map to prevent race conditions where the same file got added to the map more than once causing warnings in the console