gdamore / dcell Goto Github PK

We should try to make as much of our API @safe as possible... with just a few instances of @trusted where needed.

The handling for graphemes is a bit dodgy at present -- we use a string text, but there is a grapheme data structure that might be better for this purpose in std.uni.

We currently add capabilities in a few places, and some duplication exists in mkinfo, database.d, and parser.d.

It might be nice to have some kind of map that that has different actions. We could also amend many defaults as long as they don't conflict, for the input parsing. Almost everyone uses the Xterm definitions.

Output is a little trickier.

Possibly this would be best done in a single TermInfo structure.

JIT terminal definitions can be scraped from terminfo, using infocmp on the fly in the same way that mkinfo does.

Tcell does this nicely -- we should too. This will help folks who have unusual terminal settings.

We need to test with LDC2 as well as DMD.

We need to audit --we're missing a few we wish we didn't.

We should look at supporting the following:

is1, is2, is3 - usually only is2 is present
smcup and rmcup - these enter and exit the alternate screen buffer, but may have other uses

Writing a string to a given X, Y location is a pain. We should really provide a convenience for this.

Perhaps just allowing a string to be written at an X, Y via index operators.

When supporting wide characters we need to support it.

It might be be nice to allow an application to poll the input scanner without requiring an actual second thread. This would permit some use cases where threading is problematic.

Focus events are apparently reasonably widely supported -- we should support them.

It would be good to be able to display strings for some events ... the key events has some of this already, but we need it for mice, etc.

We are relying on a hacky bespoke algorithm to parse escape sequences, but it is inefficient as we have to scan all possibility each time a a character is added. Using a trie would let us quickly match the character. We could also keep some kind of state about progress in the trie in the parser.

This is probably a substantial performance improvement on input parsing, although input parsing is probably not a super performance sensitive concern for most applications. The current hacky solution seems to work well enough to be reasonably responsive for most cases.

Tcell does this via ACSC, but also supports user-modifiable fallback maps. It would be kind of cool to support this here.

This looks like a problem with the approach we are using for terminfo -- perhaps I botched an ioctl code?

Trivially observable with the demo apps.

We would like to support the Windows console API.

It would be nice to be able to lookup a color by name (using a user entered string, such as from a theme file). We should provide a list of well known names in string form. And probably methods to go back and forwards.