Is there any way to determine what the color of the cursor is in a terminal running something like vim? I know that you can use tput cols and tput rows to determine the height and width of the terminal, are there similar tools for cursor color/obtaining the ansi standard foreground/background color of any character location in the current terminal?
The answer to your question is "No, there is no standard way to do that."
Consider that your terminal is modelled after ancient text terminals (like DEC VT100 and the like) which communicated with a server over a serial port or modem. And those terminals were in turn modelled after TeleTYpe (tty) devices which were connected to computers back in the 1960s.
Teletype machines ("dumb" terminals) provided no data back to the server that was not typed in to the keyboard. Devices like the VT100 ("smart" terminals) provided VERY LITTLE back to the server, but the list of what's available hasn't changed in many years.
Other resources:
The full list of reports available in VT220 emulation.
Another useful unofficial resource with slightly easier to follow wording.
Note that not all terminals are VT100/VT220, and your system may have locak extensions that provide what you need in a non-standard way.
For extra reading, have a look at man termcap and man terminfo. Check out the references in the "SEE ALSO" section of those pages.
Short answer: no
Long answer: the feature, if widely available would be another capability of tput, which allows you to retrieve any of the terminal capabilities for scripting. Those are documented in the terminfo manual page. None of those deal with cursor color, only with the (rather vague) cvvis (very visible), cnorm (normal) and civis (invisible) cursor attributes.
That is, most terminals do not
provide a way to set the cursor color or
provide a way to retrieve the cursor color
xterm is a rare exception, providing both. But the feature is not often supported in terminals imitating xterm. It is documented in XTerm Control Sequences as part of the dynamic colors feature:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
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.
The 10 colors (below) which may be set or queried using 1 0
through 1 9 are denoted dynamic colors, since the correspond-
ing control sequences were the first means for setting xterm's
colors dynamically, i.e., after it was started. They are not
the same as the ANSI colors. These controls may be disabled
using the allowColorOps resource. At least one parameter is
expected for Pt. Each successive parameter changes the next
color in the list. The value of Ps tells the starting point
in the list. The colors are specified by name or RGB specifi-
cation as per XParseColor.
If a "?" is given rather than a name or RGB specification,
xterm replies with a control sequence of the same form which
can be used to set the corresponding dynamic color. Because
more than one pair of color number and specification can be
given in one control sequence, xterm can make more than one
reply.
Ps = 1 2 -> Change text cursor color to Pt.
The command-line program xtermcontrol uses these escape sequences to set and get the cursor color:
--cursor=COLOR
Set cursor color to COLOR.
--get-cursor
Report cursor color.
For example
$ xtermcontrol --get-cursor
rgb:0000/0000/0000
$ xtermcontrol --cursor limegreen
$ xtermcontrol --get-cursor
rgb:3232/cdcd/3232
For what it's worth, it is supported by VTE (e.g., gnome-terminal).
Related
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.
I would like to query and store the current terminal color pair in BASH e.g.:
#!/bin/bash
#some ANSI colour escape sequences
red="\033[0;31m"
grn="\033[0;32m"
blu="\033[0;34m"
def="\033[0;00m" # default
echo -e "Change to ${red} red to ${def} default to ${blu} blue."
# now store the current color (which happens to be blue) e.g.:
cur=????
echo -e "Change to ${grn} green and back to what I had before ${cur}"
echo -e "This would be in blue if variable cur contained e.g.: 0;34m."
echo -e "Back to default${def}"
exit 0
The answer that eludes me is how to capture the current color
cur=????
The question was about the current color, not the cursor position.
Both are "nonstandard" (though the latter, cursor position report is implemented by anything which has a valid claim to "VT100 emulator").
However, xterm implements a set of escape sequences referred to as dynamic colors, which predate the ANSI color functionality. Those set the working colors including text foreground and background. I modified this in 2002 to allow an application to send the sequence with a "?" rather than a color to tell xterm to return the color value, e.g.,
OSC 1 1 ? ST
using the notation given in XTerm Control Sequences
You can't; there is no standard control sequence to report the current cursor attributes.
What does exist, however, is a sequence to save and restore the current cursor position and attributes:
\e7 (DECSC) will save the cursor position and attributes.
\e8 (DECRC) will restore the saved cursor position and attributes.
There is no standard way to restore only the cursor attributes; however, as rici mentioned, you can get a report of the current position using \e[6n (DSR), then use the response to manually "un-restore" the cursor position after restoring its position and attributes.
Again, though, it's probably easier (and better) to just keep track of the colors in your application, rather than making the terminal responsible for that.
It's important to understand that the terminal state has nothing to do with bash. Bash doesn't care. It simply reads from stdin and writes to stdout and stderr. (See Note 1)
All terminal effects are implemented by the terminal emulator you happen to be using, of which there are many. In a graphical environment, you might be using, for example, xterm or konsole. You'll need to search the documentation for those emulators for specific terminal control codes which they interpret.
As far as I know, there is no standard code to get a report of the current terminal state, other than the cursor position (ESC[6n).
So your best bet is to remember the changes you made when you make them.
You can find a list of the standard codes implemented by the Linux console using man console_codes (although few people use the Linux console these days); most of those are also interpreted by xterm and other graphical consoles. There's an list of xterm sequences in Thomas Dickey's xterm site; it's a more or less de facto standard for terminal emulators but, as I said, you'll need to search in each emulator's documentation for idiosyncratic control sequences.
Notes
In interactive mode, bash uses a library called readline to help it handle some terminal effects. In particular, readline tries to maintain the current console cursor position, although it is easy to fool it. In PS1 you need to surround console control sequences with \[ and \] precisely because readline does not know that they are control sequences.
What I understood, is that u are asking to to get the default profile color of the user, of which u have change color of!
Eg: User is using 'Bright Green font color on Black background', you change it to 'Red font color on White background'. Now how to get/know the default colors and set them back to it!
You can use the sequence \033[0m in bash [also for command prompt (batch scripting) / powershell (ps scripting)]
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 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. . .
I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)