Please help me understand the SGR parameters of ANSI escape code from 10 to 19
\033[12m
The sources only indicate about them:
SGR parameter
Name
Note
11-19
Alternative font
Select alternative font n − 10
I would like to find out and figure out what alternative fonts are and how these ANSI commands work.
Operating system - Windows 11. File .py run in the default Command Line. Python code:
print('\033[10m', end='')
print('font0 TEST123test')
print('\033[11m', end='')
print('font1 TEST123test')
print('\033[12m', end='')
print('font2 TEST123test')
print('\033[0;33m', end='')
print('TEST123test')
print('\033[1;33m', end='')
print('TEST123test')
Result of code execution: terminal
I believe that fonts should be changed to some alternative ones, but I don't understand what and how this should happen, and what else should I configure.
Related
Save following program as test.py:
def f():
"""àâùç"""
return
print("àâùç")
and execute it in a Windows cmd-window in interactive mode:
python -i test.py
The printed text is correct, but when I call help(f) I get scrambled eggs:
P:\>python -i test.py
àâùç
>>> help(f)
Help on function f in module __main__:
f()
ÓÔ¨þ
Changing the codepage to 65001 brings up classical mystery cards instead:
P:\>python -i test.py
àâùç
>>> help(f)
Help on function f in module __main__:
f()
����
Is there any (easy) workaround ?
help() has two bugs where the implementation of the pager is to write to a temp file and shell out to more. From pydoc.py:
def tempfilepager(text, cmd):
"""Page through text by invoking a program on a temporary file."""
import tempfile
filename = tempfile.mktemp()
with open(filename, 'w', errors='backslashreplace') as file:
file.write(text)
try:
os.system(cmd + ' "' + filename + '"')
finally:
os.unlink(filename)
The file is opened with default file encoding (cp1252 on U.S. and Western European Windows) which won't support characters outside the Windows-1252 character set (don't make Chinese help documentation, for example), and then shells out to a command (in this case, more) to handle paging. more uses the encoding of the terminal (OEM ANSI: default cp850 in Western Europe and cp437 in the US) so help will look corrupt for most characters outside the ASCII set.
Changing the terminal code page with chcp 1252 will print the characters correctly:
C:\>chcp 850
Active code page: 850
C:\>py -i test.py
àâùç
>>> help(f)
Help on function f in module __main__:
f()
ÓÔ¨þ
>>> ^Z
C:\>chcp 1252
Active code page: 1252
C:\>py -i test.py
àâùç
>>> help(f)
Help on function f in module __main__:
f()
àâùç
>>>
I want to make the font as bold for the path that I'm printing using Write-Host. I'm flexible to using other methods like echo or something else.
I've tried other methods like Write-Debug, etc, also checked the module WindowsConsoleFonts.
But none of them supports font properties like making them bold or italic while printing them.
$pathString = "[" + (Get-Location) + "]"
Write-Host $pathString -ForegroundColor Cyan
I'm using PowerShell 5.1 which doesn't support MarkDown rendering, else I would have done it using Markdown.
You can achieve bold text via VT (Virtual Terminal) escape sequences.
However, regular Windows console windows (conhost.exe) do not support italics, and neither does their upcoming successor, Windows Terminal (at least as of this writing).[1]
In recent versions of Windows 10, support for VT sequences is enabled by default in both Windows PowerShell and PowerShell Core.
However, Write-Host has no support for them, so you must embed the escape sequences directly into the strings you pass to Write-Host (or strings you send to the success output stream, if it goes to the console):
Note:
I'm omitting Write-Host from the examples below, because it isn't strictly necessary, but colored text generally should indeed be written to the display (host), not to the success output stream.
While it is better to consistently use VT sequences for all formatting needs - including colors - it is possible to combine them with Write-Host -ForegroundColor /-BackgroundColor`.
PowerShell Core:
PowerShell Core supports embedding escape sequences directly in "..." (double-quoted strings), via the `e escape sequence, which expands to a literal ESC character, which is the character that initiates a VT escape sequence.
"To `e[1mboldly`e[m go ..., in `e[36mcyan`e[m."
Windows PowerShell:
There's no support for `e; the easiest solution is to use \e as placeholders and use -replace to substitute actual ESC characters (Unicode code point 0x1b) for them:
"To \e[1mboldly\e[m go ..., in \e[36mcyan\e[m." -replace '\\e', [char] 0x1b
[1] From PowerShell Core, you can run the following test command to see if the word italics prints in italics: "`e[3mitalics`e[m after"
Note that italics in the terminal are supported on macOS and at least in some Linux distros; e.g., Ubuntu 18.04
I have the file t2ű.cmd on Windows with an accented character in its name, and I'd like to run it from Python 2 code.
Opening the file (open(u't2\u0170.cmd')) works if I pass the filename as a unicode literal, but no str literal works, because \u0170 is not on the code page of Windows. (See this question for more on opening files with accented characters in their name: opening a file with an accented character in its name, in Python 2 on Windows.)
Running the file from the Command Prompt without Python works.
I tried passing an str literal to os.system, os.popen, os.spawnl and subprocess.call (both with and without the shell), but it wasn't able to find the file.
These don't work, they raise UnicodeDecodeError: 'ascii' codec can't encode character u'\u170'...:
os.system(u't2\u170.cmd')
os.popen(u't2\u170.cmd')
os.spawnl(u't2\u170.cmd', u't2')
subprocess.call(u't2\u170.cmd')
subprocess.call(u'"t2\u170.cmd"')
subprocess.call([u't2\u170.cmd'])
In this project it's not feasible to upgrade to Python 3.
It's not feasible to rename the file, because these files can have arbitrary (user-supplied) names on a read-only share, and also the directory name can contain accented characters.
In C I would use any of the wsystem, wpopen or wspawnl functions in <process.h>.
Preferably I'm looking for a solution which works with the standard Python modules (no need to install packages). But I'm interested in any solution.
I need a solution which doesn't open a new window.
Eventually I want to pass command-line arguments to program, and the arguments will contain arbitrary Unicode characters.
This is based on the comment by #eryksun.
We need to call the system call CreateProcessW or the C functions wspawnl, wsystem or wpopen. Python 2 doesn't have anything built in which would call any of these functions. Writing an extension module in C or calling the functions using ctypes could be a solution.
The C functions CreateProcessA, spawnl, system and popen don't work.
As described in the pep 0263, if you want to use unicode characters in a python script, just add a # -*- coding: utf-8 -*- at the beginning of your script (it's ok after the she-bang):
#!/bin/env python
# -*- coding: utf-8 -*-
import os
os.system('t2ű.cmd')
If you still find problems, you may take a look on some packages, like win-unicode-console.
It should work now directly, with no escaping code.
I don't know why, but this topic seems to be badly documented and is covered with controversies as nobody knows the real answer (except for maybe Mr. Moolenaar, who rarely answers anyway).
So basically I've raised a discussion here, and it went dead pretty quickly, probably because there are not too many people using Vim in terminal mode on Windows.
My encoding settings look as follows:
if has('multi_byte')
if empty(&termencoding)
let &termencoding = &encoding
endif
let &encoding = 'utf-8'
let &fileencoding = 'utf-8'
endif
Of course, I have no problems running under GVim: can type any characters, and my patched Consolas for Powerline works just fine. The problems start when I try to run Vim in terminal mode. I use ConEmu, a feature-rich terminal emulator for Windows. It claims to officially support Unicode out of the box. For example, I can run the following test script:
chcp 65001 & (cmd /c type "%~dpn0.cmd") & pause & goto :EOF
English: texts, web pages and documents
Graves,etc: à á â ã ä å æ ç è é ê ë ì í î ï
Greek: ΐ Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο
Arabic: ڠ ڡ ڢ ڣ ڤ ڥ ڦ ڧ ڨ ک ڪ ګ ڬ ڭ ڮ گ
Full width: ＠ Ａ Ｂ Ｃ Ｄ Ｅ Ｆ Ｇ Ｈ Ｉ Ｊ Ｋ Ｌ Ｍ Ｎ Ｏ
Romanian: texte, pagini Web şi a documentelor
Vietnamese: văn bản, các trang web và các tài liệu
Russian: тексты, веб-страницы и документы
Japanese: テキスト、Webページや文書
Yiddish: טעקסץ, וועב זייַטלעך און דאָקומענטן
Hindi: पाठ, वेब पृष्ठों और दस्तावेज
Thai: ข้อความ หน้า เว็บ และ เอกสาร
Korean: 텍스트, 웹 페이지 및 문서
Chinese: 文本，網頁和文件
and I can see all the symbols correctly in ConEmu. Yes, the test script turns on the 65001 codepage. I've already discovered that Vim cannot work with the 65001 codepage at all, so this seems not to be an option anyway. The default codepage in the terminal is 437, and I can also type something like Russian in ConEmu with this default codepage, and it is displayed correctly.
Reading through :h termencoding, I see that Windows uses Unicode by default to pass symbols. Then, I don't understand why when I type anything non-ANSI in terminal Vim, I see ? symbols? Airline does not display fancy symbols from patched Consolas as well. How to configure true Unicode for terminal Vim on Windows? By the way, &termencoding reports 437 as well.
Could somebody, once and for all, please, explain to me is Unicode support for terminal Vim on Windows there (and how to configure it) or not?
I've wondered about this myself too and in the past tried ConEmu and gave up after struggling to get console vim with 256 colors and fancy fonts working on it.
So today I tried out for sometime again and surprise, surprise - things seem to be working. Given all the extreme sensitiveness to versions, I'm going to try and list down versions of everything
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 1 2014 09:38:34)
MS-Windows 32-bit console version
Included patches: 1-389
Compiled by raghuramanr#ADITI
ConEmu
140723 Alpha
Windows: Win 7x64
ConEmu settings in .vimrc:
" ConEmu
if !empty($CONEMUBUILD)
echom "Running in conemu"
set termencoding=utf8
set term=xterm
set t_Co=256
let &t_AB="\e[48;5;%dm"
let &t_AF="\e[38;5;%dm"
" termcap codes for cursor shape changes on entry and exit to
" /from insert mode
" doesn't work
"let &t_ti="\e[1 q"
"let &t_SI="\e[5 q"
"let &t_EI="\e[1 q"
"let &t_te="\e[0 q"
endif
Steps:
chcp 65001
vim.exe
I still can't get a blinking cursor in vim which is confusing. Still better than before when stuff would be messed up.
There was recently a patch for "Windows 8 IME in console Vim". It was cleaned up by mattn and posted here:
https://gist.github.com/mattn/8312677
It was included with 7.4.142. Does that version fix your issue?
How can you get similar highlightings to Zsh's Less than Bash's Less in Ubuntu?
I switched from OS X to Ubuntu. My Less do not work as expected in Zsh.
Manuals in my Less are green and black with or without the following code.
# comment these out in Ubuntu
export LESS_TERMCAP_mb=$'\E[01;31m' # begin blinking
export LESS_TERMCAP_me=$'\E[0m' # end mode
export LESS_TERMCAP_se=$'\E[0m' # end standout-mode
export LESS_TERMCAP_so=$'\E[38;5;246m' # begin standout-mode - info box
export LESS_TERMCAP_ue=$'\E[0m' # end underline
export LESS_TERMCAP_us=$'\E[04;33;146m' # begin underline is now yellow
# | | |
# | |----------------- yellow
# |-------------------- underline
# to have the indication of cursor's location and line numbers, and R
export LESS="-mNR"
# |--------- only ASCII color
The code makes manuals readable in OS X, but it does not work for Ubuntu in Zsh.
Ubuntu has excellent highlightings in Bash's Less. My manuals have the colors yellow, green and black in Bash without my code. Both Zsh and Bash use the same Less at /usr/bin/less. This suggests me that Ubuntu's Bash has some dot-files which configure it somewhere.
Where are highlightings for Ubuntu's Less in Bash?
This works for me in zsh on archlinux:
$ mkdir ~/.terminfo/ && cd ~/.terminfo
Now get the terminfo description:
$ wget http://nion.modprobe.de/mostlike.txt
Now compile it using tic (the terminfo entry-description compiler)
$ tic mostlike.txt
(you may want to delete the mostlike.txt file after compiling)
mostlike.txt is this
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm-pcolor
mostlike|manpages with color looking like most,
am, hs, km, mir, msgr, xenl,
cols#80, it#8, lines#24, wsl#40,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, bold=\E[1m\E[31m, clear=\E[H\E[2J, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
dsl=\E]0;\007, ed=\E[J, el=\E[K, enacs=\E)0, fsl=^G,
home=\E[H, ht=^I, hts=\EH, il=\E[%p1%dL, il1=\E[L, ind=^J,
is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>, kbs=^H,
kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
kfnd=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
kslt=\E[4~, rc=\E8, rev=\E[7m\E[34m, ri=\EM, rmacs=^O,
rmcup=\E[2J\E[?47l\E8, rmir=\E[4l, rmkx=\E[?1l\E>,
rmso=\E[m, rmul=\E[m,
rs2=\E7\E[r\E8\E[m\E[?7h\E[?1;3;4;6l\E[4l\E>, sc=\E7,
sgr0=\E[m, smacs=^N, smcup=\E7\E[?47h, smir=\E[4h,
smkx=\E[?1h\E=, smso=\E[1;30m\E[47m, smul=\E[32m,
tbc=\E[3g, tsl=\E]0;, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?1;2c, u9=\E[c,
And then just define an alias in the rc file of your favorite shell:
alias man="TERMINFO=~/.terminfo/ LESS=C TERM=mostlike PAGER=less man"
My default shell is bash so take this with a grain of salt. Start with /etc/profile and see how it sources bash-specific files. You need to re-create that logic for zsh. Maybe the zsh-lovers package can help, at least its title of tips, tricks and examples for the zsh
is suggestive.