The road to tcell 3.0

[gdamore]

I think it's time to start thinking about what tcell 3.0 might look like.

There are many changes I'd like to make, which require potentially breaking changes. It's time to discuss what those would be, and solicit feedback.

Key Encoding Changes

First off, we need to remove definitions for KeyCtrl[A-Z] etc. Those won't work well going forward because they overlap with other key definitions, and were based on compatibility of the ASCII encodings. These already don't work that way on Windows, but we have a serious problem where e.g. KeyCtrlH occupies the same encoding as KeyBackspace (these are aliases for each other). This happens with a few of these, and is a throw back to old style TTYs.

I would discard the KeyCtrlXXX symbols altogether. Modified keys would be presented as such. For the times when we have an overlap of e.g. Ctrl-I is TAB, we would just report as TAB. On most modern terminals these would be unambiguously handled by the CSI-u encoding scheme proposed in #671. (This is already the case on Windows.)

Retiring Termbox compatibility

The termbox compatibility layer is abandonware. People who want to convert to tcell gradually would be able to use version 2.x, but moving to 3.x they would need to actually update their code. I don't think many (if any) projects are actually using the termbox layer anyway. There are semantic shortcomings that would be difficult to overcome if we tried to keep this compatibility, and I don't think it's worth doing for termbox.

Retiring support for the legacy Windows console API

At least for output (not sure about input), the VT mode on Windows is vastly superior. This might hurt Windows versions before Windows 10. But Windows 8 is EOL.

Adopting modern Go.

We would move to probably Go 1.20 or newer. This could allow using generics for example, or possibly other things. We can't support the old versions of Go forever.

Removing the PollEvent based API.

This is probably controversial, and would require many (most) applications to change. The PollEvent API is awkward and not very idiomatic for Go. The ChannelEvents() API (possibly with some refinement) would become "standard".

PostEvent and PostEventWait especially need to be removed.

Retire support for ancient terminals

I'm specifically talking about the ancient Wyse, TVI925, and similar. We simply don't see them in the wild, and we can't test them. While the idea of having good fallbacks and a rich terminal database was a worthy ideal, in practice it hasn't been useful, and keeping this support means we have bloated terminfo databases that nobody can use. Probably there are some other outliers, like beterm, that could be removed without much of anyone noticing.

Revisiting the API around SetContent, GetContent

Today these are use a single rune, and optional array of combining rules. It would be simpler by far to just make this a string. The rule is that the first fully composed glyph from the string would be displayed. Possibly we could actually give a feedback about how many bytes were consumed from the string.

Remove views framework

The "views" package was an early effort at building a widget set on top of tcell. It sort of works, but it's also sort of abandonware. There are others that have done a better job here. And maybe even views could move into its own package and be expanded separately.

Combining HideCursor, ShowCursor, SetCursorStyle somehow...

This API feels like it evolved organically -- it did -- and could probably be revisited in some way.

Retiring CharacterSet API

Nobody has ever used this I think. It does nobody any good. We need to remove it.

Summary

This is a lot of potential breaking change. But we could do it if we had a major release boundary. We'd need a migration guide of course. But I don't think that would be too hard to do.

[vlappa]

Ok, then for version 3.0 https://go.dev/blog/module-compatibility ;)

[eNV25]

The whole point of version 3 is that you can do breaking changes.

[vlappa]

The whole point of Go is to be as compatible as possible that's all I'm saying. Here another interesting piece.

https://go.dev/blog/randv2

[Bios-Marcel]

May I ask why you are planning to remove PostEvent*? I don't care for it, but the explanation would be interesting. @gdamore

Regarding all the breaking changes. I'd say go for it! If people need this backwards compatibility, the README could simply link the features that are removed with v3, so people know which version to use. Given go uses tags for versions, changes can easily be backported via a separate branch anyway, in case any heavy bugs occur.

[gdamore]

PostEvent is brittle. There are non-blocking forms, but the blocking API winds up creating a potential application deadlock. I'd really prefer that users get this via channel, and then they can make a clear decision about whether or not to block, or to multiplex on a select statement as they need.

[gdamore]

If I switch to a version 3, I will probably relegate maintenance for version 2 to critical fixes only. I have zero interest in doing feature work for multiple versions at once. Even non-critical bug fixes probably won't get backported.

[Bios-Marcel]

Ah yeah ... right, the channel could be used for both posting and reading, this way tcell wouldn't even have to know about the simulated events. I didn't think that far.

Regarding not backporting, that's absolutely fair :D

[eNV25]

Removing the PollEvent based API.

Would it be possible to expose the Events channel directly? Are there any disadvantages to doing so?

(Screen) Events() <-chan Event

This is a read-only channel because we probably don't want the user closing this channel. We use (Screen) Fini() for that.

The ChannelEvents() API (possibly with some refinement) would become "standard".

We should consider using a context.Context instead of a quit channel to signal cancellation.

(Screen) ChannelEvents(ctx context.Context, evs chan<- Event)

[gdamore]

Agreed. This API evolved before go Contexts existed. :-)

[gdamore]

I suspect we could expose the Events channel.... although I need to refresh my brain to ensure that there were no compelling reasons for not doing so.

One key thing is that if a legacy user is using the PollEvent api, then that might be confused by another consumer pulling from the Events channel.

I'm half inclined to just expose the channel and insist that users consume from that. It's nicer that way.

We do need a way for the application to signal a graceful shut down for us. I guess a context would do.