bug: Mark updates take too long

[tristan-harris]

Neovim version (nvim -v)

0.10.1

Operating system

Arch Linux

Terminal emulator / GUI

Alacritty

Describe the bug

There is a noticeable delay between moving the cursor off a line and the marks on that line being updated. This can be solved by setting debounce = 0, but should not be necessary given that the default is only 100 milliseconds.

https://github.com/user-attachments/assets/800201fc-56f6-4d1e-bd79-10f086b6b955

Expected behavior

The marks on a line update near instantly when the cursor is move elsewhere.

Healthcheck output

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

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

markdown.nvim [configuration] ~
- OK valid

markdown.nvim [nvim-treesitter] ~
- OK installed
- OK markdown: parser installed
- OK markdown: highlight enabled
- OK markdown_inline: parser installed
- OK markdown_inline: highlight enabled

markdown.nvim [executables] ~
- OK none to check

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

Plugin configuration

return {
    'MeanderingProgrammer/markdown.nvim',
    -- dev = true,
    ft = { 'markdown', 'md' },
    name = 'render-markdown', -- Only needed if you have another plugin named markdown.nvim
    dependencies = { 'nvim-treesitter/nvim-treesitter', 'nvim-tree/nvim-web-devicons' },
    opts = {
        latex = { enabled = false },
        heading = {
            icons = { '󰎤 ', '󰎧 ', '󰎪 ', '󰎭 ', '󰎱 ', '󰎳 ' },
            signs = {},
            backgrounds = { 'DiffAdd', 'DiffChange' }
        },
        code = { style = 'normal' },
        dash = { icon = '━' }, -- https://www.w3.org/TR/xml-entity-names/025.html
    }
}

Confirmations

• [X] I have provided markdown text for any screenshots used in my description & understand that my issue will be closed if I have not

Additional information

Markdown text used in recording.

# Editor Commands

### Read/Write

- `:x`/`:xit`               -> To save and quit (equivalent of `:wq`).
- `:w`/`:write`             -> To write to a specified file.
- `:wqa`/`:wqall`           -> Write all changed buffers then quit.
- `:up`/`:update`           -> Like `:w` but only writes when buffer has been modified.
- `:n`/`:new`               -> Open file in new window in nvim.
- `:e`/`:edit`              -> Open file in nvim. Without arguments it reloads current buffer.
- `:edit!`                -> Discard unsaved changes in the current buffer.
- `:sav`/`:saveas`          -> Save to a specific file.
- `:r`/`:read`              -> Read contents of file into buffer (can be `stdout`).
- `:so`/`:source`           -> Read contents of file as series of commands.

- `:mes`/`:messages`        -> View previous messages.

---

[MeanderingProgrammer]

This is a side effect of what a debounce means and differences in user behavior will make the lag better or worse.

A debounce means run this function if at least n milliseconds have passed since the last run. So repeatedly triggering the function will skip most executions. There's a neat doc that goes over different techniques: https://gist.github.com/runiq/31aa5c4bf00f8e0843cd267880117201#debouncing-on-the-leading-edge.

So a debounce of 100 milliseconds will update the marks in the view port and any events that occurs faster than 100 milliseconds get ignored. Moving down by holding j is going to be one of the worst cases since those events occur at nearly the same time. So the update only happens after j stops being held and the CursorHold event triggers.

I think I can do something to improve this by treating movements differently from text changes, and skip the debounce if we don't need to parse the document.

[MeanderingProgrammer]

I've pushed a change to avoid debounce / parsing on cursor movements, should improve the lag: https://github.com/MeanderingProgrammer/markdown.nvim/commit/6bb1d43c9e360929d4497a0459084b062bfe9de5.

LMK if it works better after the update!

[tristan-harris]

Wow, fastest developer on Github! Everything works great.

Now I can happily continue spamming h/j instead of learning proper Vim motions 😃.