We could show case some example programs. My modified version of go-matrix, and of course proxima5!

Curses & ncurses have support for box drawing characters and such via the "ACS" terminfo entries. It would be nice to use these.

Last night's change busted wide characters on XTerm. Took a few hours to find the bug. Note that Windows was always fine.

Readme has some inconsistent uses of I & we, misstates Termbox where it means Tcell, and can generally improve from some minor language cleanups.

It sure would be useful to have a stock unicode test program, to help detect problems like #20

For terminfo, we should use the bell, or flash, perhaps depending on user configuration (and of course presence of the flash attribute)

Perhaps for library support we ought to just expose a separate Flash() API.

Note that Windows has special APIs for these, and in particular we should play the Alert message sound rather than using the legacy Beep API.

So $GOPATH handing is wrong on several levels.

First, $GOPATH can consist of multiple directories. So our attempt to look up a file using it as a single directory is broken.

Second, not everyone installs from source.

So probably the best place for this is in $HOME. Or maybe we can figure out a way to locate "library" or support files for Go? I'm not sure if such a thing exists.

The github API is busted, we should remove the status badges.

The license badge can be replaced with a static one.

Go lint reported a number of issues. Not all of them can/should be addressed (for example, adding "documentation" for a constant called KeyCtrlA doesn't seem to be very useful -- the name is self explanatory), but many of the issues were valid.

The CellBuffer implementation in particular needs improved documentation.

For display, we could allow programs to register "fallback" runes, e.g. in a game, we could use a fancy glyph from another language or the emoticons list, but fall back to a simpler ASCII if the terminal can't display it. Proposed API is:

screen.AddFallbackRune(rune orig, rune fallback)

I'm not proposing to support this at all for combining characters.

We'd like a global SetStyle() to set the default style on a terminal.

We'd like to be able to work with Cells, including getting and setting cells, so that we could for example make a program that just changes the an attribute while leaving other attributes unchanged, as well as contents. etc.

When using tcell for gaming (!!) it is convenient to know when the entire has been pushed to the terminal ... for example the normal Show() API spits out a bunch of bytes which can be buffered in the file, and Show() can return back before the bytes have drained fully.

In some cases, it may be possible to overfill the stream, causing excessively long backlogs. For systems that refresh frames often (e.g. with just a few msec delay between Show() invocations), it may be better to wait for the output file to completely drain before starting another invocation of Show().

When using legacy terminals (such as genuine vt100) we need to first emit the code to setup / enable the alternate character set, and only afterwards emit codes to enter/exit the mode.

The mouse terminfo entries we made up (smous, rmouse) may be unnecessary. In particular, I've discovered that ncurses has created a new pair of entries called "XM" and "xm". They are somewhat different.

XM appears to be the format used for enabling & disabling mice. It uses parameterized string with the sole parameter being 0 or 1 -- 1 indicates that mouse reports should be enabled, whereas 0 indicates the reverse.

xm is the the format used for mouse reports, and is also a parameterized string. The parameters are as follows: x, y, buttons, state -- where state is either 0 for a release, or 1 for a press. The x, y coordinates are presented normally, and button codes are encoded as per x11term but without the 32 added.

The xm string is a forward processor, and doesn't really help with going in the reverse direction, which is what we need. That is, it specifies how to create a mouse event, not how to parse one. Unfortunately, this means we need to retain our custom mouse event parsing code for the time being. Its unclear how xm= could be used by any program, although it does serve as a form of documentation for developers.

Good news is that the only mouse protocols that seem to be supported are via xterm's x10mouse (9, we never use), x11mouse (1000), DEC locator mode (which appears to be nearly completely undocumented and unused anywhere), and the extended 1001 (highlight tracking, we never use), 1003, 1002, 1005 and 1006 modes. All of these strings are supplied in the latest terminfo.src exclusively for xterm.

The upshot of this is that I think we can get away doing what we have been doing -- submitting just the escape sequences for 1000, 1003, and 1006 (in that order), and then parsing mouse events as we have been, preferring the SGR form, but supporting x11 events.

In the future, maybe we can create a data driven form of xm= that goes in the reverse direction... we could also use some kind of booleans to indicate fixed protocol parsing.

That said, its probably pretty unlikely that any new mouse reporting protocols are going to be created. The SGR mode supports pretty much anything you'd want to have in a terminal, especially when combined with SGR (1003) mode.

By providing a stub for the termios implementation, we can support compilation and inclusion in projects that need to build for plan9 or nacl. This will help folks using this code in larger projects that include both ui and server components. The UI component won't work if they need topsl, but also the programs can include some kind of fallback.

The benefit here is to help consumers having to known where it works, and where it doesn't.

We've pulled the encoding stuff out (and provided vastly better test coverage of it), so we can pull that code out from this repo and just use it from there.

Windows can report up to all eight mouse buttons. Go ahead and support them all. (XTerm maxes out at 3 mice, plus the wheel motion.)

The hazeltine 1500 cannot display '~'. Presumably we have to replace it with something else on output. I have no idea what.

That said, I've never seen this terminal. Do they exist anywhere anymore? This is extremely low priority.

Older terminals (VT100, etc.) had requirements to insert padding characters (usually zero bytes), based on a terminfo specified delay, which was given in msec. (or fractional msec). We need to insert the delay, figuring baud rate into the mix, by injecting the appropriate number of padding characters.

For some platforms (especially Linux, FreeBSD, Darwin) we could use the sycall package to get termio stuff. (Not sure about baud rates though --- those are constants but I don't know if the constants are available in the syscall package.)

Having these available via syscall would mean cross compilation for those platforms would be easier.

So some keys (control keys) are delivered with ch != 0, which breaks the termbox applications that always want Ch == 0 if the key code is not an actual rune.

We should pass a zero value for Ch when key code != KeyRune.

We want better documentation, please.

I made some bad assumptions that only UTF-8 would use richer character sets -- including combining character support.

Turns out I was wrong about that. GB18030 can do everything UTF-8 can do. We need to fix that.

Recent changes to the code base sadly broke our nice Wide character support. The change that busted it was #3 -- we optimized, but we didn't recalculate for full width characters.

It turns out that buffering is something we should just do by default. The separate buffering implementation leads to suboptimal implementation, which is covered by #3

We should just use a buffered implementation everywhere.

We need to call use_env(FALSE) before reading TERMINFO variables here.

Some terminals (many) have only support for one or more 8-bit languages. For example, Latin1 (8859-1) is very common.

We could look at $LANG (or LC_CTYPE or somesuch) and make a decision to convert our output to whatever form is appropriate for the given locale.

Bonus points: If we have #15 done, we could also check for support for certain special characters like pi, the UK pound sterling, etc. and translate those using ACS characters. Its unclear at this time if that's actually worthwhile.

Mouse.go demo program has program comment from boxes.go

The mouse demo needs to have fixes to work with non-color terminals -- it panics, and even if the panic is fixed, the colors are ugly.

Also, we should support creating selection boxes, etc. Make this much much nicer.

We'd like to express a better way for an application to check if it can display a particular rune.

This is pulled from #44 , and done in combination with #45

Some character sets can cope with full width characters, not just Unicode.

We should assume that the width on translation is valid, if the translation was not "?", and preserve the width.

We can add a few more key codes:

F13 through F64
KeyClear
KeyCancel
KeyExit
KeyPrint

Also some things were missing for KeyInsert and KeyDelete

While testing gomatrix, which runs lots of threads in parallel, I found out that on shut down the threads would continue to update the screen, resulting in garbage on shut down.

The JSON output from mkinfo is not stable, because the Go runtime randomizes the enumeration order of maps. We should sort the aliases array, so that the database format doesn't change each time. This will drastically reduce the size of diffs in git output.

On Windows, we the naive use of SetCell winds up having us operate suboptimally. We could be smarter here by grouping updates together.

To make this efficient, we really need to have a higher level API available for use by the BufferedScreen writer that can request the bottom layer to defer updates and then flush the entire screen.

The current Screen API is inadequate for this. Perhaps what is desired is a NewBufferedScreen() optional method on Screens; this could then allow the Windows API to create a dedicated buffered writer that does this.

Another option would be to offer an optional switch to turn off immediate writes. Not sure what is more natural.

Only terminals that advertise mouse support should be parsed for mice. This can avoid possible conflicts with other usages of conflicting strings on older terminals.

We can simplify the encoding logic so we aren't special casing UTF-8 and ASCII anymore.

Lets provide a cleaner version of the common encoding support.

While here, let's provide transformers for ASCII, ISO-Latin1, and ISO-Latin5. This should greatly expand the reach of the app, and give more correct results for people actually living in ISO 8859-1 locales (rather than the 8859-15 hack we had.)

While testing, I noticed that I somehow broke entry of non-ASCII runes when not running in a UTF-8 locale. This is trivially noticeable in the mouse.go demo.

To test it, try setting the locale in MacOS Terminal to something else, and make sure your shell and terminal are in agreement. Then you can use Unicode Hex Input to enter Unicode data points, and they will be translated as appropriate to the locale by Terminal, before delivery to the application input.

Or, you can do like I do and cut-and-paste from unicode.go, or even set the keyboard to another language (such as Russian) and try typing Russian.

While trying to write to the event channel we are holding a lock. If the channel overfills, we can wind up deadlocking, as the consumer may need that lock.

Let's do two things.

First deepen the channel, which reduces the likelihood of hitting this.
Second, if we can't push an event on the queue, just drop it. These are window, mouse, and keyboard events. Its not nice to drop them, but if e.g. a keyboard buffer overfills, those events are dropped too.

So that's about the best we can do.

Noticed that when I resized a window with a different background (with gomatrix), that the new areas of the window were unpainted (because they were dirty).

We'd like to have some self tests, and a harness to support testing more functionality.

In fact, a "Simulation" that is just backed by a memory would be incredibly helpful to facilitate a wide variety of tests, and would be useful for folks who want to test higher level code / frameworks that are built on tcell (like topsl.)

Both XTerm and Windows have the ability to change the title on the window. We should expose that.

I've noticed that when running this with a program like sokoban, which continuously refreshes the display -- writing first an underlying value, then a a different upper layer, that we wind up thinking that these are invalidating the backing buffer; even though the end state is the same.

This causes a lot of cursor activity on, which it turns out is only visible when running a terminal that cannot hide the cursor (ANSI is a good one).

The other thing that running sokoban helped me to identify, is that things suck badly when the application wants to hide the cursor. The onscreen cursor is left in some strange place on the screen, and confuses the heck out of the user. (In the sokoban game, it can lead to confusion between the boxes on screen.)

So, when we finish drawing, if the application has requested that the cursor be hidden, lets actually just move it to the lower right corner of the screen. Its far from ideal, but its far better than leaving it floating around elsewhere on the screen.

So the fix for this involves a new common CellBuffer, that handles most of these things. The beauty of this is that cell structures are hidden from the application, and we can get a nicer API, and more code commonality between the three different screen implementations (terminfo, windows, and simulation.)

We'd like to expose some functions, e.g. for games programming, that gave hints as to the underlying API. For example:

HasMouse()
CanDisplay(rune)
HasKey(key)

This would also be useful for programs that want to e.g. decorate windows -- for example, no point in display "F1 for help" if the terminal has no F1 definition... better to say "ESC-1 for help" in that case.

Sadly the info we get won't necessarily be totally accurate -- for example, just because a mouse is supported by XTerm doesn't mean one is present, and who knows how many buttons are present. Likewise, key definitions may exist but not be present on an actual implementation.

Still, we should offer up what info we do have.

A few ideas here.

First, we should try to use SGR mode (1006h) if possible, after enabling the mouse.
Second, we should try to use button move events (1002h), to record relative mouse motion.
Finally, we can optionally add support for recording mouse motion events, although its unclear to me whether that is actually useful. My feeling is that button motion events (e.g. for drawing rectangles) is likely to be far far more useful.

Not all terminals support the extended modes; however it should be possible to distinguish the different report types, and further it should be possible to send all these escapes and hope that terminals that don't understand them will just ignore them.

(It appears that this is largely true; although my sample set is rather small. Certainly MacOS Terminal understands none of these, while iTerm 2 understands them all, as does modern XTerm.)

Reverse video does not work as doc'd. Apparently it only works for DBCS, not Unicode. We can reverse it ourselves instead. (Underline has the issue as well, but we cannot do anything about it.)