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).
This causes colors that are set that are low numbered to
be treated as themed colors -- basically honoring the palette
of the terminal.
The Style and Color implementations have changed quite a bit
to permit growth -- the colors are now 64-bits wide to permit
using the upper bits as flags, and to leave room for a future
alpha channel.
There is a new TrueColor() method on colors that obtains the
value as strict RGB value, and this will be used in lieu of
whatever terminal colors are provided -- giving the application
full control over the color space if they want, without
forcibly clobbering user preferences for terminals for the
vast majority of cases.
Indexed colors are created with the new PaletteColor API.
This works well on the new Windows 10 Terminal, as well as recent
Windows 10 ConHost. Support for this is automatically enabled if
we detect that the terminal supports ANSI escapes, except for
ConEmu, which has a fairly severe scrolling bug with truecolor.
To opt-in anyway, set TCELL_TRUECOLOR to "enable" in your environment.
To opt-out, set TCELL_TRUECOLOR to "disable" in your environment.
This reverts commit 1b5e88726b02c4d65b5a921ba06f016708ef0f9d.
Reuse of the buffer causes a subtle bug if the consumer
does not read from the slice fast enough. This was a regression.
Removing SetCursor makes it possible to add lines to the model on the fly,
while keeping the cursor in position.
Go also initializes them with 0, no need to set it manually.
The build for the "solaris" and "illumos" tags appears to have been
broken by commit 8ec73b6fa6c543d5d067722c0444b07f7607ba2f, which
introduced the Beep() API. Restore functionality by using the same
implementation as every other UNIX family platform.
This way GetCell() will get full runes, not just bytes. Now accent characters will show properly
Adjust SetLines() and Init() to work on [][]rune instead of []string
Add a Beep() method to the Screen interface. On *nix systems, this
writes the bell character (0x07) to the tty. On Windows, we call the
MessageBeep syscall.
Fixes: #2
Do not store cursor info (cursorX, CursorY) in CellView, as it belongs to the model (CellModel)
Use GetCursor() to identify current cursor position from CellModel
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.
Sometimes, the TIOCGWINSZ ioctl returns all zeroes (including columns,
rows) without an error. I found this when experimenting with the jexer
TUI toolkit for java e.g.
mvn dependency:get -Dartifact=com.gitlab.klamonte:jexer:0.3.2
jexer -jar ~/.m2/repository/com/gitlab/klamonte/jexer/0.3.2/jexer-0.3.2.jar
Once the demo starts, click the "Terminal" button, then type
stty size
it returns
0 0
My understanding is that this is normal, and happens until SIGWINCH is
received, or the size is set explicitly with TIOCSWINSZ.
My tcell application crashed under the jexer terminal because I didn't
anticipate a window size of (0,0).
If you run vim under the jexer terminal, it correctly sizes itself to
80x24. The shell's TERM variable is xterm, and infocmp xterm | grep cols
shows a default of 80 and a default of 24 for lines. The documentation
for vim explains how it computes the terminal size:
https://github.com/vim/vim/blob/master/runtime/doc/term.txt#L629
- an ioctl call (TIOCGSIZE or TIOCGWINSZ, depends on your system)
- the environment variables "LINES" and "COLUMNS"
- from the termcap entries "li" and "co"
This PR replicates that logic in the getWinSize() function. I think it
makes sense here because tScreen holds the TermInfo struct but the
tcell.Screen interface does not expose TermInfo to clients - of course
because the screen is abstracted to work on Windows too.
