Patch 8.1.1299

[Bram Moolenaar]

Patch 8.1.1299
Problem: "extends" from 'listchars' is used when 'list' is off. (Hiroyuki
Yoshinaga)
Solution: Only use the "extends" character when 'list' is on. (Hirohito
Higashi, closes #4360)
Files: src/screen.c, src/testdir/test_listchars.vim


*** ../vim-8.1.1298/src/screen.c 2019-05-05 15:47:37.825923529 +0200
--- src/screen.c 2019-05-08 20:20:27.436236341 +0200
***************
*** 5594,5601 ****
break;
}

! /* line continues beyond line end */
! if (lcs_ext
&& !wp->w_p_wrap
#ifdef FEAT_DIFF
&& filler_todo <= 0
--- 5594,5603 ----
break;
}

! // Show "extends" character from 'listchars' if beyond the line end and
! // 'list' is set.
! if (lcs_ext != NUL
! && wp->w_p_list
&& !wp->w_p_wrap
#ifdef FEAT_DIFF
&& filler_todo <= 0
*** ../vim-8.1.1298/src/testdir/test_listchars.vim 2019-04-04 13:28:41.201589932 +0200
--- src/testdir/test_listchars.vim 2019-05-08 20:14:19.686543989 +0200
***************
*** 110,115 ****
--- 110,134 ----
call cursor(1, 1)
call assert_equal([expected], ScreenLines(1, virtcol('$')))

+ " test extends
+ normal ggdG
+ set listchars=extends:Z
+ set nowrap
+ set nolist
+ call append(0, [ repeat('A', &columns + 1) ])
+
+ let expected = repeat('A', &columns)
+
+ redraw!
+ call cursor(1, 1)
+ call assert_equal([expected], ScreenLines(1, &columns))
+
+ set list
+ let expected = expected[:-2] . 'Z'
+ redraw!
+ call cursor(1, 1)
+ call assert_equal([expected], ScreenLines(1, &columns))
+
enew!
set listchars& ff&
endfunc
*** ../vim-8.1.1298/src/version.c 2019-05-08 18:36:40.060562551 +0200
--- src/version.c 2019-05-08 20:18:13.965070043 +0200
***************
*** 769,770 ****
--- 769,772 ----
{ /* Add new patch number below this line */
+ /**/
+ 1299,
/**/

--
Living on Earth includes an annual free trip around the Sun.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Antony Scriven]

Hi!

> Solution: Only use the "extends" character when 'list' is on. (Hirohito
> Higashi, closes #4360)

This change may be consistent, but is it helpful?

It seems to me that extends and precedes provide basic UI
feedback akin to a scrollbar or the 'display' option, rather
than displaying special characters differently. I, and one
other I've spoken to, like to know if there is text hidden
off-screen, without having to keep 'list' enabled.

Is anyone else bugged by this change, or does everyone
'wrap' religiously?

Warm regards, --Antony

[Tony Mechelynck]

I wrap, but not religiously, and in particular I don't wrap diffs, and
I set 'list' on because I want to see several of the 'listchars'
options, including a visible end-of-line, visible tabs and visible
no-break spaces. So I also customize 'listchars' in my vimrc.

The way I understand it, and the way it's documented, 'listchars' is
used in two cases:
a) to display ordinary editfile text when 'list' is on
b) to display the output of the :list command.

AFAIR it has been like this since before I started using Vim.

Most of the possible 'listchars' settings have a defaut which means
that, when omitted, that particular setting will default to what Vim
does when 'list' is off, with at least one exception: the hard tab.
When 'list' is off, a hard tab is displayed as one or more spaces
until the next character is at an abscissa which (if the first
position in a line is 1) is one more than a multiple of 'tabstop'.
When 'list' is on and 'listchars' does not include "tab:", a hard tab
is represented by the two characters ^I. To get the default behaviour
with 'list' on (and for instance some other nondefault setting) you
need

:set lcs+=tab:\ \

i.e. two backslash-escaped spaces. (I use tab:\|_ which is stored as
|_ and gives one vertical bar plus zero or more underscores.)

If you want to see precedes and extends, and default the rest, you may use

:set list lcs=tab:\ \ ,extends:>,precedes:<

IIUC this should give you the same behaviour as with 'nolist' except
that long lines will have a < at the left margin and/or a > at the
right margin depending on which part of the line is displayed. Of
course, if you prefer other characters, the choice is unlimited. With
'encodiing' set to utf-8 (and, I suppose, a "scriptencoding utf-8"
statement near the top of your utf8-encoded vimrc), another possible
setting would be

:set list lcs=tab:\ \ ,extends:→,precedes:←

Or you may (like me) go whole hog and use

if exists('+list')
set list
if exists('+listchars')
set lcs=eol:¶,tab:\|_,extends:>,precedes:<,conceal:*,nbsp:·
endif
endif

Best regards,
Tony.

[Gary Johnson]

I agree completely. I wrap or not as the situation warrants.
I rely on the 'extends' character to tell me that text is
off-screen. I also use 'showbreak' to show me that text has wrapped
rather than being on an actual separate line. I don't want the
clutter of the other 'listchars' in most cases.

I think this change is a bad idea altogether, but if someone doesn't
like having 'extends' on all the time, give them an option to turn
it off, or give the rest of us an option to restore the previous
behavior.

Regards,
Gary

[Bram Moolenaar]

> > Solution: Only use the "extends" character when 'list' is on. (Hirohito
> > Higashi, closes #4360)
>
> This change may be consistent, but is it helpful?

It was a bit of a mistake to add these items in 'listchars', we are
correcting that now.

> It seems to me that extends and precedes provide basic UI
> feedback akin to a scrollbar or the 'display' option, rather
> than displaying special characters differently. I, and one
> other I've spoken to, like to know if there is text hidden
> off-screen, without having to keep 'list' enabled.
>
> Is anyone else bugged by this change, or does everyone
> 'wrap' religiously?

The todo list has a brief entry for this:

Add something like 'fillchars' local to window, but allow for
specifying a highlight name. Esp. for the statusline.

So, the reason we didn't quickly add another option to make "extends"
work when 'list' is off, is that we probably want to add some more
functionality at the same time. That is keeping it local to the
window, and being able to specify separate highlighting. This could be
useful for other "filler" characters as well.

--
You have heard the saying that if you put a thousand monkeys in a room with a
thousand typewriters and waited long enough, eventually you would have a room
full of dead monkeys.
(Scott Adams - The Dilbert principle)

[Gary Johnson]

On 2019-05-20, Bram Moolenaar wrote:
> > > Solution: Only use the "extends" character when 'list' is on. (Hirohito
> > > Higashi, closes #4360)
> >
> > This change may be consistent, but is it helpful?
>
> It was a bit of a mistake to add these items in 'listchars', we are
> correcting that now.
>
> > It seems to me that extends and precedes provide basic UI
> > feedback akin to a scrollbar or the 'display' option, rather
> > than displaying special characters differently. I, and one
> > other I've spoken to, like to know if there is text hidden
> > off-screen, without having to keep 'list' enabled.
> >
> > Is anyone else bugged by this change, or does everyone
> > 'wrap' religiously?
>
> The todo list has a brief entry for this:
>
> Add something like 'fillchars' local to window, but allow for
> specifying a highlight name. Esp. for the statusline.
>
> So, the reason we didn't quickly add another option to make "extends"
> work when 'list' is off, is that we probably want to add some more
> functionality at the same time. That is keeping it local to the
> window, and being able to specify separate highlighting. This could be
> useful for other "filler" characters as well.

I would like to resolve this.

The most straightforward solution would be an option akin to
'showbreak' that would allow the extends and precedes characters to
be set globally or locally for the current window. However, that
would not address the other issues discussed in todo.txt, such as
window-local status line fill characters, and it sounds like Bram
would prefer one option with a number of optional items rather than
more individual options.

I propose using 'fillchars' for this purpose. The scope would be
changed from "global" to "global or local to window". Two items
would be added, copied from 'listchars':

item default Used for
extends:c '' Character to show in the last
column, when 'wrap' is off and the
line continues beyond the right of
the screen.
precedes:c '' Character to show in the first
column, when 'wrap' is off and there
is text preceding the character
visible in the first column.

Two highlight groups would also be added:

item highlight group
extends:c Extends
precedes:c Precedes

Both highlight groups would be initialized to "links to NonText".

I may not be understanding the comment in todo.txt:

Add something like 'fillchars' local to window, but allow for
specifying a highlight name. Esp. for the statusline.

Does that mean that the user should be able to set a local highlight
group _name_ for each item, and thereby have different item
highlighting in every window? If so, I'll change the proposal
accordingly.

Since it has been decided that 'listchars' applies only when 'list'
is on, I think the values of the 'listchars' extends and precedes
and the values of the 'fillchars' extends and precedes should be
independent. However, I think that if the user has set the value of
the 'fillchars' extends or precedes, then that value should be used
when 'list' is on and the corresponding 'listchars' item has not
been set.

A possible problem with making 'fillchars' global and local to
window is that it doesn't make sense to make the vert item local.
The vert item is a separator between windows, not a property of any
one window. I don't think that inconsistency would bother anyone,
though.

I'm not married to this proposal. My primary interest is in somehow
providing for the use of extends and precedes characters when 'list'
is off, as before this patch, without going through the hoops of
backing out the patch or using a plugin to leave 'list' on and
manage 'listchars' when the user sets 'list' to off or on, both of
which I've done.

Please let me know what you think. I have some time on my hands and
I think this would be an interesting and useful project.

Regards,
Gary

[Bram Moolenaar]

This is an essential difference in intention for the 'fillchars' option:
it specifies highlighting to be used in between windows, not inside a
window. Adding "fold" and "diff" here was a mistake, that just happened
because there was no better place to put them.

We should really separate the window-framing, which should be uniform
over the whole Vim window, and what happens inside windows, which can
depend on what is displayed inside that window, and how the user wants
to see that.

> I'm not married to this proposal. My primary interest is in somehow
> providing for the use of extends and precedes characters when 'list'
> is off, as before this patch, without going through the hoops of
> backing out the patch or using a plugin to leave 'list' on and
> manage 'listchars' when the user sets 'list' to off or on, both of
> which I've done.
>
> Please let me know what you think. I have some time on my hands and
> I think this would be an interesting and useful project.

We also have to take into account how the values are set: Once by the
user (in ~/.vimrc), by a filetype plugin or something else? As soon as
a user preference and the plugin both want to change something, we need
to take care of priority. That's not making it any easier.

For an option, it is possible to use += and -= to make changes, but
these days we have other ways to specify highlighting. We also have
'wincolor' to change the basic color of a window. When specifying other
colors in that window, they should be taking that into account. This is
getting closer to having a per-window color scheme.

In general, I think we have been trying to make a minimal change to do
just only what we can think of right now. I'm starting to think that a
better approach is to aim for a big change and see how things fit in
there.

--
DENNIS: Oh, very nice. King, eh! I expect you've got a palace and fine
clothes and courtiers and plenty of food. And how d'you get that? By
exploiting the workers! By hanging on to outdated imperialist dogma
which perpetuates the social and economic differences in our society!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD