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

bug: line highlights/signs are not applied until leaving insert mode #315

Closed
hneutr opened this issue Jan 31, 2025 · 7 comments
Closed

bug: line highlights/signs are not applied until leaving insert mode #315

hneutr opened this issue Jan 31, 2025 · 7 comments
Labels
bug Something isn't working

Comments

@hneutr
Copy link

hneutr commented Jan 31, 2025

Neovim version (nvim -v)

0.10.4

Neovim distribution

LazyVim

Operating system

MacOS

Terminal emulator / GUI

kitty

Describe the bug

when, for example, adding a new heading, the highlights/border/signs/etc are not applied until insert mode is left, which is new behavior. The same is true for horizontal rules.

@hneutr hneutr added the bug Something isn't working label Jan 31, 2025
@MeanderingProgrammer
Copy link
Owner

I'm going to need an example as well as your config, this does not happen for me. There are edge cases depending on when the debounce runs and your typing speed but as is this is far too vague.

@hneutr
Copy link
Author

hneutr commented Jan 31, 2025

Hm, I'm going to close this for now as it looks like this behavior isn't present with a minimal config. Apologies!

@hneutr hneutr closed this as completed Jan 31, 2025
@hneutr hneutr reopened this Jan 31, 2025
@hneutr
Copy link
Author

hneutr commented Jan 31, 2025

Okay, not sure if this is or is not a bug on your end of things or on Lazy.nvim's side, but I've figured out how to replicated the bug — it shows up if the configuration in Lazy.nvim has ft = "markdown". Here's a minimal vimrc:

-- Settings
vim.opt.termguicolors = true
vim.opt.cursorline = true
vim.opt.number = true
vim.opt.relativenumber = true

-- lazy.nvim setup
local lazypath = vim.fn.stdpath('data') .. '/lazy/lazy.nvim'
if not vim.uv.fs_stat(lazypath) then
    local lazyrepo = 'https://github.com/folke/lazy.nvim.git'
    vim.fn.system({ 'git', 'clone', '--filter=blob:none', '--branch=stable', lazyrepo, lazypath })
end
vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
    spec = {
        -- Some colorscheme
        {
            "catppuccin/nvim",
            lazy = false,
            name = "catppuccin",
            priority = 1000,
            config = function() vim.cmd.colorscheme("catppuccin") end,
        },

        -- Minimal nvim-treesitter config
        {
            'nvim-treesitter/nvim-treesitter',
            build = ':TSUpdate',
            config = function()
                ---@diagnostic disable-next-line: missing-fields
                require('nvim-treesitter.configs').setup({
                    ensure_installed = { 'markdown', 'markdown_inline', 'latex' },
                    highlight = { enable = true },
                })
            end,
        },
        -- Plugin settings
        {
            'MeanderingProgrammer/render-markdown.nvim',
            dependencies = { 'nvim-treesitter/nvim-treesitter', 'echasnovski/mini.nvim' },
            config = function()
                require('render-markdown').setup({
                    render_modes = true,
                    heading = { border = true },
                })
            end,
            ft = "markdown",
        },
    },
})

To replicate the bug, open a file, type insert "# heading" and you will see that the highlights aren't applied until you leave insert mode. If you remove ft = "markdown" from the above config, highlights will be applied as normal.

@MeanderingProgrammer
Copy link
Owner

I do get the same behavior, thanks for digging into it. Another edge case with lazy loading, wonderful! If you open up another buffer that new buffer will work as expected.

Most likely the bug started from this commit: 1ba6fb7, which was done to handle a problem when lazy loading using vim-plug.

MeanderingProgrammer added a commit that referenced this issue Feb 1, 2025
## Details

Issue: #315

Previously we added a step to attach to the current buffer to handle
`vim-plug` based lazy loading not running for the initial file.

This causes a problem with `lazy.nvim` since the attach function will
run before picking up user configuration values, which will cause the
first buffer to be out of sync from the user configuration.

As a sort of hacky but good enough solution run the lazy load handling
attach calls behind a vim.schedule. This should result in the event
based ones running first and avoid this problem.
@MeanderingProgrammer
Copy link
Owner

Should be fixed by: b9c98ff

@Dupond
Copy link

Dupond commented Feb 1, 2025

I know you don't want to support lazy loading, and I assume it's intended, but just in case it wouldn't be intentional: this commit impacts lazy loading with vim-plug; with this commit, render-markdown is only applied after 5 seconds. However, it's immediately applied if I press j or l keys; but it's never applied if I immediately enter Insert mode.

MeanderingProgrammer added a commit that referenced this issue Feb 2, 2025
## Details

Related issues:

- #309
- #315
- #317

Okay this is getting convoluted to handle the differences in lazy
loading between `lazy.nvim` and `vim-plug`. The issues are as follows:

- `lazy.nvim` & Lazy Loaded: Attempting to attach to current buffer at
  the start will not pickup user configuration (called from plugin
  directory before setup) so may not listen to all needed events. This
  means we should not attach to current buffer and rely on the
  `FileType` auto command.
- `vim-plug` & Lazy Loaded: The initial load swallows the `FileType`
  event for the current buffer (`lazy.nvim` seems to trigger the event)
  so first buffer will be ignored. This means we cannot rely on the
  `FileType` auto command and need to attach to the current buffer.

To fix this we need to be aware of the plugin manager being used so we
can do the right thing, which sucks, but oh well.

The solution expands on our existing logic to hook into `lazy.nvim`
configuration for this plugin. When the user has NOT configured lazy
loading (via filetypes nor commands) we attempt to attach to the current
buffer. This means if they have we will skip attaching and will rely on
the `FileType` event.

This solves the `lazy.nvim` problem of not using the updated user
configuration. This does mean when not lazy loading with `lazy.nvim` we
will attempt to attach to the current buffer. This will initially fail
since the filetype will not be set for the buffer but will succeed for
the buffer later once the `FileType` event is triggered.

For `vim-plug` we don't have any hooks so no matter what it will look
like we are NOT lazy loading. This means we will attempt to attach to
the current buffer fixing the issue of lazy loading with `vim-plug`.

Have also added a check that buffer is valid in the `should_attach`
function. The issue related to this should be fixed from the other
updates but having it in place seems like a good idea in either case.
@MeanderingProgrammer
Copy link
Owner

Should be fixed by: 4645c18

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