I am trying to spawn khal, a terminal calendar, when mouse pressing the default textclock widget in awesome wm.
local cal_notification
mytextclock:connect_signal("button::release",
function()
if cal_notification == nil then
awful.spawn.easy_async(noisy,
function(stdout, stderr, reason, exit_code)
cal_notification = naughty.notify{
text = stdout,
width = auto,
destroy = function() cal_notification = nil end
}
end
)
else
naughty.destroy(cal_notification)
end
end)
Unfortunately on execution, all syntax highlighting of khal is gone.
Does anyone have an idea how to spawn a notification without losing the 'look'?
Edit:
This occurs probably with any other terminal calendar, for example with cal, I think.
With grep --color -EC6 "$(date +%e)" it still doesnt output color.
With a forced --color statement of khal it outputs 001b 1m before every highlighted character.
CLI applications like khal use so-called ASCII escape codes to encode the coloured highlighting. Parts of those is what you saw with "outputs 001b 1m before every highlighted character".
There are more characters within those sequences than what you pasted here, but those are likely swallowed by Lua's string handling or awesome's rendering.
The problem here is the fact that this way of highlighting text using ASCII escape codes is something that's specific to terminals and terminal emulators. Other applications do not use or implement them.
For awesome specifically, text markup is done through Pango Markup. So for your notifications to retain the highlighting created by khal, you will need to create a conversion layer that transforms the ASCII escape codes into Pango markup.
An additional challenge is the fact that colours in terminals use a theme-based system. The terminal is configured with a certain set of colours, and the escape codes merely index into that list. They don't hold any actual colour information themselves. However, for Pango, you need to specify the actual colour value in the markup.
Related
I'm trying using
man ascii | vi -
to check ascii manual with vim,
then there are some weird character like '^H'
weird character in vim
how to make it normal?
EDIT:
i think this is due to some wrong config of my vim, or terminal,
because i tried some other machine,and it works fine,any body help?
What you're seeing here is the man page convention for typesetting bold and underlined characters.
The ^H character is the "backspace" or BS character, which you can find in ascii(7) as ASCII 8.
Displaying as ^H is a convention to indicate "Control-H", the caret being a symbol for the "Control" key, since that's a key combination that generate this control character (note that "H" is the eighth letter, also it's on the same row as BS in the ASCII chart at the man page.)
Also note that ^H here is a single character and not the separate ^ and H characters. If you move along that line with l motion repeatedly, you'll see Vim skips the Hs. Vim might also display them in a different color to make it clear they're special characters.
The effect you're seeing here is called overstruck characters and it comes from the days when computers would be connected to line printers rather than screens. Man pages were created early in the Unix days and are typeset with a program named nroff (which has roots that predate even Unix) that uses these sequences to encode its text decorations, even to this day.
So one way to make text bold (or, print it stronger) was to print a letter, back out one space, then print it again. In your example, N^HNA^HAM^HME^HE is being used to print the word NAME in bold.
Typically, you'll use a man pager program that knows how to handle those sequences. For instance, less has specific support for overstruck text and is able to recognize those sequences using backspace (or carriage return, also possible to use it for that) and convert into bold or underline text using terminal escape sequences which actually achieve those effects in a terminal.
If you're using a different pager, often you'll use col -b to strip your text from those sequences. (See col(1) for details.) Note that col -b doesn't produce terminal escape sequences around overstruck text, it simply removes all overstriking, leaves the text plain, so any text reader can display it.
(In that sense, man ascii | col -b | vi - is one possible way around your issue, but not the best one.)
Vim doesn't support overstruck text or terminal escape sequences in text it receives as input. So the approach used to use Vim as a man pager is to strip all overstriking (same as col -b does) and then use Vim's syntax highlighting feature to mark man page sections etc. (So instead of seeing the original markings typeset into the man pages, those are all being stripped and you're actually seeing Vim syntax configuration for man pages.)
This is accomplished by the manpager.vim script, which is shipped by default with Vim and which registers a :MANPAGER command that you can access as vim +MANPAGER -.
You'll see that part of what that does is to remove overstriking, same as col -b does. It also sets the file type correctly and enables syntax highlighting, setting up Vim as a suitable viewer for man pages.
I think this is due to some wrong config of my vim, or terminal, because I tried it in some other machine and it works fine there.
I'd say this is most likely due to the man pages being typeset differently between the two systems.
Man pages themselves and the pipelines used to generate them from the source code are not very uniform and you'll find differences across operating systems or even Linux distributions.
It's possible that on your other system all man pages get stripped using col -b at creation time, or that man will strip them when piping them to something that's not what's set in $MANPAGER, or even that they don't have anything marked as bold or underline in their sources.
Hard to tell exactly which (your reference to working fine on another machine lacks details to tell), but this would be my bet.
In short: To use Vim as a pager for man pages, instead of piping them to Vim, set it up so that man will run vim as a pager itself.
In Vim, see :help manpager.vim which has instructions on how to set this up.
In short, all you need is to add this line to your ~/.bash_profile:
export MANPAGER="vim -M +MANPAGER -"
After setting that up and logging in again, all you need is:
$ man ascii
And man will launch vim in the right mode for you.
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'm making a terminal recording and I would like to change the terminal foreground color to emphasize certain parts (such as certain command line arguments) in the recording.
How can I map a function key to emit a color code in bash/readline?
I can bind to other things like the arrow keys using bind '"\e[21~":"\e[A"', so I think doing something like bind '"\e[21~":"\e[[31m"' should emit a color code and change the fg color.
It doesn't. How do I make this work?
If you bind a key to a string like \e[A then this key emits this string which in turn is again parsed by the readline library and interpreted (in this case to mean "up" which is then pointing to the function previous-history). The string is never printed to the terminal.
So if you want to print something, you need to bind a key to a function which prints something arbitrary (your ANSI color escape sequence). I'm not aware of such a readline function because it doesn't make much sense if you think it through. The problem is that readline has no notion (no internal model) of colored characters. Readline is for raw characters only, without character styles. Switching the color, entering some visible characters, then using cursor keys to edit already typed (maybe colored, maybe standard) characters -- stuff like this will lead to redraws of the complete line. In that process the colors will be eradicated quickly (because readline doesn't really know about them).
So I guess what you want just isn't possible. It is a feature not supported by readline and which you cannot simply add to it (correctly) from the outside without breaking things.
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)]
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. (^_^)