This makes the default build about 150k larger, but includes all
the good terminals needed to make most folks happy. In addition,
it allows a build tag of tcell_minimal to suppress that. Finally,
we do not include infocmp support on platforms unlikely to support
it, such as Windows, nacl, android, etc.
This change has refactored the illumos layer to make use of the
golang.org/x/sys/unix package to achieve a clean cgo-free solution
for illumos and Solaris.
The approach here should be a template for other systems. I've
also made some changes to the Linux port.
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.
A gowid user reported that mouse movement in their gowid(tcell) application
was causing the console cursor to flicker on windows, jumping from the current
position in the console to the top left corner, and back again. In part, this
is an artifact of the way I render a gowid "canvas" - calling HideCursor()
unilaterally, then calling ShowCursor(x, y) if the canvas contains a logical
cursor that is within bounds. Because currently every mouse event causes a
gowid application redraw, on windows the effect is to cause the cursor to jump
to the top left briefly, disappear, then reappear in the previous
position. You can see it most easily by moving the mouse rapidly left and
right.
An upstream fix is for me to only call HideCursor() if I know I'm not going to
call ShowCursor(x, y). But the flicker can also be eliminated by removing the
call to setCursorPos(0, 0) in console_win.go before hiding the cursor. The
single call to showCursor() in console_win.go is preceded by setting cursor
coordinates explicitly, so I don't think anything depends on the assumption
that a hidden cursor has been set to position (0, 0) first.
I humbly submit this patch as another attempt to address the issue that tcell
will only paste up to 11 characters at a time. The problem is caused by the
fact that events (key, mouse, etc) constructed from the stream of raw input
characters are sent to the consuming application over a length-10 channel via
screen.PostEvent() which, if the channel is full, will drop what can't be sent
immediately. If the input stream grows rapidly e.g. because the user pasted a
large section of text into the running tcell application, then more than 10
events will likely be built from the chunk of input read by scanInput().
A blocking channel send is not used (i.e. PostEventWait() instead of
PostEvent()) because the channel send is issued from a call stack in which the
screen struct's lock is held. If the receiving application is not consuming
events, then callers to other screen APIs will block waiting for the screen's
lock. If the receiving application needs to call another screen API before
reading from the channel, a deadlock may occur if that required screen API
tries to take the screen's lock.
This patch collects events extracted from the input stream into a slice while
the lock is held, then after releasing the screen lock, writes them in order
to the event channel with PostEventWait(). I chose the blocking API to ensure
events aren't dropped, since sending the events outside of the lock-held scope
should remove the risk of a deadlock (unless I've missed something important!)
This patch is similar in spirit to that submitted by @soyking:
9addd5bbe4.
I have not adjusted the windows cmd console screen because the paste problem
does not seem to be an issue in practice on that platform, at least according
to my testing.
go-sqlmock, which is a dependency for go-colorful tests, have switched from
gopkg.in to Go modules. This repository still records the old gopkg.in import
path in the go.mod file, which confuses `go mod`:
go: gopkg.in/DATA-DOG/go-sqlmock.v1@v1.3.3: go.mod has non-....v1 module path "github.com/DATA-DOG/go-sqlmock" at revision v1.3.3
This commit updates the go.mod file to use the new import path.
We had problems where if $TERM was set on a Windows console, we would
fail to allocate the screen because of missing termios. This caused
lots of problems for many Windows users. This should make this easier
for folks who might have set $TERM for other reasons, even in a Windows
console environment.
Eventually we will want to support emitting characters for 256 color
support, but that's later.
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.
* SetContent() now makes a copy of the combining characters slice. Avoids unexpected side effects when original slice is reused/modified. Fixes#215
* Appending combining characters to an empty rune slice instead of making a copy.
This changes the database to use sha1 based file names. Its not
beautiful, but this is the BS we have to do to cope with the garbage
that is case insensitive filesystems.
Legacy databases are still honored, if you have them.
Setting t.quit to nil while the mainLoop is running causes a
race condition when the Fini() method is called. This change
instead uses a select expression to avoid the nil check and set.
This is not so much a fix, as a workaround for an incredibly busted
tty driver in macOS. I've tried nearly every other approach I can
think of, and this is the best of a bunch of really rotten options.
The draw back here is that reinitializing the screen may not work as well
as we'd like, and that there may be a leaked descriptor and goroutine
after you Fini() on macOS. Not many other approaches seem viable, and to
be honest, very few applications are likely to ever notice that.
If some Apple developer sees this, please talk to me about the fixes
needed in the tty driver -- this has been a known bug (to me at least)
for many years now.
Garrett D'Amore