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

gruvbox_256palette.sh gets reset (gnome-terminal on Ubuntu) #13

Closed
blueyed opened this issue Dec 4, 2013 · 18 comments
Closed

gruvbox_256palette.sh gets reset (gnome-terminal on Ubuntu) #13

blueyed opened this issue Dec 4, 2013 · 18 comments

Comments

@blueyed
Copy link
Contributor

blueyed commented Dec 4, 2013

I am using gnome-terminal on Ubuntu and noticed, that the effect of gruvbox_256palette.sh gets reset on Alt-Tab or when clicking the terminal window title.

Before (with gruvbox_256palette.sh applied):
vi - zshrc _009

After:
vi - zshrc _008

I get re-execute gruvbox_256palette.sh (after exiting Vim) to fix it, but since this effect is triggered on Alt-Tab already, it's hard to work around.

This affects both the dark and light schemes.

I think a fix for this might be to have a real palette for gnome-terminal?

Something like the following might do for installation: https://github.com/sigurdga/gnome-terminal-colors-solarized

For what it's worth: Konsole does not re-act on gruvbox_256palette.sh altogether, and xterm is unaffected by this reset-bug.

@morhetz
Copy link
Owner

morhetz commented Dec 4, 2013

@blueyed
Hm, so it seems there are to different issues:

  1. Gnome Terminal resets colors set by script.
  2. Color script doesn't affect Konsole at all.

I'll try to check gnome-term reset-bug later today. Could you please specify your *buntu and gnome-term versions?
I'm pretty sure, I've tested that stuff on Ubuntu VM couple months ago and everything was ok. Gimmie some time to investigate what came wrong. It would be easier to fix if it's gnome-term problem and not mine :)

Speaking of so called "real-palette" as quick fix, you definitly could set g:gruvbox_termcolors=16 instead of 256 and change gnome-term's colorscheme to match gruvbox colors as it was specified at #4. I don't really like that solution since it forces you to change your term colorscheme, while with color-script you might have gruvbox colors at vim and solarized (or any else) at term.

And about Konsole.. don't want to sound rude but who's still using that? Anyway I'll check this too, but it's probably a real Konsole bug.

@blueyed
Copy link
Contributor Author

blueyed commented Dec 4, 2013

@morhetz
This is gnome-terminal 3.6.1-0ubuntu6 on Ubuntu 13.10 (latest). I could imagine that it may even be related to Unity (the window manager), since Alt-Tab or moving the window triggers it.

Konsole is quite nice actually, and I have considered using it instead of gnome-terminal again recently, but then it had problems with the Ubuntu font and unicode characters in the prompt.

Would be interesting, if @krzkrzkrz can reproduce this issue (since he uses the theme also on Ubuntu, probably with gnome-terminal)?!

@morhetz
Copy link
Owner

morhetz commented Dec 4, 2013

@blueyed
Well, I was wrong about "couple months". Seems like it's known bug.

You could run script from vim with :! ~/path/gruvbox_256palette.sh and even bind it to some hotkey. But you should press enter to return to vim from script each time you run it. If you stuck with gnome-term and don't want to use any other else terminal the least disturbing way would be using 16 colors scheme. I've never issued such problems since only terms i use is urxvt and lilyterm.

@blueyed
Copy link
Contributor Author

blueyed commented Dec 4, 2013

@morhetz
Thanks for having looked into it!

I had tried to run the script from Vim before, and had the impression that it did not work (but it does - at least).

Would be nice, if the FocusGained autocommand worked with gnome-terminal..

I had been using urxvt before, and will take a look at lilyterm.

@morhetz
Copy link
Owner

morhetz commented Dec 5, 2013

@blueyed
Well, neither FocusGained nor FocusLost works for gnome-term.

@blueyed
Copy link
Contributor Author

blueyed commented Dec 5, 2013

I have now tried lilyterm, and it is affected by the same issue. (it appears to be quite nice otherwise though)

urxvt is not affected, but lacks too much in usability for me (needs setup via .Xresources, no menu/profiles, ..)

@morhetz
Copy link
Owner

morhetz commented Dec 5, 2013

@blueyed
Wow, that's weird. I had no problem with lilyterm on debian sid, but seems like it's reseting colors on ubuntu just as gnome-term. Things getting more weird as sakura terminal (which is libvte based too) doesn't have such reset-bug.
Probably need to test more globaly if it's ubuntu-only problem or not. For what I can say, it's not Unity problem as switching to openbox haven't fixed this. Could it be something with ubuntu-specific modifications (like libvte-ubuntu) or not I'm not sure.
And Konsole should handle color-script though I've noticed awful redraw issues with it on Ubuntu 13.10 (which is not related to color-script). For this term you could also try using osx version of script as it has different escape code (I suppose Konsole is handling x1b).

@morhetz
Copy link
Owner

morhetz commented Dec 5, 2013

@blueyed
Just noticed that lilyterm works ok if you set 'Dim text when inactive' option off. Don't forget to save settings.
Still haven't found similar option for gnome-term

@blueyed
Copy link
Contributor Author

blueyed commented Dec 5, 2013

@morhetz
Great, that works!
Thanks for your help and the recommendation on lilyterm. It is a pity that it's not available in Debian/Ubuntu by default though.

@morhetz
Copy link
Owner

morhetz commented Dec 5, 2013

@blueyed
If you want you could also check other libvte-based terms like sakura, roxterm, terminator, etc. Most of them are in default packages already. That's just me prefering lilyterm.

@blueyed
Copy link
Contributor Author

blueyed commented Dec 5, 2013

@morhetz
terminator is nice, but also affected by this bug

@blueyed
Copy link
Contributor Author

blueyed commented Dec 7, 2013

I have investigated further and it appears, that it is caused by the GTK theme being used (Ubuntu's default Ambiance)! Radiance is also affected.

I have now switched to another theme (Numix), which is not affected.

It seems like the gtk theme engine itself might be bugged in this regard somewhere, and the Ubuntu themes trigger it, while others do not: because switching themes triggers it always.

@morhetz
Copy link
Owner

morhetz commented Dec 8, 2013

@blueyed
Oh, that's great news, nice to hear. I'm making solid documentation update currently and I'll probably close this issue as the changes would be pushed.

@blueyed
Copy link
Contributor Author

blueyed commented Dec 10, 2013

For the record: the Numix GTK theme fixes it for gnome-terminal, but Terminator and LilyTerm are still affected.

@kursion
Copy link

kursion commented Feb 26, 2015

Wouah ! Finally !

I was struggling with this bug since multiple hours now. I'm using Terminator (archlinux, i3wm). I had the exact same bug. Finally I change my color palette to "Solarized" in the preference menu.

Now it works like a charm :) 👍

More details: add the source line to your .zshrc or .bashrc. Change the color palette to Solarized and voila ! Don't forget to reload the terminal !

@morhetz
Copy link
Owner

morhetz commented Feb 26, 2015

@kursion That's the weirdest thing I've ever heard. I don't know how terminal colorscheme could be related to script color reset. For sure I should check if this works for my setup and put this tip to the wiki. Thank you.

@kursion
Copy link

kursion commented Feb 27, 2015

@morhetz Yes... there is no sense to do that for me too. I was out of solution and trying random things to fix this issue. Well on my side I can confirm that it's working. The bug disappeared with that colorscheme :/

@vegarab
Copy link

vegarab commented Oct 25, 2017

Still have this issue. Ubuntu 16.04, i3-gaps, Terminator 0.98...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants