I'm having a hard time trying to get a pure white (background) and black (foreground) text with ruby and curses.
With this code
Curses.init_pair(1,COLOR_BLACK,COLOR_WHITE)
Curses.attron(Curses.color_pair(1))
Curses.stdscr.addstr str
Curses.attroff(Curses.color_pair(1))
I get black text on a grayish background (the bottom three lines in
screenshot)
What could I be doing wrong? I tried switching from iterm2 to mac terminal
still the same.
Most of the terminals which implement "ANSI color" use a more intense foreground color when told to render bold. But there is no corresponding workaround for the background.
However, the majority of these also implement SGR 39 and SGR 49, which reset the foreground and background to its "default" colors. Using that would get your original terminal background (which is likely what you want). That is a feature of ncurses called use_default_colors, which I see is available in ruby.
Using that feature, your example would
call the Curses.use_default_colors method,
not bother (for example) to create a color pair, since the default pair 0 would draw using the terminal's default colors.
other color pairs (1 through the maximum number of pairs) would work just like regular curses.
The example given uses color pair 1. If you were using the default-colors extension, you could initialize Curses with the use_default_colors method. Then, using the default color pair 0, you would see on most terminals the original terminal colors. This method is from the underlying ncurses library irregardless of whether the Ruby package is called "curses" or "ncurses".
Color pair 0 is special (see manpage). It cannot be set to specific colors by your application. As an extension, ncurses provides a way to alter this in a useful way.
Related
I am trying to build a Terminal theme in MacOS. The colors that are actually being displayed are slightly different from the hex colors I am setting. For example:
I am setting the background color to #292D3E here. But when I sample the color from the actual background, it is #24293B.
Why is this happening? It seems to do it with most of the colors. I suspect it has to do with Terminal only being able to use a limited palette? But I'm wondering why it would still allow me to enter it, and why it would still show the pasted value and not change it to the allowed value after I saved it if that were the case.
Is there any way to change the size of the text in shell script ?
I mean dynamically during the execution .
For example I have an image drawn with ASCII code and i want to reduce the size of text .
Now when echo or cat the image it will be shown as the command prompt actual size (the actual font size) .
A couple of comments note that font size/style are under the control of the terminal emulator, and that xterm (and a few others) support escape sequences to change these.
However - almost all terminal emulators (all that you would be likely to encounter) rely upon keeping the characters in a nice row/column grid. All of the characters have the "same" size. If you change the size of the font in xterm, all of the characters on the screen change to the same size. So there is no way to (as OP asks) to reduce the font-size temporarily, e.g., while using ASCII graphics to draw a picture using aalib, etc.
If you want to do something like that, the easiest way to do it is to have the script run its graphics in a separate window, e.g., by splitting it up into one part that starts the window and another script to draw the graphics.
For an alternate via of terminals and fonts, there is always something like 9term (no rows, no columns, no vi).
I'm using Emacs 24.3 under Ubuntu 14.04.1. I'd like to use it both via the GTK interface and the Gnome terminal with emacs -nw. Unfortunately, the colours for any theme that I use appear slightly different in the terminal.
I've set things up so that under Gnome terminal, TERM=xterm-256color. However, I have also customised my terminal colors — "black" is actually #151515, "red" is #DA4939, etc. Emacs seems to get close to displaying the correct colours for each theme, but is never quite correct. The themes I'm using are the deftheme-style of theme.
I don't understand why customising terminal colours should affect this — with TERM=xterm-256color, Emacs should have access to a greater palette than just the usual 16 colours. In the output of list-colors-display, black is listed as #000000 but displayed as #151515; there is, however, a color-16 that is also listed as #000000 and displayed properly. So Emacs is indeed capable of displaying #000000.
On the left is Emacs GTK, which displays the theme colours correctly. On the right is emacs -nw run in Gnome terminal, where all the colours are slightly different from what the theme specifies. The theme I've used for this picture is just an example; this happens with any theme. My full config is on Github.
How can I get Emacs to display the correct theme colours in Gnome terminal without removing my customisation of the terminal palette?
A couple issues:
1) I believe that when you customize the "terminal colours", they overlap the first 16 color entries of the 256-colour palette. So if emacs is telling the terminal to use colors 0-15, they will come out as whatever you have set that colour to actually be in your terminal preferences. It doesn't appear to be affecting you specifically, but it is good to be aware of.
2) For the remaining 256 colors, I believe there are only 256 (maybe 241 if your terminal re-colored the first 16) colors that you may choose from.
Unless you choose your GTK theme colors to match exact colours that are available in the 256 palette, having them be identical is not going to be possible. It looks like your emacs did a pretty good job of selecting the closest available colors of the 256 on its own.
If you want to see what I'm talking about in action, try downloading and running a script such as this show-all-256-colors.py script and running it in your terminal. I would wager that as you change your terminal colours, you'll see the entries 000 through 015 change correspondingly, while the remaining colors are always the same.
printf "\033[1;32;40mGreen text on black background.\033[0m\n"
That is the green, but how can i get light green or other variation of color?
http://pueblo.sourceforge.net/doc/manual/ansi_color_codes.html , are only those color available for gnome-terminal as escape code?
Also how can i get bigger font with ruby?
using the "1" as the first parameter, as you are doing already, that's as "light" a green as you're going to get. this guy's webpage might be helpful: http://www.linuxfocus.org/English/May2004/article335.shtml
testing on urxvt:
[added later] there is a DEC extension for double-sized characters: Printing double-size characters with Ncurses but urxvt doesn't support it, I don't know about Gnome terminal.
With an offset of 90 you can create bright/high contrast colors.
See here for a reference. Wikipedia mentions the bright color range, but doesn't really explain how to use them (if I haven't missed it).
If you combine it with the bold style you can create 4 variations of a color.
Example:
It's a matter of the terminal support. The ansi codes that you list are interpreted by the terminal emulator and those codes are the only available colours (it comes from the days before windows and when 16 colours caused a stir).
If you need more you could consider using a graphical interface to your ruby app such as tk.
You can use an RGB escape code:
printf "\033[38;2;r;g;bmText\033[0m"
or, for background colour:
printf "\033[48;2;r;g;bmText\033[0m"
Just replace r, g, and b with the desired RGB value.
I have been playing with color schemes for terminal VIM and have found something annoyingly frustrating that I have been unable to solve thus far.
I expect the 16 system colors to change. They are obviously configurable. For that reason, I attempted to use the 256-color palette to construct a VIM color scheme that would be the same regardless of the terminal's 16 (configurable) system color palette.
I used only colors from the 256 color palette for everything, including background. However, I noticed that if I open terminals with different background and text colors specified for the terminals, the VIM color schemes appear quite different in the two terminals.
I do not see similar behavior on Ubuntu even when the terminals have different background, foreground, AND system color palettes.
I will happily accept an answer that explains why this happens.
I will be ecstatic if someone can tell me a way around this beyond setting up a specific terminal for each set of color settings I want to use.
By default, ANSI terminals are 16 color devices and the Vim color schemes that work in gvim will not work properly in a terminal.
Some terminals are capable of 88 or 256 colors. You can tell Vim about this by setting t_Co. Of course, 256 colors is still less than full RGB that you have in gvim.
There is a package for vim called CSApprox developed by Matt Wozniski. It lets you use the gvim color schemes with approximate colors.
This is what I use myself.
CSApprox includes a documentation file which explains everything better than I can here.
URL: http://www.vim.org/scripts/script.php?script_id=2390
Good luck.
P.S. about your question However, I noticed that if I open terminals with different background and text colors specified for the terminals, the VIM color schemes appear quite different in the two terminals.
That sounds like the OSX terminal does not separate the color definition from the 256 color xterm palette; i.e. that by manipulating its settings you're messing with the palette or something like that.
Terminals should probably be keeping the 16 color user-configurable stuff separate from the 256 color palette.
Terminal dynamically adjusts some color values to ensure a minimum amount of contrast with the background color. Perhaps that’s what you’re seeing.
Please attach a screenshot showing the two different color schemes. A good script for viewing the available colors is 256colors2.pl.
Please, post screenshots so that we see what you see. It's hard to talk about colors without seeing them or comparing their numerical values.
Well, I'm still on 10.6.8 so I've never enjoyed Terminal.app's ability to display 256 colors.
But, AFAIK, its default 16 colors are not taken from the X11 palette. They are probably hardcoded somewhere and their values are user-configurable anyway. Because of that, I have no idea why changing the default Red value to anything would change the looks of your Vim colorscheme.
However, Terminal.app (like most other terminal emulators) allows you to change the values of Background, Text, Bold, Selection and Cursor. Depending on how your colorschemes are written some of these settings may override parts of your colorscheme, Background, most notably.
I've had my Terminal.app background matching my Vim colorscheme's background for a long while with great results. Well, at least for a 16 color terminal emulator.
The 256 colour mode is still just an indexed palette, the same as the 8 and 16 colour modes. The application simply selects a colour by index from a palette, and it's up to the terminal to decide which colour that will actually be.
That two different terminals happen to pick the same colours for these indexes may just be the fact that within the 216-colour RGB cube there's 6 levels of each component, so the "obvious" natural way to assign those colours would be to pick each from the list (0, 0x33, 0x66, 0x99, 0xcc, 0xff). I'd imagine most terminals will do this, and therefore give the same colours at the same indices.
If two terminals differ it's simply an indication they're using some other method of selecting their actual colours.
If you are using iTerm2 then you may need to change what type of terminal it is reporting.
In your iTerm2 Preferences > Profile > Terminal > Report Terminal Type, set to xterm-256color
In Terminal.app aka Apple Terminal, the colours will change if the background colour is not explicitly set as well.
So with your colour scheme you must set up the default background colour using the Normal colour group, e.g.:
hi Normal ctermfg=188 ctermbg=234
and then you should not see any further changes to colours.
Note: I have only noticed the foreground being affected presumably so that you do not miss any important output ;)