really interesting comment - basically makes the case that TUIs and (line-oriented) CLIs need to do Unicode handling fundamentally differently, and so are kind of incompatible: https://github.com/kovidgoyal/kitty/issues/1978#issuecomment-1682023413
which suggests maybe it's best to have a different platform for TUI and CLI?
curious what you think @Luke Boswell!
I'm really not sure. I feel like maybe doesn't affect Roc's CLI platform as we aren't emulating a terminal. Roc apps using basic-cli
can be run in any terminal, and the platform doesn't really make any additional assumptions beyond that (other than support for stdin/stdout/stderr, raw/canonical modes etc).
This zulip thread was my last experiment with TUI app using basic-cli
. Below is an example of how I implemented the change cursor position with ANSI escapes. I'm assuming here that the terminal supports ANSI escapes. Maybe this is a similar story for unicode, where the platform makes no assumptions and the app developer is free to implement whatever suits their use-case.
cursorPosition : {row: I32, col: I32} -> Str
cursorPosition = \{row, col} ->
rowStr = row |> Num.toStr
colStr = col |> Num.toStr
"\u(001b)[\(rowStr);\(colStr)H"
I guess some experimentation with ZWJ (emoji) sequences might help to explore the limitations/capabilities of this further.
makes sense!
I also feel like it will be much clearer once we start experimenting with platform agnostic/independent effects. It will be easier to see how platforms might evolve and what kind of design would make simple UI's/interactive UX most friendly
Last updated: Jul 06 2025 at 12:14 UTC