With the following example, I am able to get the mouse position inside my terminal until column 94. Where is the limitation?
#include <curses.h>
int main()
{
initscr();
cbreak();
noecho();
keypad(stdscr, TRUE);
mousemask(ALL_MOUSE_EVENTS, NULL);
MEVENT event;
for (;;)
if (wgetch(stdscr) == KEY_MOUSE && getmouse(&event) == OK)
mvprintw(0, 0, "Mouse at row=%03d and column=%03d", event.y, event.x);
}
Tested in:
Windows Terminal (WSL2)
cmd.exe (WSL2)
But it is working in :
mintty (WSL2)
What am I missing?
In all terminal, I get the same result by manually enabling mouse reporting with echo -e "\e[?1000;1006;1015h". So it seems Ncurses is using something else...
ncurses uses the terminal description to determine if the terminal supports xterm's 1006 mouse-mode. It looks at the XM flag (see user_caps(5)):
The XM capability has a single parameter. If nonzero, the mouse
protocol should be enabled. If zero, the mouse protocol should
be disabled. ncurses inspects this capability if it is present,
to see whether the 1006 protocol is used. If so, it expects the
responses to use the SGR 1006 xterm mouse protocol.
To see that flag, you can use infocmp, e.g.,
infocmp -1x |grep XM,
to see if it is defined. For mintty, you might see this:
$ infocmp -1x mintty | grep XM
XM=\E[?1006;1000%?%p1%{1}%=%th%el%;,
For those others, it helps to know what TERM is set to (also, the version of ncurses, since it could be too old).
That 1015 in the question bears comment: that is an rxvt-unicode feature, which is not recognized by Windows Terminal. Nor is it mentioned in the documentation for Windows cmd. It is implemented in PuTTY (also xterm, though PuTTY's implementation differs from xterm). In both PuTTY/xterm, that 1006 which precedes the 1015 in the echo command will cause those terminals to use xterm's 1006 ("SGR mode"), which is implemented by Windows Terminal. If you had omitted the 1006, then it would not work with ncurses, because the protocols differ—and ncurses does not have support for the 1015 encoding.
Related
I'm using
Windows 10 Terminal (v1.12.10982.0)
Bash from Cmder (v4.4.23(1)-release)
Quemu (v7.0.0-11902-g1d935f4a02-dirty)
The terminal supports ansi colors (e.g., echo -e "\033[0;34mI'm blue\033[0m" works).
For testing of a custom kernel, I'm using qemu's serial port and the -serial stdio cli argument.
Text is printed fine, however any ansi color escape sequences are displayed verbatim, e.g., ←[32mError←[0m.
After twiddling around I figured out that if I'm removing the -display none argument, it actually works as intended.
For my non-graphical CI system I'll need a headless version of qemu, but adding either -display none or -nographic both break the ansi escape sequences.
Is that intended? Is there an option that I missed?
Previous section
I don't know where in the integration this error is happening. Is qemu doing something before it prints it to stdio?
How can I fix this? I saw Ansicon, but it seemed to be a fix for Windows' CMD.
I'm using Mac OS 10.13.4.
iTerm2 Version is Build 2.1.1
Vim Version is
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 29 2017 18:37:46)
Included patches: 1-503, 505-680, 682-1283
Compiled by root#apple.com
And I Installed the Vundle plugin
And when I open vim in iTerm2 with oh-my-zsh, the $p appears at the first line.
It doesn't appear with Terminal.app of Apple?
How to solve this problem?
vim is assuming that iTerm2 is xterm (not a good assumption), and attempting to determine the state of the cursorBlink resource by sending an escape sequence containing $p which iTerm2 does not handle properly (see source-code for vim for the escape sequence, and also where it uses the feature). While vim starts with the TERM setting (i.e., "xterm"), it does make a few checks to exclude things like gnome-terminal as noted in the source code comment. But iTerm2 happens to fool vim in this case. So the result goes to the screen.
In XTerm Control Sequences that is documented like this:
CSI ? Ps$ p
Request DEC private mode (DECRQM). For VT300 and up, reply is
CSI ? Ps; Pm$ y
where Ps is the mode number as in DECSET/DECSET, Pm is the
mode value as in the ANSI DECRQM.
Two private modes are read-only (i.e., 1 3 and 1 4 ), pro-
vided only for reporting their values using this control
sequence. They correspond to the resources cursorBlink and
cursorBlinkXOR.
Although vim is fooled here, the problem is due to iTerm2, for which you've probably set the TERM environment variable to xterm-256color, or something like that. It doesn't match iTerm2's behavior very well (the function keys don't match up, etc). ncurses provides a better one. But out-of-the-box MacOS has a terminal database that's about ten years old, and lacks that entry. To get a good terminal database (i.e., one where you could set TERM to iterm2), you could do that with MacPorts or home-brew.
Running infocmp to get a measure of the differences between the (correct) iterm2 entry and linux, xterm-256color shows that
it's actually closer to nsterm-256color (a correct entry for Terminal.app which Apple doesn't provide) with 38 lines of difference,
next closest linux with 76 lines and
still further away from xterm-256color with 94 lines.
The feature that's missing or mis-implemented in iTerm2 isn't in the terminal description: it's a special feature that vim has to guess about.
As mentioned above, this $p is due to vim sending a control sequence for a cursor blink request. In your .vimrc, you can turn off the cursor blink request by clearing the t_RC terminal option. I wrapped this in a conditional which turns it off only for 256 color terminals.
if &term =~ '256color'
set t_RC=
endif
Setting the terminal explicitly to linux solved it for me:
export TERM=linux
The p means print, which is the command the range is being given to, and yes.. it displays to you what is in that range.
In vim you can look at :help :range and :help :print to find out more about how this works. These types of ranges are also used by sed and other editors.
They probably used the 1,$ terminology in the tutorial to be explicit, but note that you can also use % as its equivalent. Thus, %p will also print all the lines in the file.
I have a problem with my Xterm and I can't figure out what is wrong:
I need to enable the option *selectToClipboard in my Xterm to be able to copy text in the terminal.
To do so i firstly tried to "manually" start xterm with the option with the following command: xterm -xrm 'xterm*selectToClipboard: true' which work very well.
Then to enable the option each time xterm is started I put the following line xterm*selectToClipboard: true in my ~/.Xresources and I used the command xrdb -merge ~/.Xresources to update the settings but it doesn't work: Xterm starts but the option isn't enabled and I can't copy text from the terminal whereas all the other options in the Xresources are enabled and work fine.
Does anyone have an idea of what could cause this problem?
X resources are case-sensitive. The xterm manual documents this as
selectToClipboard (class SelectToClipboard)
Tells xterm whether to use the PRIMARY or CLIPBOARD for SELECT
tokens in the selection mechanism. The set-select action can
change this at runtime, allowing the user to work with programs
that handle only one of these mechanisms. The default is
"false", which tells it to use PRIMARY.
The feature was added to xterm in patch #209 (2006). It is not an optional feature. So (assuming you have typed the command-line as given), there are a few possibilities to check:
you could be running an older version of xterm. To check this, run
xterm -v
The -v version option of xterm will have it print a one-line message showing the patch-level along with the configuration for which it was compiled, e.g.,
XTerm(261)
The feature can be set/reset using an escape sequence, as noted in XTerm Control Sequences:
CSI ? Pm h
DEC Private Mode Set (DECSET).
...
Ps = 1 0 4 1 -> Use the CLIPBOARD selection. (This enables
the selectToClipboard resource).
Your shell initialization may have something which sends this sequence.
The xrdb -query is one way to check for resource-settings, but it is not infallible. A better tool would be appres, e.g.,
appres XTerm
appres UXTerm
depending on whether xterm is run with/without the UXTerm application defaults. In contrast to xrdb, appres shows resource settings after taking into account the "app-defaults" files. (It does not see resources applied only to an instance of xterm such as the -xrm option).
tmux has a feature which can interfere with selections (whether to primary or clipboard). That is called set-clipboard, and is commented upon here:
Enabling mouse in tmux conflicts with paste in X [duplicate]
Re: iTerm2 support for set-clipboard
Short answer:
just need to add the line bellow in your /etc/X11/app-defaults/XTerm file
*selectToClipboard: true
Long answer:
If you look at man pages xterm(1):
man xterm
FILES
The actual pathnames given may differ on your system.
...
/etc/X11/app-defaults/XTerm
the xterm default application resources.
/etc/X11/app-defaults/XTerm-color
the xterm color application resources. If your display supports color, use this
*customization: -color
in your .Xdefaults file to automatically use this resource file rather than /etc/X11/app-defaults/XTerm. If you do not do this, xterm uses its compiled-in default resource settings for colors.
...
I did not find any reference to a user configuration file to set XTerm application defaults, except for XTerm-color, so I don't think it exists.
I'm trying to get 256 colors in the fantastic ConEmu-Maximus5 console.
Update: Now it only shows 8 colors. I know because '$tput colors' output is '8'
I have followed the instructions and activated:
TrueMod (24-bit color) support
Inject ConEmuHk
ANSI x3.64 / xterm 256 colors
I don't understand what to do with 'check off whether the buffer / slide.'
I'm in windows 7.
I start ConEmu with a custom direct link, so it loads cygwin bash file.
"C:\Program Files\ConEmu\ConEmu64.exe" /cmd ""C:\cygwin\bin\bash.exe" --login -i"
In my bashrc profile I have -> export TERM=cygwin
This is my custom command prompt:
function prompt {
local RED="\[\033[0;31m\]"
local GREEN="\[\033[0;32m\]"
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
PS1="$COOLRED\u#\h $LIGHT_COOLGREEN\$PWD \[\e[0m\] > "
}
prompt
The value of ConEmuANSI in ON, by the way.
I have some screen shots:
As you can see the command prompt looks very extravagant because it doesn't like the 256 color settings. If i substitute the variables COOLRED and COOLGREEN with RED and GREEN, then it looks ok, but it's not 256 colors.
More screenshots of the settings:
And the last sceen shot it's cygwin's mintty. Everything is ok there. Full 256 color supported. It's a shame mintty doesn't have tabs. That's mostly the reason why I'm trying to move to ConEmu.
Thank you very much for helping!!!
Bash does not send ANSI sequences to console. It tries to process them itself. And, because *nix terminal is generally only 8-color (not taking into account 256-color mode), bash uses 8-color palette instead of 16-color palette which is common to Windows terminal.
I think, 256-colors works in mintty because _isatty returns zero in that terminal. But it returns non zero value under ConEmu. May be in future builds I solve this puzzle (how to create real terminal with PTY features for some applications).
As for the question
You have no need in 256-colors In fact. To redefine prompt palette you may use "Extend foreground colors with background" feature. In breaf - set up colors 16, 17, etc. in ConEmu, set prompt background in bash to #5 (configurable in ConEmu), and voila.
There was a small bug in ConEmu "Extend..." processing. Use build 121016 or later.
PS1="\e[30;45m\u#\h \e[34;45m$PWD \[\e[0m\] > "
Following info does not match the question, but may be useful
Current version does not support 256-color mode in 'whole' console buffer (limitation, yes, removing it in plans).
So, you can go 2 ways
totally disable scrollback buffer (many ways, for example "cmd -cur_console:h0")
work in the bottom of the scroll-buffer.
I also couldn't get 256 color support to work (the colors would show up, but they looked the same as the 16-color palette). I switched to the "xterm" color scheme and now it works in native Windows executables (such as Python) but not in anything that uses Cygwin. Cygwin appears to have terminal-escape-sequence processing that you can't turn off, which defeats the ConEmuHk injection.
This is documented on the ConEmu wiki, here.
I had this weird problem and the weird solution and somehow it works. and don't know if this is with others too, just some info-sharing in case this shall be helpful.
I like colouring my consoles and like to utilize the full real 256 bits of RGB colouring.
After confuguring as in the conemu/CMDer (i used the forked one) instruction. my 256bit coloring test looked like this.. After mucking around a bit and testing with my bash 256bit capability. i.e running this command:
for i in {1..16384}; do echo -en "\e[38;5;${i}mTest";done
*note supposed to be {1..256}, but i had to force it for a longer colour prints, so just took a longer random number..
giving the result:
But running some 2-3 times, i saw this clean gray shade suddenly
and it worked then on..
weird but i got this working. Could it be that CMDer is somehow not using the full 256 bit because of optimizing reason and it get triggered when it is kicked in??,
PS: my CMDer cmd for the console:
-cur_console:fp -cur_console:d:"C:\WS":P:"<Cobalt>":t:"test":C:"C:\Arbeit\tools\Iconka-Buddy-Ninja.ico" set "PATH=%ConEmuDrive%\Program Files\Git\usr\bin;%PATH%" & "%ConEmuDrive%\Program Files\Git\git-bash.exe" --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe /usr/bin/bash.exe -l -i
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
Those \es are probably from an e.g. C printf string. You don't want them in a shell script. Stick with the original \033 notation. Also you are missing the closing \]. These lines should now read
local COOLRED="\[\033[38;5;173m\]"
local COOLGREEN="\[\033[38;5;113m\]"
I want to send a keystroke to a GLUT program on X11, but I can't find there's an X11 client attached to the GLUT program.
I do this, using the most excellent demo program for the chipmunk 2d physics package:
xlsclients -a|sort >aa
chipmunk_demos (in another window)
xlsclients -a|sort >bb
diff aa bb
and there's no difference.
My eventual hope is that I can control the GLUT program by sending key events with the equivalent of:
xdotool key --window 0x4000002 a
So my questions:
how can I remote control a GLUT program running on linux/X11?
Is there a way to get an X11 window id for a GLUT program?
Install xtrace, then:
In Terminal 1:
xtrace -d :0 -D :8 | grep CreateWindow
In Terminal 2:
DISPLAY=:8 chipmunk_demos
You should get a line with:
... CreateWindow depth=0x18 window=0x04a00002 ...
Update: xdotool actually contains powerful search functionality, which recent versions make even easier to use. It doesn't make sense to use xtrace like this, just use xdotool search instead