I want to know if it's possible to detect available colors in terminal which vim was called, so I could select different colorschemes for each color situation.
This is different from checking &t_Co variable. Sometimes I open a vim with 8 colors, and can set t_Co=256 to use some colorschemes, but sometimes (Like in Terminal.app in mac), setting this variable doesn't throw an error but the t_Co isn't changed because Terminal.app's color limit is 16.
Fact is: I only know this limit by experience, I would like to know if it's possible to know this value from calling a function (if terminal_supports > 256) or something like that.
Can I do it using just viml functions, or I would need to create some bash scripts and call them from vimrc for example? I would like to have this information in Linux, Mac and Windows (also, using Cygwin).
(If I, for some reason, can't get this information from the system, is there a table or in vim help some information about different terminals and their color capabilities? If so, then I could create a hash table with all terminals and ther colors capabilities.)
Another try: some information is here, if you haven't found it already, including informative link at bottom of the linked page:
256_colors_in_vim
So far as I know Vim gets the t_Co number from termcap. So if you can get value from termcap to accurately reflect max colors supported then you're set. I think that's what the info in linked page does, at least for 256 color terms. . .
Related
I've spent a bunch of time going over my Vim and Tmux configurations lately, trying to refine my workflow and I have come across a (small but annoying) problem that is stumping me. I am currently using OSX, but I have had the same issue with Windows' terminal/powershell.
My issue is that I am unable to change the brown color that appears in the default vim syntax highlighting which is used many of the languages that I write in. The color that I am speaking of can be seen in this vim colortest:
In the default OSX terminal (and in powershell) you can set the ANSI colors via terminal preferences, however, the brown color is not included in the GUI configuration options. This results in some ugly syntax highlighting that does not fit in with my desired color scheme:
My question is, what is the most portable way to change this default color? I would love to be able to do something in my .vimrc that would just work around this ugly color so I don't have to reconfigure colors for any system that I might be on, but I understand this might not be possible. Another route would be changing the syntax highlighting colors, but my investigations into that have so been unfruitful.
Thanks!
Appedix:
Colors selected in OSX profile for screenshots:
Sadly, the default Vim colorscheme is not as tidy as one would hope. In this case, Brown is a bit of a "catchall" name that ends up being interpreted differently in different contexts.
In GUI Vim, Brown refers to the "Brown" in X11's rgb.txt: #A52A2A.
In TUI Vim with &t_Co == 256, you get #af5f00, AKA 130 in the "xterm palette".
In TUI Vim with &t_Co == 16 or &t_Co == 8, you get your terminal palette's "Yellow", AKA 3.
By the looks of it, you seem to be affected by the second case.
While there exist ways to change the so-called "xterm palette" wholesale, you will have a hard time changing that specific color in a straightforward, non-messy way.
What you can do…
Do :set background=dark to force Vim to use a different set of default colors that doesn't include "Brown".
Choose a built-in or third-party colorscheme that doesn't use that specific color.
Override the Statement highlight group as explained in this gist with whatever color you want from the xterm palette.
In Ubuntu gnome-terminal it can be done by doing Ctrl + or Ctrl -
Is there a way to write a python script that when executed would resize the font size of the terminal it is executed from?
I need this in order to display images in terminal with high resolution using timg.
Checking the source (vte and gnome-terminal), looks like there's no way to do this. Other terminals (e.g., xterm) can do this using escape sequences. See XTerm Control Sequences:
OSC Ps ; Pt ST
Set Text Parameters. For colors and font, if Pt is a "?", the
control sequence elicits a response which consists of the con-
trol sequence which would set the corresponding value. The
dtterm control sequences allow you to determine the icon name
and window title.
...
Ps = 5 0 -> Set Font to Pt. These controls may be disabled
using the allowFontOps resource. If Pt begins with a "#",
index in the font menu, relative (if the next character is a
plus or minus sign) or absolute. A number is expected but not
required after the sign (the default is the current entry for
relative, zero for absolute indexing).
vte recognizes the 50, but that (like a lot of other xterm features) is just a stub that doesn't do anything. The xterm sources include a 20-year old script which demonstrates the feature (see fonts.sh).
Rather than using an escape sequence, you might be able to use the wmctrl tool (which could ask the window manager to negotiate with the terminal). Some have done that with other terminals, e.g, terminology (but ultimately using an escape sequence).
vte does have some code which might be accessible from a python script, using g_signal_connect to associate decrease-font-size and increase-font-size signal (see source code). The signal code is what you're using with the keyboard. But how you might determine the object pointer from a script starting outside the terminal emulator isn't clear.
There is no easy way to do this across terminals. Terminals support so called control sequences, which can set a bunch of options, like text color and others, but there is no control sequence for setting the font size. See for example https://en.wikipedia.org/wiki/ANSI_escape_code and https://invisible-island.net/xterm/ctlseqs/ctlseqs.html for what kind of actions are supported.
For reference purposes: I am using a Macbook Pro Retina (2014) and all software is up to date as of the time I am posting this question. (Using OSX 10.10.2 Yosemite)
I have been struggling for the past few days as I attempted to customized the Terminal window. Everything was going fine... until I decided I only wanted to change the color for the text that you are currently typing (text input) which will then be executed.
I have no problems getting into my .bash_profile and adjusting anything. I simply cannot seem to grasp the color concept well enough such that it only does this one thing for me. Currently my .bash_profile looks like this:
export PS1="\n\n\njboned$ "
export PATH="/usr/local/mysql/bin:$PATH"
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad
Any assistance would be greatly appreciated. As a sidenote: I understand the 8-bit snippets used to represent the individual colors, however it seems I cannot figure out how to use them to address only the text input only.
To do what you are asking, these steps would be needed:
at the end of the prompt, turn on the text color which you want to show
when you press return (to complete editing) turn the text-color off.
bash does not reset attributes while you edit, so the color "should" work — while editing. As you edit, bash is likely to use escape sequences which clear the current line (which may fill it with whatever background color you have selected).
The real problem is how to reset the colors when you press Enter. That does not appear to have a straightforward solution: I do not see a way to rebind the Enter key to add features—no distinction is made between levels of interpretation, and you may not find it possible to enhance the Enter key. The key binding feature in bash talks mainly to the readline library; leftovers are sent to bash. In a binding you may be able to do these things:
send the name of a macro to bash, or a full echo command which resets colors (since readline has no echo of its own, it seems)
the Enter key (i.e., ^M), and
to readline directly, the accept-line function
Alternatively, what you could do is bind another key, say control/L to do the bash accept-line function as well as resetting color. Here are a couple of links which you would find useful to investigate how to do this:
how to bind the 'Enter key'
Complex keybinding in bash
In bash, how do I bind a function key to a command?
Smart preparsing with the bash shell
There are several libraries like ncurses that assist in making command-line GUIs.
Simply put, how do they work?
My first thought was that ncurses intercepts all keyboard input, and draws each "frame" by outputting it line-by-line normally. Closer inspection, however, reveals that each new frame overwrites the previous one. How does it modify lines that have already been outputted? Furthermore, how does it handle color?
EDIT: The same question applies to anything with a "fancy" interface, like vim and emacs.
Text terminals have command sequences that do things like move the cursor to a particular position on the screen, insert characters, delete lines etc.
Each terminal type is different and has its own set of command sequences. ncurses has a databse (see terminfo for details)
Internally ncurses maintains 2 views of the screen: the current contents and what the screen should look like after the current pending changes are applied. Once the program requests a screen redraw, ncurses calculates an efficient way to update the screen to look like the desired view. The exact characters/command sequences output depend on what terminal type is in use.
curses (and ncurses, too, I think) works by moving the cursor around on the screen. There are control sequences to do such things. Take a look at the code again and you'll see them. These sequences are not ASCII control characters, they are strings starting with (umm...) ESC, maybe. Have a look here for a higher-level explanation.
I'm having some issues with my Cygwin terminal when I run 'less'. 'less' works fine, but when I come out of it, all the screen buffer history of the terminal is lost. Any suggestions?
I'm running Cygwin on WinXP.
Try running as less -X, or set the LESS environment variable to -X.
It has nothing to do with bash. What's being erased is the text displayed by your terminal emulator.
Like other full-screen programs, less saves the terminal state (including any displayed text and the cursor position) when it starts, and restores it on exit.
It does this by printing the strings defined by the smcup and rmcup terminfo entries.
These depend on the value of the $TERM environment variable.
If these strings aren't printed, or if they're configured to something that doesn't save and restore your terminal state, then less will replace whatever was on your screen by the contents of the file you want to view, and then not restore it.
Using the -X option to less (as suggested by the answer you accepted tells less not to print the smcup and rmcup strings -- which I would expect to cause the problem you're trying to solve.
If you want to save and restore your terminal state (which means that the output produced by less will vanish when you quit), you need to make sure that your $TERM environment variable is set to something with proper smcup and rmcup settings. I find that setting it to xterm usually works.
If you're ambitious, you can create your own terminfo entry and use the tic command to "compile" it to the binary format used by the system.
Dawid Ferenczy's answer suggests another possible cause for the problem; it's not something I've ever run into myself.
(Opinions differ widely on whether saving and restoring the terminal state is a good thing. This blog entry was written by someone who intensely dislikes it. Personally, I like it; if I want to run a full-screen command and keep its output visible while I'm doing something else, I just launch it in another window.)
(The original poster hasn't been on the site in about 2½ years, so we shouldn't expect any feedback, but these answers are likely to be useful to others.)
I had the same issue on my new laptop. I have been using Cygwin on the 64bit Windows 7 for a long time and I never experienced this problem. But on the new fresh system (also 64bit Windows 7) the same Cygwin with the same configuration cleared the screen buffer whenever I quit LESS, MAN, VIM etc. And it bothered me very much. Because I'm using Cygwin inside ConEmu terminal emulator, I suspected ConEmu. After a lot of hours comparing everything what potentially could be the cause (environment variables, configurations, software versions etc.), I had a conversation with the ConEmu's author (and he was really great, exemplary support for the free software!). And we finally found the cause.
The only difference (or one of few) was in the display size. The old laptop has a screen resolution of 1366 x 768 pixels, while the new one has 1920 x 1080. And I'm using the whole screen for the terminal window. It's really strange, but if the terminal window height is greater than cca 62 lines, the screen buffer is cleared after quitting the LESS, VIM etc. No matters if Cygwin is executed inside the ConEMu or plain cmd.exe. Making the terminal window smaller solved the problem. Window height of 62 lines seems to be fine for me. Also, with some of greater height values, the LESS process sometimes crashed.
It seems that it's a problem of the Cygwin.
The whole story you can read here.
Maybe it could help somebody. It took me really a lot of time to solve that. While the solution (or rather workaround) is such damn stupid :)