Skip to content
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

fix(latex-renderer): fixed renderer breaking when a snippet change made it stop compiling #1476

Merged
merged 1 commit into from
Jun 24, 2024

Conversation

ALVAROPING1
Copy link
Contributor

@ALVAROPING1 ALVAROPING1 commented Jun 23, 2024

Previously, when a snippet that had already been rendered was modified and the new version failed to compile, the renderer got stuck on a bad state until that snippet was fixed: the rendered image of other snippets wasn't updated when they were modified, and the last rendered image of the bad snippet would keep being shown. Additionally, if by the time the bad snippet was fixed any other snippets were different from before the bad snippet stopped compiling, those snippets would get re-rendered and their previous image would get stuck on the screen.

This patch fixes this issue: now when a snippet is modified and it stops compiling its rendered image is properly cleared and the rest of the snippets are unaffected.

Before:

bad.mp4

After:

good.mp4

After a long time of debugging i found out that under the situation i mentioned, the module.private.image_api.clear() call in the following for loop was silently erroring out, which lead to the images not being properly cleared (since only the local copy of the images table was partly updated, but the original version actually used by the rest of the renderer was never updated with the modified local copy). After using pcall() to get the error from the image_api.clear() call, the actual error was E5560: nvim_buf_is_valid must not be called in a lua loop callback, which according to the stacktrace comes from image.nvim.

I'm not sure why the nio.scheduler() call is needed because it's already called before any of this code runs (right before the renderer is called) and it's weird that it's only needed in this specific case, but through trial and error it seems to be needed again after the call to module.required["core.integrations.treesitter"].execute_query() (right before where it's currently at) to avoid the error

@vhyrro
Copy link
Member

vhyrro commented Jun 24, 2024

Thank you!

@vhyrro vhyrro merged commit 7fc91bb into nvim-neorg:main Jun 24, 2024
6 checks passed
@ALVAROPING1 ALVAROPING1 deleted the fix-renderer branch June 24, 2024 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants