[vim/vim] Make fillchars a local setting (#5206)

Consus

unread,

Nov 10, 2019, 4:38:55 AM11/10/19

to vim/vim, Subscribed

Is your feature request related something that is currently hard to do? Please describe.

It would be great to make fillchars a local setting to make it possible for plugins like https://github.com/liuchengxu/vista.vim to declare custom folding style via fold.

Describe the solution you'd like

Ability to call setlocal fillchars=... (similar to neovim solution).

Describe alternatives you've considered

Additional buffer-local variables for each setting (stl, stnc, vert, fold and diff).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Christian Brabandt

unread,

Dec 13, 2019, 4:26:57 AM12/13/19

to vim/vim, Subscribed

I wonder if it makes sense to have 'fillchars' option being local to a window. That might cause inconsistencies in the display of several window (borders and such) and actually I would even say, a plugin shouldn't mess with my local configured fillchars setting. Either it sets it globally (and then affects all windows) or it just shouldn't modify it at all.

Bram Moolenaar

unread,

Dec 13, 2019, 3:26:10 PM12/13/19

to vim/vim, Subscribed

This is already mentioned in the todo list, but with some question marks:
Should make 'listchars' global-local. Local to window or to buffer?
Probably window.
Add something like 'fillchars' local to window, but allow for specifying a
highlight name. Esp. for the statusline.
And "extends" and "precedes" are also useful without 'list' set. Also in
'fillchars' or another option?

Christian Brabandt

unread,

Dec 15, 2019, 10:37:49 AM12/15/19

to vim/vim, Subscribed

I am not so sure, it is a good idea to make the whole fillchars setting local to window. For one, which windows vert suboption of the fillchar setting will then be used for drawing windows? fold, stl and diff might make sense, not sure (thought it might cause inconsistent display of folds and diff lines), stlnc probably doesn't (again it is not easily possible to guess, for which windows this would be in effect, since other windows could have their own stl suboptions.

For listchars, extends, precedes makes sense yes.

Bram Moolenaar

unread,

Feb 15, 2021, 2:39:13 PM2/15/21

to vim/vim, Subscribed

Closed #5206 via eed9d46.

lacygoill

unread,

Feb 15, 2021, 2:59:41 PM2/15/21

to vim/vim, Subscribed

This todo item is no longer relevant:

Should make 'listchars' global-local. Local to window or to buffer?

Probably window. #5206

Maxim Kim

unread,

Mar 4, 2021, 4:05:18 AM3/4/21

to vim/vim, Subscribed

The topic is about "Make fillchars a local setting" but the closing commit makes 'listchars' global-local...

Gary Johnson

unread,

Mar 4, 2021, 11:26:39 AM3/4/21

to reply+ACY5DGEFZ3DA2RFSPN...@reply.github.com, vim...@googlegroups.com

On 2021-03-04, Maxim Kim wrote:
> The topic is about "Make fillchars a local setting" but the
> closing commit makes 'listchars' global-local...

That's correct. The subject was meant to imply--in few words--that
the setting should be made local in addition to it already being
global. Are you suggesting that 'listchars' be only local, or did
you just misunderstand the subject?

Regards,
Gary

vim-dev ML

unread,

Mar 4, 2021, 11:27:08 AM3/4/21

to vim/vim, vim-dev ML, Your activity

Maxim Kim

unread,

Mar 4, 2021, 11:30:17 AM3/4/21

to vim/vim, vim-dev ML, Comment

Are you suggesting that 'listchars' be only local, or did you just misunderstand the subject?

I mean listchars are not fillchars.

—
You are receiving this because you commented.

Gary Johnson

unread,

Mar 4, 2021, 11:37:33 AM3/4/21

to reply+ACY5DGEVVADUCWVAHA...@reply.github.com, vim...@googlegroups.com

On 2021-03-04, Maxim Kim wrote:

> Are you suggesting that 'listchars' be only local, or did you just
> misunderstand the subject?
>
> I mean listchars are not fillchars.

Oops. I must read more carefully.

Regards,
Gary

vim-dev ML

unread,

Mar 4, 2021, 11:37:57 AM3/4/21

to vim/vim, vim-dev ML, Your activity

K.Takata

unread,

Mar 4, 2021, 6:16:52 PM3/4/21

to vim/vim, vim-dev ML, Comment

Reopened #5206.

—
You are receiving this because you commented.

Bram Moolenaar

unread,

Jul 4, 2022, 12:35:04 PM7/4/22

to vim/vim, vim-dev ML, Comment

Closed #5206 as completed via 96ba25a.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.

Reply all

Reply to author

Forward