[vim/vim] Make listchars extends/precedes, fillchars lastline, and "<<<" consistent (Issue #15134)

21 views
Skip to first unread message

Asheq Imran

unread,
Jul 1, 2024, 6:10:45 PM (2 days ago) Jul 1
to vim/vim, Subscribed

Current Behavior

When wrap is off, the characters used to show that there is text before or after the visible part of the buffer line come from the listchars flags extends:c and precedes:c:

:set nowrap
:set listchars=extends:▷,precedes:◁
:set list
image.png (view on web)

When wrap is on, the character used to show that there is text AFTER the visible part of the buffer line is "@@@" but can be overridden by thefillchars flag lastline. And if smoothscroll is on, the character used to show that there is text BEFORE the visible part of the buffer line is "<<<" and cannot be overriden.

:set nolist
:set wrap
:set display=lastline
:set smoothscroll
image.png (view on web)
:set fillchars=lastline:➤
image.png (view on web)

And if showbreak is not empty, then "<<<" is not displayed.

:set showbreak=➥
image.png (view on web)

And if list is on and listchars includes precedes, then the precedes character is used instead of the showbreak

:set list
image.png (view on web)

Desired Behavior

  • listchars flag precedes should not be used when wrap is on. The same way that extends is not used when wrap is on.
  • The default "@@@" should be ">>>" instead to match the default "<<<" on the other side. The "@@@" can be overridden with a new fillchars flag called firstlineto be the counterpart to the existinglastline` flag.


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134@github.com>

zeertzjq

unread,
Jul 1, 2024, 6:23:53 PM (2 days ago) Jul 1
to vim/vim, Subscribed

  • 'listchars' flag precedes should not be used when 'wrap' is on. The same way that extends is not used when 'wrap' is on.

This is not desirable and not backward-compatible. However if a 'fillchars' firstline flag is added, it may make sense to give it higher priority over 'listchars' precedes flag.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201191700@github.com>

Asheq Imran

unread,
Jul 1, 2024, 6:36:27 PM (2 days ago) Jul 1
to vim/vim, Subscribed

  • 'listchars' flag "precedes" should not be used when 'wrap' is on.

This is not desirable and not backward-compatible. However if a 'fillchars' "firstline" flag is added, it may make sense to give it higher priority over 'listchars' "precedes" flag.

Why is precedes used on the left side of the buffer line, but extends is not used on right side? It appears to be an oversight.

To make things consistent, we can either:

  • Stop using precedes on the left side OR
  • Start using extends on the right side


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201227812@github.com>

zeertzjq

unread,
Jul 1, 2024, 6:48:47 PM (2 days ago) Jul 1
to vim/vim, Subscribed
  • 'listchars' flag "precedes" should not be used when 'wrap' is on.

This is not desirable and not backward-compatible.

Why is precedes used on the left side of the buffer line, but extends is not used on right side? It appears to be an oversight, not something we should intentionally preserve.

It is intentional. Please see patch 8.1.2060.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201280710@github.com>

Asheq Imran

unread,
Jul 1, 2024, 6:51:49 PM (2 days ago) Jul 1
to vim/vim, Subscribed

it may make sense to give it higher priority over 'listchars' "precedes" flag.

The priority chain would get even more odd I think:

  1. default "<<<" (lowest priority)
  2. showbreak
  3. 'listchars' "precedes" flag
  4. 'fillchars' "firstline" flag (highest priority)

If we continue using 'listchars' "precedes", I propose we change the order:

  1. default "<<<" (lowest priority)
  2. 'listchars' "precedes" flag
  3. 'fillchars' "firstline" flag
  4. showbreak (highest priority)

If we stop using 'listchars' "precedes", it would be:

  1. default "<<<" (lowest priority)
  2. 'fillchars' "firstline" flag
  3. showbreak (highest priority)


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201294040@github.com>

Asheq Imran

unread,
Jul 1, 2024, 6:57:45 PM (2 days ago) Jul 1
to vim/vim, Subscribed

  • 'listchars' flag "precedes" should not be used when 'wrap' is on.

This is not desirable and not backward-compatible.

Why is precedes used on the left side of the buffer line, but extends is not used on right side? It appears to be an oversight, not something we should intentionally preserve.

It is intentional. Please see patch 8.1.2060.

I also see patch 9.0.0758

I just feel that:

  • Either those changes should not have been made OR
  • They should have been accompanied by similar changes for "extends"


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201316371@github.com>

zeertzjq

unread,
Jul 1, 2024, 6:58:07 PM (2 days ago) Jul 1
to vim/vim, Subscribed

The situation with 'showbreak' is a bit different. 'listchars' "precedes" is drawn over 'showbreak', and it doesn't disable 'showbreak' (which can be seen if 'showbreak' contains multiple characters), while 'showbreak' disables the default "<<<". If 'fillchars' "firstline" flag is added, it makes sense for it to draw over 'showbreak' as well.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201317499@github.com>

Asheq Imran

unread,
Jul 1, 2024, 7:08:57 PM (2 days ago) Jul 1
to vim/vim, Subscribed

The situation with 'showbreak' is a bit different. 'listchars' "precedes" is drawn over 'showbreak', and it doesn't disable 'showbreak' (which can be seen if 'showbreak' contains multiple characters), while 'showbreak' disables the default "<<<". If 'fillchars' "firstline" flag is added, it makes sense for it to draw over 'showbreak' as well.

I don't think it makes sense for "precedes" to draw over showbreak characters. It doesn't give the user any more information than what showbreak already does. It just makes the UI more cluttered. That's why I proposed showbreak being the highest priority. If showbreak is non-empty, nothing else needs to be shown.

As far as the proposed fillchars "firstline" goes, I think it should actually have the same priority as the default "<<<". It's simply changing the default character, not adding another entry in the priority list. IOW, if showbreak disables the default "<<<", fillchars "firstline" should not show either. I hope that makes sense.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/15134/2201337428@github.com>

Reply all
Reply to author
Forward
0 new messages