Skip to content

bug: Visual effects cleared when markdown files is splitted and scrolled #184

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

Closed
2 tasks done
Bekaboo opened this issue Sep 25, 2024 · 7 comments
Closed
2 tasks done
Labels
bug Something isn't working

Comments

@Bekaboo
Copy link
Contributor

Bekaboo commented Sep 25, 2024

Neovim version (nvim -v)

0.10.0

Neovim distribution

N/A

Operating system

Linux

Terminal emulator / GUI

Alacritty

Describe the bug

When a markdown file is splitted into two windows and one of the window scrolls, the visual effects can be cleared in another window.

Expected behavior

Both windows render normally.

Healthcheck output

render-markdown: require("render-markdown.health").check()

render-markdown.nvim [version] ~
- OK plugin 7.1.11
- OK neovim >= 0.10

render-markdown.nvim [configuration] ~
- ERROR render-markdown.signs: is not a valid key

render-markdown.nvim [nvim-treesitter] ~
- OK installed
- OK markdown: parser installed
- OK markdown: highlight enabled
- OK markdown_inline: parser installed
- OK markdown_inline: highlight enabled
- WARNING latex: parser not installed
  - ADVICE:
    - Disable LaTeX support to avoid this warning by setting { latex = { enabled = false } }

render-markdown.nvim [executables] ~
- WARNING latex2text: not installed
  - ADVICE:
    - Disable LaTeX support to avoid this warning by setting { latex = { enabled = false } }

render-markdown.nvim [conflicts] ~
- OK headlines: not installed
- OK obsidian: not installed

Plugin configuration

require('render-markdown').setup()

Plugin error log

N/A

Confirmations

  • I have updated this plugin to the latest version using my plugin manager
  • I have provided text for all screenshots & understand that my issue will be closed if I have not

Additional information

I believe this is because render-markdown clears "off-screen" extmarks but it only considers visible range of the file in the current window instead of all windows that contain the markdown file.

A video that demonstrate the bug (observe the split on the left):

2024-09-24.23-12-13.mp4
@Bekaboo Bekaboo added the bug Something isn't working label Sep 25, 2024
@MeanderingProgrammer
Copy link
Owner

I'm curious what is the reason to open the same markown file in multiple windows?

@MeanderingProgrammer
Copy link
Owner

Your assumption is correct, we only render within the visible range + some buffer of a file. The range will be determined by the active window.

@Bekaboo
Copy link
Contributor Author

Bekaboo commented Sep 25, 2024

I'm curious what is the reason to open the same markown file in multiple windows?

Taking notes while referencing to the previous section of the note? There are many use cases actually. I often find myself using splits to view different parts of the same file simultaneously to have a grasp of the whole file structure.

@MeanderingProgrammer
Copy link
Owner

Yeah, I do that with code, but I was just wondering when that would happen with markdown. I guess my use of it doesn't often involve looking at different parts, but it sounds reasonable. This one might take some time.

@cideM
Copy link

cideM commented Sep 25, 2024

Just chiming in to say that I split and scroll a lot as well and therefore this issue is quite important to me

MeanderingProgrammer added a commit that referenced this issue Sep 25, 2024
Issue: #184

This plugin optimizes performance for large files by only attempting to
render what is visible in the window + some amount of buffer. This is
likely what users want in most instances however does not account for
the fact that the same file can be open in multiple windows at the same
time. When this occurs and one of the windows is scrolled the other
window will start losing decorations.

To account for this we now iterate through all windows for the current buffer
and collect all visible ranges. These ranges are coalesced based on any
overlaps. This is done in a new `range` module.

Much of the logic in the `context` module needed to be updated to
account for multiple ranges rather than a single top and bottom. This
was fairly easy for most things and involved adding a loop over the ranges.

It was convenient that all the range checking logic was centralized in
the `context` module and did not leak into any of the rendering logic,
so it seems like we have a good abstraction.

Since we went the more complicated route with the implementation
handling multiple ranges the performance impact should be negligible. It
should be none with a single window and as little as possible with
multiple windows since no matter what we will need to do more work to
render more lines.
@MeanderingProgrammer
Copy link
Owner

Turned out not too difficult. I thought the visible range logic might have leaked to multiple places, but nope, fairly contained.

Should work after: 767707e.

@Bekaboo
Copy link
Contributor Author

Bekaboo commented Sep 26, 2024

Thanks! Closing this as fixed.

@Bekaboo Bekaboo closed this as completed Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants