feat: listchars only in visual mode #18167
Conversation
Problem: Listchars aintain their SpecialKey highlighting when within a visual selection, unlike regular text which adopts Visual highlighting. Solution: Remove attr_pri restriction in attribute combination logic to allow listchars display in visual mode, combining extra_attr with existing char_attr when visual selection is active.
This comment was marked as off-topic.
This comment was marked as off-topic.
glepnir
changed the title
|
Yes. The previous change altered the merge priority. The original issue has been updated to request supporting listchars only when in Visual mode. Currently, a new option visuallist has been added (a better name would be welcome) that shows the selected area's listchars only when in Visual mode, using the |
This will complicate the size computation of TABs and the cursor positioning on TABs, as they depend on whether |
|
your reply was so fast that I hadn’t refreshed the page yet. Wouldn’t it be enough to just control a variable and attribute for whether to render listchars? No other calculations need to be changed. |
No. Because
So if you change whether |
That is what I was thinking looking at the updated docs here in PR. What would happen to those partial tabs in blockwise selection? |
|
Thanks. I’ll try these cases .. |
|
Isn't this something that could be achieved using a ModeChanged autocommand? |
5 participants
Problem: Listchars aintain their SpecialKey highlighting when within a visual selection, unlike regular text which adopts Visual highlighting.
Solution: Remove attr_pri restriction in attribute combination logic to allow listchars display in visual mode, combining extra_attr with existing char_attr when visual selection is active.
relate neovim/neovim#34189