New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Background color for inactive windows / per window #5302

Closed
blueyed opened this Issue Sep 6, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@blueyed
Contributor

blueyed commented Sep 6, 2016

What do you think about having a highlighting group for inactive windows?

I have created a plugin based on a hack, which uses &cursorcolumn (https://github.com/blueyed/vim-diminactive/), and also asked for it in Vim a while ago (vim/vim#325) without any feedback.

I am experiencing some issues myself with the plugin from time to time, probably because of other plugins over-using :noautocmd when going back and forth between windows.

Wouldn't it be rather trivial to support this in Neovim/Vim directly: just have a different background for non-current windows?!

In a perfect world this would also apply the "current" style to any location list for the current window.
Not sure about quickfix lists in this regard. Maybe there should be a way to always not dim them (i.e. not apply the non-active background to them)?

@mudox

This comment has been minimized.

Show comment
Hide comment
@mudox

mudox Sep 6, 2016

I've always been thinking about this, why not step further, let [n]vim maintains separate syntax/color scheme data info per window.

Then we can, for example, edit a python buffer in one window applying a color scheme that is best for python language, and edit a c buffer in another window applying a different color scheme that is best for c language.

mudox commented Sep 6, 2016

I've always been thinking about this, why not step further, let [n]vim maintains separate syntax/color scheme data info per window.

Then we can, for example, edit a python buffer in one window applying a color scheme that is best for python language, and edit a c buffer in another window applying a different color scheme that is best for c language.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Sep 6, 2016

Member

I'd also really like a good way to distinguish the currently active window. Though I'm not sure dimming the background is ideal, but the thing needed here may be useful for other cases.

One might say that window-local highlight groups are needed, but that seems like a mess for little gain. Instead call matchaddpos() could be modified to color cells even if they don't contain text. (I thought that was supposed to be the case already...):

hi Foo ctermbg=red
call matchaddpos('Foo', [line('.')+1, 1, 999])

By the way, since Nvim supports mapping <esc> safely, a nice workaround for finding the currently focused window is to map it to something like this:

justinmk/config@19bb7e5

But again that would work better if non-text could be highlighted by matchaddpos().

Member

justinmk commented Sep 6, 2016

I'd also really like a good way to distinguish the currently active window. Though I'm not sure dimming the background is ideal, but the thing needed here may be useful for other cases.

One might say that window-local highlight groups are needed, but that seems like a mess for little gain. Instead call matchaddpos() could be modified to color cells even if they don't contain text. (I thought that was supposed to be the case already...):

hi Foo ctermbg=red
call matchaddpos('Foo', [line('.')+1, 1, 999])

By the way, since Nvim supports mapping <esc> safely, a nice workaround for finding the currently focused window is to map it to something like this:

justinmk/config@19bb7e5

But again that would work better if non-text could be highlighted by matchaddpos().

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Sep 6, 2016

Member

let [n]vim maintains separate syntax/color scheme data info per window.

How much more useful would that be compared to matchadd()/matchaddpos(), which already support per-window highlighting?

Then we can, for example, edit a python buffer in one window applying a color scheme that is best for python language, and edit a c buffer in another window applying a different color scheme that is best for c language.

You can already assign different colors to the specific syntax groups for C and python. E.g.:

hi pythonFunction ...
hi cUserFunction ...
Member

justinmk commented Sep 6, 2016

let [n]vim maintains separate syntax/color scheme data info per window.

How much more useful would that be compared to matchadd()/matchaddpos(), which already support per-window highlighting?

Then we can, for example, edit a python buffer in one window applying a color scheme that is best for python language, and edit a c buffer in another window applying a different color scheme that is best for c language.

You can already assign different colors to the specific syntax groups for C and python. E.g.:

hi pythonFunction ...
hi cUserFunction ...
@mudox

This comment has been minimized.

Show comment
Hide comment
@mudox

mudox Sep 6, 2016

Different color scheme authors focus on limited range of different languages, they craft their color scheme file often according to their daily use scenario. So I think each color scheme file has its focused one or ones among hundreds existing languages.

Similar to what GitHub did, it gives each language a representative color, each language appears
more distinctive in its own color scheme(s). And [n]vim users may be able to try different color schemes on their multiple working languages.

This feature make [n]vim more versatile on colorization (maybe more colorful) especially on true color environments. Something like this (simulated by tmux panes)

screen shot 2016-09-06 at 12 32 54

However I admit that it is not a urgent or key feature to [n]vim, just a wishlist item.

mudox commented Sep 6, 2016

Different color scheme authors focus on limited range of different languages, they craft their color scheme file often according to their daily use scenario. So I think each color scheme file has its focused one or ones among hundreds existing languages.

Similar to what GitHub did, it gives each language a representative color, each language appears
more distinctive in its own color scheme(s). And [n]vim users may be able to try different color schemes on their multiple working languages.

This feature make [n]vim more versatile on colorization (maybe more colorful) especially on true color environments. Something like this (simulated by tmux panes)

screen shot 2016-09-06 at 12 32 54

However I admit that it is not a urgent or key feature to [n]vim, just a wishlist item.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jul 23, 2017

Member

closed by #6597

Member

justinmk commented Jul 23, 2017

closed by #6597

@justinmk justinmk closed this Jul 23, 2017

@justinmk justinmk modified the milestones: 0.2.1, todo Jul 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment