We assume that any terminal that supports mouse reporting will also support
focus reporting; but we also add an entry to Terminfo to let specific terminals
override it if needed.
Previously, modified function keys in dyanmic terminals were not
supported (like shift/control/alt + arrow keys).
Even though xterm-compatible terminals were dynamically discovered
and their keys added to the terminfo struct, the Modifiers field
was not supported and therefore the modified Xterm keys were not
added to the keycodes map (prepareXtermModifiers was skipped).
This fixes the issue by setting the Modifiers field when we
discover that the terminal is xterm-compatible.
Commit 43efca775e added support for url IDs within OSC8 escape
sequences, however the formatting of the param is incorrect.
Use `id=` instead of `id:`
Fixes: 43efca775e ("hyperlinks: add support for optional id parameter")
These fix errors discovered while implementing the same logic
in dcell. While here, the conditional support was simplified
using a similar approach as used in dcell, and test cases were
added.
This supports both terminfo (Linux, macOS) terminals, and
the legacy Windows console. Perversely, the "modern" Windows
terminal doesn't support application initiated resizing yet.
fixes#526 tcell emits redundant attributes
This work is inspired by, and partly derived from, work submitted by
Simon Ser (@emersion). However, we've modified the bottom half of
the terminfo parser to better support strings properly, and are using
proper terminfo syntax.
Instead of an attribute called Hyperlink, we have called it Url
for the sake of brevity.
While here we noticed and fixed bug #526, which could badly impact slow
terminals, or slow links. This likely makes things better for folks
coming over long distance SSH connections for example.
We've also provided OSC 8 handling for all terminals which appear to
support the mouse sequences; hopefully ones that don't handle this
sensibly will just ignore it. (Limited testing seems to show this.)
There are two “regular”[^1] terminfos for foot. One stripped down
version included with ncurses, and another one shipped with foot
itself, that contains a number on non-standard capabilities (mainly
used by tmux).
Foot’s “own” terminfo is _usually_ packaged as “foot-extra”.
[^1]: there’s actually four; foot also has a “direct” variant (similar
to xterm-direct): foot-direct, and foot-extra-direct.
This adds a new method, SetCursorStyle() to the screen API.
It also automatically restores the cursor when disengaging to
the default cursor. Modern terminals (and Windows console) support
this.
This adds optional MouseFlags that can be used to adjust what is
tracked for mouse reporting (leaving the other modes to be handled
by the terminal.) This should work on all XTerm style terminals,
but on Windows we have no way to be selective here.
This adds Bracketed Paste support for terminals that have mouse
support and support it. The bracketing events are EventPaste,
with methods to note Start() or End() of the paste. Content
comes in as normal rune events. Programs must opt-in to this by
calling screen.EnablePaste().
@tslocum reported that the commit at 2d6d7fbe broke mouse support in
cview (https://github.com/gdamore/tcell/pull/384#issuecomment-698422464). The
purpose of the original commit was to fix a terminfo background color
code parsing problem that I spotted using TERM=xterm-16color:
$ infocmp xterm-16color | grep setab
setab=\E[%?%p1%{8}%<%t%p1%'('%+%e%p1%{92}%+%;%dm,
The middle sections says "if p1<8 then push(p1+'(') ". '(' is ascii
40. The sequence '%d' will then pop from the stack and interpreting the
result as an integer.
My change above was to have tcell assume the sequence between two single
quotes was a single ASCII character e.g. '(' and push that to the
terminfo stack as an integer with the ASCII value of the character
e.g. push(40:int). I didn't find any counterexamples in my local
terminfo database that didn't line up with that assumption; but I did
break mouse support because tcell generates its own rules to enable
mouse support, if not specified in the terminfo DB - both when
generating its own Golang-style internal DB, and in the dynamic terminfo
generator that uses infocmp:
"%?%p1%{1}%=%t%'h'%Pa%e%'l'%Pa%;\x1b[?1000%ga%c\x1b[?1002%ga%c\x1b[?1003%ga%c\x1b[?1006%ga%c"
This rule will push 'h' or 'l', depending on whether mouse mode is to be
enabled or disabled, and then sets the variable named a to the result,
interpreted as a string. The result is that when mouse mode is enabled,
tcell needs to emit \x1b[?1000h - where the 'h' comes from variable a
i.e. it needs to be able to push a quoted argument as a string and not
be forced into an int.
This alternative fix preserves the fact the quoted argument is a string
and maintains that on the stack. However, if the integer Pop() function
is called when the top element of the stack is a string, tcell will now
- return the string converted to an int, if it converts e.g. in the case
'123' is pushed to the stack as a string and popped as an int, the value
is 123
- otherwise return the ASCII value of the first character of the string
e.g. if '(' is pushed then popped as an int, the value returned is 40.
To be compatible with this logic, if a terminfo rule needs to push an
integer whose value is >= ascii('0')==48 and <= ascii('9')==57, it will
need to use the form e.g. {53} and not '5' because the form '5' will be
pushed as "5":string and if popped as an int will return the value 5 and
not 53.
I noticed this problem while running a gowid test program (palette.go)
with TERM=xterm-16color. This terminal type is not present in tcell's
built-in database, and so tcell falls back to the dynamic terminal type
by parsing the output of infocmp. The symptom was that foreground colors
were not correctly set, leaving a monochrome screen. This seems to be
caused by a problem interpreting the *background* color terminfo
rule. The attribute to set background color is defined like this (Ubuntu
20.04):
$ infocmp xterm-16color | grep setab
setab=\E[%?%p1%{8}%<%t%p1%'('%+%e%p1%{92}%+%;%dm,
The middle sections says "if p1<8 then push(p1+'(') ". '(' is ascii
40. If I run
$ tput setab 5
the terminal sees 'ESC[45m'. This correctly sets the background color to
magenta. But if I tell tcell to emit a cell with background color set to
tcell.Color(5), the terminal sees 'ESC[0m'. This means in practice, my
app emits a code to set the foreground color, then an SGR code that
resets all attributes, then the ASCII character.
When tcell "runs" a terminfo rule in terminfo::TParm(), a push to the
stack preserves the type of the argument pushed - int or string. When a
single quote is encountered, the argument within is pushed to the stack
as a string. For the `setab` rule above, tcell will then pop as an int,
discarding the error and returning 0. The fix here is to have tcell push
the argument inside the single quotes as an integer, using the ascii
value of the argument e.g. "(" -> 40 - and assume the string is length
1, I suppose. Cross-referencing against
ncurses/tinfo/lib_tinfo.c::tparam_internal(), it looks like this code
assumes a single-quoted string is assumed to be length=1 and is also
interpreted as an integer with the ascii value of the character:
case S_QUOTE:
cp++;
npush(UChar(*cp));
cp++;
break;
This replaces high numbered function keys on xterm style
emulators with modifiers. So pressing SHIFT-ALT-F1 is
reported as exactly that, for example. This also extends
that to the insert, delete, home, end, etc.
There is a chance that this will break some emulators --
of particular concern are older VTE based emulators and
rxvt (and derivatives). However, we think that most VTE
derivatives are now much more closely aligned to xterm.
The Wyse50 alternate character set was changed (likely
due to a bug fix in ncurses).
Implemented key kombination of Shift + PgUp/PgDn for Gnome terminal.
Same combination copied to all other terminal implementations which use same
codes for Shift + Up/Down but since this is tested on Ubuntu 16.04 with Gnome
Terminal 3.18.3 it could be that it is not correctly implemented for some of the
other terminals.
I have rerun gen.sh having pulled the latest tcell to include this PR:
https://github.com/gdamore/tcell/pull/325.
I am using Ubuntu 19.04 - running gen.sh changed more fields than just
those impacted by the above fix. I've removed those from this commit. (I
verified that gen.sh changed those fields I've removed without the fix
above, so it's not related). Based on TERMINALS.md, I suspect you
regenerate these typically on a Debian machine(?)
@klamonte opened this issue against gowid, a package that relies on tcell for
all its terminal handling: https://github.com/gcla/gowid/issues/24. It
describes how a shell inside a terminal widget that the TUI launches freezes
when the user hits backspace. The TUI loads a tcell TermInfo struct for the
screen-256color terminal and that struct codes KeyBackspace as the single byte
0xff - and so the byte 0xff was sent to the tty. On my Ubuntu 19.04 machine,
`infocmp screen-256color` shows `kbs` is `^?` According to
https://en.wikipedia.org/wiki/Caret_notation, `^?` should map to 0x7f (127) -
"The digraph stands for the control character whose ASCII code is the same as
the character's ASCII code with the uppermost bit, in a 7-bit encoding,
reversed". This affects both mkinfo.go, the generator of the JSON terminfo
database files, and the dynamic terminfo generator.
fixes#285 Loss of color/mangled formatting on GNU screen
fixes#93 use the terminfo database instead of the json database
This change falls back to using a dynamically generated terminal
description (using infocmp, which must be on the path) if the builtin
database doesn't have a suitable description.
For most users this should resolve the problem of unknown terminals.
This expands support for 24-bit color for terminals that support the
ISO 8613-6:1994 escape sequences (same as xterm), allowing this support
to be enabled by setting % COLORTERM to "truecolor" (or 24bit or 24-bit),
or by setting TCELL_TRUECOLOR to "on", or by setting $TERM a value that
ends in the word "-truecolor".
As this is handled by the runtime now, we no longer need to create magical
database entries for -truecolor options.
A colors.go demo is provided to show off 24-bit color support.
While go-convey was pretty nice, it carries a rather large dependency
graph, which we think it is better not to burden our downstreams with.
It is easy enough to just refactor the tests to use the standard testing
package.
stk