Skip to content
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

Universal monochrome theme #26

Open
neutaaaaan opened this issue Jul 18, 2020 · 10 comments
Open

Universal monochrome theme #26

neutaaaaan opened this issue Jul 18, 2020 · 10 comments
Labels
v:colorblind Is colorblind-friendly v:dark background Has a dark background v:high contrast Has a high contrast v:light background Has a light background v:true colors Supports true colors terminal emulators v:tui Supports TUI Vim v:16 colors Supports 16color terminal emulators v:88 colors Supports 88color terminal emulators v:256 colors Supports 256color terminal emulators

Comments

@neutaaaaan
Copy link
Collaborator

This is a copy of this post

I've worked a bit on that pure monochrome theme that would allow people to ignore a broken environment, and keep :syntax on without having to resort to setting t_Co=0 which quite frankly is the visual equivalent of vogon poetry.

Not defining anything but bold/underline/reverse and letting vim use your terminal foreground and background colors works just fine.

I'm relatively satisfied with what I've put together, although my own preference is to only highlight things that I feel I want to know, rather than try to be complete. There is some annoying overlap here and there, but it's fairly minimal.

mono

vimdiff

The implementation itself is really nothing fancy, I've attached a version I hacked on top of another one of my themes if anyone feels like playing around with it.

None.zip

@romainl
Copy link
Collaborator

romainl commented Jul 18, 2020

Thanks.

From the top of my head:

  • I like it, it is very close to where I want bruin to go when I have time to iterate (it is too "rich", right now),

  • the active and inactive status lines are not easily distinguishable, I would suggest making one underlined (possibly the inactive one),

  • I think the UI should be treated with more consistency, like… the current tab and the current window looking the same, etc.,

  • some highlight groups are in a bizarre state where they inherit the messy default colors:

    Identifier     xxx term=underline ctermfg=6 guifg=DarkCyan
    Statement      xxx term=bold ctermfg=130 gui=bold guifg=Brown
    PreProc        xxx term=underline ctermfg=5 guifg=#6a0dad
    

@romainl romainl added v:16 colors Supports 16color terminal emulators v:256 colors Supports 256color terminal emulators v:88 colors Supports 88color terminal emulators v:colorblind Is colorblind-friendly v:dark background Has a dark background v:high contrast Has a high contrast v:light background Has a light background v:true colors Supports true colors terminal emulators v:tui Supports TUI Vim labels Jul 18, 2020
@neutaaaaan
Copy link
Collaborator Author

the active and inactive status lines are not easily distinguishable, I would suggest making one underlined (possibly the inactive one),

I used to do that, but I'd often lose the inactive one below a fold, or a particularly dense line. reverse is consistent, and doesn't happen often outside of diffs.

I think the UI should be treated with more consistency, like… the current tab and the current window looking the same, etc.,

TabLineSel term=bold,reverse ought to do the trick. There are probably a handful more elements that I never get to see within my own workflow that need to be tweaked.

The generated file is messy, I expect it'll be rewritten from scratch if we make it past the bikeshedding stage.

@neutaaaaan
Copy link
Collaborator Author

Slightly updated version, with changes to how StatusLineNC and Tabs are handled.
Can't shake the bizarre way groups inherit the default vim colours.

None.zip

@habamax
Copy link
Collaborator

habamax commented Aug 16, 2020

Win Terminal:

image

GUI:
image

Is there a way I can make it consistently either white or black for both? Should I do autocmd Colorscheme and set Normal fg and bg?

@neutaaaaan
Copy link
Collaborator Author

If you're talking about the way the windows terminal uses different colours for bold characters, that's precisely what I'd hoped to avoid by only relying on foreground/background, and all of my testing in xterm, urxvt and gnome-terminal came back fine.
There's not fixing that without messing about with your local config.

If you mean you'd like to bolt the colours down, you'd have to explicitely set everything -- the inheritance chain can be downright bizarre at times -- and then you'd be pretty much guaranteed to run into problems specific to the local environment, such as the brighter bold colours, or bizarre colour combinations.
I don't see any point in shipping that, the neutral version is virtually guaranteed to work fine, and one of the very few things that can be reasonably expected is that the user will have control over their terminal emulator.
On the other hand, you might be interested by one of these colourschemes.

@habamax
Copy link
Collaborator

habamax commented Aug 17, 2020

@neutaaaaan all vim shipped colorschemes are either dark or light no matter if I use them in terminal or GUI with the exception of default. (correct me if I am wrong).

The question was whether this one is dark or light? Or is it "default-like" that depends on background of a host (GUI white, terminal whatever is there)?

@neutaaaaan
Copy link
Collaborator Author

Or is it "default-like" that depends on background of a host (GUI white, terminal whatever is there)?

That's it. What it's set to effectively doesn't matter, the host process will force its own foreground/background regardless.

@lifepillar
Copy link
Contributor

IMO, something like this should definitely be included, but sticking to pure monochrome in capable terminals and GUI seems a bit extreme to me. Are there any reasons for that? I'd prefer a color scheme that degrades gracefully:

  • GUI/256/88 colors are available: use shades of gray;
  • 16 colors: use ANSI 0, 7, 8, and 15;
  • 8 colors: use ANSI 0 and 7;
  • less colors: just set term attributes.

If, on the other hand, there are reasons to prefer pure monochrome everywhere, then the color scheme could be simplified. @neutaaaaan Could you make your template available, so we can experiment with this color scheme?

As I mentioned in #33, this color scheme could be used as a fallback by other color schemes when the environment does not have enough colors. That is, the other color schemes might be structured as follows:

if <has GUI or at least 256 colors>
  " Color scheme definitions
else " Fallback
  let g:colors_fallback = 1
  source $VIMRUNTIME/colors/none.vim
endif

The colors_fallback flag could be used by None to detect whether it's been selected by the user or invoked as a fallback, and act accordingly (e.g., not reset g:colors_name when used as a fallback).

Then, all other color schemes should only define GUI and xterm colors.

@lifepillar
Copy link
Contributor

There's a caveat to the above: many (most?) Vim's color schemes use ANSI colors. While for new color schemes the approach I have mentioned is not an issue, it would break backward compatibility.

@neutaaaaan
Copy link
Collaborator Author

@lifepillar It's a catch-all solution for people working in busted environments that they don't have the privileges or the know-how to fix. It's overkill on purpose, as the only assumption is that foreground/background are legible.

The template is derived from one of my other themes, beware of the cruft :
None.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v:colorblind Is colorblind-friendly v:dark background Has a dark background v:high contrast Has a high contrast v:light background Has a light background v:true colors Supports true colors terminal emulators v:tui Supports TUI Vim v:16 colors Supports 16color terminal emulators v:88 colors Supports 88color terminal emulators v:256 colors Supports 256color terminal emulators
Projects
None yet
Development

No branches or pull requests

4 participants