🖨️ A more flexible API to specify output target

[kentookura]

I am experimenting with Nottui and would like to display diagnostics in my application. I am aware that terminal rendering used to be handled with notty.

From looking at the code in Tty, maybe this can be achieved by just exposing function that is a bit more flexible than display? I'd just like to pass my own formatter here: https://github.com/RedPRL/asai/blob/563566f2696ce258784215ba35bdd4ff89341410/src/tty/Tty.ml#L207

What I tried so far:

My best guess is to write a function display : Message.t Diagnostic.t -> ui, where ui is a wrapper around the image type of Notty. I could use the optional output argument of display, but it is not obvious to me how to hook the out_channel into my application. The toplevel of the UI is started by Ui_loop.run... which takes a Notty_unix.Term.t... into which I can pass an out_channel... This seems messy.

[kentookura]

I might drop Notty as well, but I am still interested in a slightly more flexible API.

[favonia]

@kentookura I agree the API is not great. The fundamental design headache is that OCaml does not provide a "universal I/O streams". Therefore, many libraries are forced to come up with their own interface to accept standard out_channel, buffers, etc. For example, the dst type in the uutf library:

https://erratique.ch/software/uutf/doc/Uutf/index.html#type-dst

I suppose we could generalize out the output in the same spirit, maybe even treating the Format.formatter as some form of (inefficient) "universal I/O streams".

[favonia]

@kentookura BTW, I don't immediately see how this can help your integration with Notty. Notty's formatter does not accept control characters at all, but we are sending out control characters directly. Therefore, if you plug Notty's formatter into the display function, it will complain about the control characters we output. Notty really wants to manage all control characters and ANSI coloring sequences does contain control characters.

[kentookura]

I am no longer using Notty, so that whole headache is gone.

[favonia]

@kentookura Alright, I'm closing this as "WONTFIX" then.

[kentookura]

Sure, but I am still interested in discussing a more flexible API in general.

[favonia]

@kentookura Alright. In general, the difficulty is to choose this "universal output stream" type. Some libraries define their own solutions. Sadly the standard library lacks one.

[kentookura]

@jonsterling

[mikeshulman]

I thought I might have another use case for this, namely compiling with js_of_ocaml and hooking the output into xterm.js to run in a browser. But it turned out to work fine to just use Sys_js.set_channel_flusher on stdout.

(End result: https://mikeshulman.github.io/jsnarya/. As you can see, the ANSI colors and highlighting work fine too.)

[kentookura]

Thought of this issue when reading this:

https://discuss.ocaml.org/t/an-amusing-use-of-first-class-modules-reading-from-plaintext-and-compressed-files/10073/