You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feature: Reveal text in operator-pending mode, and when jumping with flash.nvim (or similar plugins) #43
Is your feature request related to a problem? Please describe.
When manipulating textobjects, I would like the text revealed so that I could better see what's going on.
Describe the solution you'd like
The solution is to reveal text during operator-pending mode.
I'm also unsure if plugins like flash.nvim make use of the operator-pending mode, so if they don't, this plugin should also allow to reveal text when using jump mode or enhanced f/t motions.
Describe alternatives you've considered
The alternative is just disabling the concealment.
As far as interacting with the various navigation helper plugins, I personally don't use them and don't particularly want to try out all the options so will let users bring up any poor behaviors and go from there.
Yes. Lazy shows the markdown.nvim commit to be 467ad24.
I found out the issue occurs when I run require("which-key").register(). If I comment that out, it works, but I would rather not since which-key is integral to my workflow (and many other users).
Not sure if it's a timing issue, or interruption issue, or a which-key bug, or what, but you may need to investigate that since a lot of users use which-key as a foundation for their config.
Edit: Both markdown.nvim's reveal (if it worked) and which-key's popup would occur roughly at the same time so I'm assume the bug stems from there. My guess is that it accidentally grabs the mode of the which-key popup instead of the main buffer? Or maybe it applies the reveal on the which-key popup instead of the main buffer?
Ah I also use which-key, but have most of the presets disabled. In this case the operators preset is what causes the behavior.
I'm seeing that with operators enabled which-key prevents the mode change from happening at all. As in it forces the editor to stay in normal mode. Which kind of makes sense, but that means with which-key the operator pending state doesn't exist.
I don't think there's really anything to do. I can't infer an event that's not being triggered, will make a note of this somewhere though.
even though render-markdown is place first, flash.nvim still grey out the screen without the unconcealment. Only when i press the first key does it unconceal. But when I tried replacing require("render-markdown").buf_toggle() with another command, that command executes first like normal.
Activity
MeanderingProgrammer commentedon Jun 27, 2024
Hi, thanks for the feedback! I agree not rendering during operator pending mode makes a lot of sense.
Have pushed a change: 467ad24, lmk if it works as expected.
Disabling concealing is also possible if you want to do that for any reason in the future:
As far as interacting with the various navigation helper plugins, I personally don't use them and don't particularly want to try out all the options so will let users bring up any poor behaviors and go from there.
Thanks again!
oblitzitate commentedon Jun 27, 2024
Still not working for me. No changes when I enter an operator (e.g.
d) as the initial keystroke.My current config:
{1 "MeanderingProgrammer/markdown.nvim" :name "render-markdown" :dependencies ["nvim-treesitter/nvim-treesitter" "nvim-tree/nvim-web-devicons"] :opts {:headings [ " " " " " " " " " " " "]}}MeanderingProgrammer commentedon Jun 27, 2024
I gotta ask, did you update the plugin?
oblitzitate commentedon Jun 27, 2024
Yes. Lazy shows the markdown.nvim commit to be
467ad24.I found out the issue occurs when I run
require("which-key").register(). If I comment that out, it works, but I would rather not sincewhich-keyis integral to my workflow (and many other users).Not sure if it's a timing issue, or interruption issue, or a which-key bug, or what, but you may need to investigate that since a lot of users use which-key as a foundation for their config.
Edit: Both markdown.nvim's reveal (if it worked) and which-key's popup would occur roughly at the same time so I'm assume the bug stems from there. My guess is that it accidentally grabs the mode of the which-key popup instead of the main buffer? Or maybe it applies the reveal on the which-key popup instead of the main buffer?
MeanderingProgrammer commentedon Jun 27, 2024
Ah I also use which-key, but have most of the presets disabled. In this case the
operatorspreset is what causes the behavior.I'm seeing that with
operatorsenabled which-key prevents the mode change from happening at all. As in it forces the editor to stay in normal mode. Which kind of makes sense, but that means with which-key the operator pending state doesn't exist.I don't think there's really anything to do. I can't infer an event that's not being triggered, will make a note of this somewhere though.
Found an issue on which-key's side, it's expected behavior: folke/which-key.nvim#534.
khangnm1340 commentedon Mar 21, 2025
buf_toggle()happens after flash.nvim even when placed first .I have this key map
even though render-markdown is place first, flash.nvim still grey out the screen without the unconcealment. Only when i press the first key does it unconceal. But when I tried replacing
require("render-markdown").buf_toggle()with another command, that command executes first like normal.output.mp4