Gary Johnson wrote:
> 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.
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
/// Bram Moolenaar -- [email protected] -- 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 ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/202004151536.03FFawCJ030452%40masaka.moolenaar.net.
