[vim/vim] Matching Brace Only Highlights When On Screen (Issue #10942)
Wolfgang E Sanyer
Steps to reproduce
- scroll your screen so only one of a match brace is on-screen
- highlight the brace
- scroll your screen so that both braces are now visible
Expected behaviour
The matching brace should be highlighted when it scrolls into view
Version of Vim
9.0, included patches: 1-135
Environment
Operating System: debian
Terminal: alacritty
TERM: xterm-256color
shell: bash
Logs and stack traces
[](https://asciinema.org/a/4mQltCCgcsfHcmfAdmgoDvoSw)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wolfgang E Sanyer
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
We need to call s:Highlight_Matching_Pair() when WinScrolled is triggered:
diff --git a/runtime/plugin/matchparen.vim b/runtime/plugin/matchparen.vim index cc4f38f66..6d4c8d807 100644 --- a/runtime/plugin/matchparen.vim +++ b/runtime/plugin/matchparen.vim @@ -20,7 +20,7 @@ endif augroup matchparen " Replace all matchparen autocommands - autocmd! CursorMoved,CursorMovedI,WinEnter * call s:Highlight_Matching_Pair() + autocmd! CursorMoved,CursorMovedI,WinEnter,WinScrolled * call s:Highlight_Matching_Pair() autocmd! WinLeave * call s:Remove_Matches() if exists('##TextChanged') autocmd! TextChanged,TextChangedI * call s:Highlight_Matching_Pair()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Right, WinScrolled was added at some point, we can now use it, as @lacygoill suggested.
The check for CursorMoved can be removed, autocommands are now always available.
Will be in the next runtime files update.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #10942 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
I still use my Vim9 refactoring, which includes the previous patch, removes the check for CursorMoved, and fixes various other issues. The PR #7985 was closed automatically when I deleted my fork (I didn't know how to fix the merge conflicts).
I could open a new PR. Although, I regularly find issues because of it. For example:
- internal error when searching for pattern after adding text property
- cursor in wrong position when removing text property on CursorMoved
- cursor drawn in wrong position when removing text property
Not because of type errors, nor because of syntactical or logical errors, but because it uses text properties which – I guess – are less well-tested than regular matches (which the current matchparen plugin uses instead).
So, not sure it would be a good idea after all.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Wolfgang E Sanyer
Will be in the next runtime files update
Can you link to a PR or commit that resolves this?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
It hasn't been commited yet.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wolfgang E Sanyer
This usually means it hasn't been commited yet.
Gotcha.
Can we keep the issue open until it has?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
Can we keep the issue open until it has?
Usually, once a patch has been found for an issue in the runtime files, the report is closed (but not always).
If you need an immediate fix, try this:
$ mkdir -p ~/.vim/plugin/
$ vim ~/.vim/plugin/matchparen.vim
:% delete _
:0 read $VIMRUNTIME/plugin/matchparen.vim
:/WinEnter/ substitute/WinEnter/WinEnter,WinScrolled/
:wq
If you want to be notified once the next update of the runtime files occur, you can subscribe to this Atom feed via an RSS/Atom feed reader (e.g. newsboat).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wolfgang E Sanyer
Usually, once a patch has been found for an issue in the runtime files, the report is closed (but not always).
Can you help me understand what these "runtime" files are? How are they distributed?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
The runtime files are here.
They contain various files which are not strictly necessary for Vim to start working, but provide enhancements at runtime, such as syntax highlighting, indentation scripts, filetype settings, compiler plugins, color schemes, built-in help, ...
Each script can be maintained by an independent person, a maintainer, whose name should appear at the top of the relevant file. For example, in the case of the Python syntax script:
" Maintainer: Zvezdan Petkovic <zpet...@acm.org>
Periodically, the maintainers send their changes as a patch to the devs who then merge them in a patch titled "Update runtime files". The last one occurred 3 days ago.
In the case of your issue, the problematic plugin is the matchparen plugin, which is implemented here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wolfgang E Sanyer
They contain various files which are not strictly necessary for Vim to start working, but provide enhancements at runtime, such as syntax highlighting, indentation scripts, filetype settings, compiler plugins, color schemes, built-in help, ...
This makes sense, thank you for the detailed explanation
I guess the part I'm still confused about is the earlier comment:
Usually, once a patch has been found for an issue in the runtime files, the report is closed (but not always).
This seems counterintuitive. It looks like the runtime files are indeed part of the vim distribution itself, so why does it make sense to close the issue before the fix has been committed to the repository? Is this just a convention that is used in this project?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
This seems counterintuitive. It looks like the runtime files are indeed part of the vim distribution itself, so why does it make sense to close the issue before the fix has been committed to the repository? Is this just a convention that is used in this project?
This is just the way it is handled here. I guess this is a reminder for Bram, that his copy of the runtime files already includes the change.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.