[urbit] Re: [urbit/arvo] colored output requirements (#212)

[Curtis Yarvin]

I don't know enough about the usage of background colors. I would ask: do
any IRC clients, etc, use these? Are they universally supported by modern
ANSI terminal sequence recognizers?

The four-letter-word game isn't any fun unless you actually have to stick
to Scrabble words. I would suggest: ++tint, ++deco, ++styx.

I am happy to dispute your feeling that colored output should be available
at a lower level. I think it's really only for interactive use. The use
of a ++tank (or hopefully soon ++tanq) is that it gives the programmer very
little leeway to style the output; in fact, ++tanq is even more easy to
build and restrictive for a reason. Eg, a Hoon AST (twig) is a tree and
++tank builds trees, but a ++tank is not a pretty-printer for Hoon.

There are two kinds of text output: interactive and diagnostic.
Interactive output goes to the console as a sole-effect. Anything a
generator produces is diagnostic output -- or at least, that's how we think
about it now. The primary demand of diagnostic output is that it never
breaks, ever. Nothing is more infuriating than a crash in rendering your
diagnostics. So it has to be incredibly easy to generate, simple and
stupid, which ++tank is and ++tanq is even more. I wouldn't want to go in
the opposite direction.

You could certainly imagine, however, a mark transformation that
transformed your data structure either to a tank, or to a styled text
document, or perhaps to HTML. On the web you'd see HTML, in a terminal
styled text. So I'm not saying that styled text output from generators is
impossible; I would do the interactive use case first.

As for the actual molds, your design is perfectly serviceable. But most
styled text is likely to be just text. So going from "foobar" as ++tape,
to "[[~ ~ "foobar"] ~]" as ++styl, is a little annoying. What about:

++ tint ?($~ $r $g $b $c $m $y $k $w)
++ deco ?($~ $bl $br $un)
++ styx (list $@(@t (pair (pair deco tint) styx)))

What did we do here? We disambiguate an unstyled atomic text block against
a styled subtree. So "foobar" is also a ++styx. We pair the color and
decoration, because they may be built as an integrated style. We allow
text atoms of any length, so ['foobar' ~] is a ++styx as well. Then the
new sole-effect page is {$sty p/styx}. You could even make the deco and
tint units, creating snazzy cascading styles (~ inherits the parent's
style).

Also, at least as important as colored output is a colored *prompt*. This
would certainly help with the constant prompt confusion we suffer from...
fortunately this is also a sole protocol.

Helpful? Thoughts?

continuing the conversation from #203
<https://github.com/urbit/arvo/pull/203> ...
++ kulr ?($~ $r $g $b $c $m $y $k $w) :: color or default
++ decr ?($~ $bl $br $un) :: decor or default
++ styl (trel kulr decr tape) :: inline text
These seem to fall naturally out of basic terminal color/style support
(and the relevant ANSI codes...). A color is one of R/G/B, C/M/Y/K, white,
or null. A text decoration is blink, bright, underscore, or null. And a
piece of styled, inline text is a triple of color, decoration, and the text
itself. A line of output is therefore (list styl).
*(I'm making the assumption that background colors, hidden text, reversed
text, etc. are out of scope.)*
Wrapping this up as a ++sole-effect is pretty straightforward; something
like: {$klr p/(list styl)}. However, I can't shake the feeling that
colored output should be available at a lower level ...
The obvious use-cases are generators and unlinked apps that produce output
in response to pokes (as :hood does with |sync, |merge, etc.). I know the
long-term plan is for syslog-style output to be sent to a :talk channel,
but, even then, ++sole-effect doesn't quite feel natural...
If this were to be added to ++tank, I'd propose something like {$vein
p/styl}, and maybe even {$leaf p/?(tape (list {$vein styl}))}. I'm not
sure how it could fit with ++tanq.
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/212>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALyAZpe1LcaZKv-lq_rRbkJhbTgq4EQks5qYsZ9gaJpZM4JTe9e>
.

[Curtis Yarvin]

You seem well enough engaged with this problem, so please consider these
suggestions no more than advisory...

I kind of want [bg fg] to be a pair. But it would be nitpicking.

I considered regarding the default in your ++tint and ++deco as a unit
case. I don't think that's right, though. If it was right, it's a little
tacky to build in the null to a data structure; ++deco should be {$bl $br
$un}, etc. If it's *not* right, "default" actually means something
semantically; it's a mysterious color or decoration defined by the terminal
but not by the protocol. In this case, `~` should *not* inherit, because
then there's no way to get back to "default" within a nested span.

It would be ideal to get the breaking change in sooner rather than later,
because we have a big breaking change scheduled for August. Admittedly it
doesn't change the term.c interface. But there is simply no way to upgrade
the Urbit interpreter over the wire.

Alternatively, %blit could apply the ANSI codes itself and just rely on
them slipping gracefully into term.c, even though this is architecturally
very bad. On the other hand, it could keep the change non-breaking.

~& is never output and nothing, including :talk, should rely on it :-)

I forget where splitting of long lines happen. Isn't it performed at the
very end in term.c? If so, I would keep it that way. It's true that the
terminal tells us its preferred line width, but...

Thanks! That all makes sense, and is a big help.
=x |%
++ tint ?($~ $r $g $b $c $m $y $k $w) :: text color
++ deco ?($~ $bl $br $un) :: text decoration
++ styl (trel tint deco tint) :: bg/deco/fg
--
++styl is a triple ordered by reverse (expected) frequency -- that is, I
``%r
`[%br %r]
++ mtrx [%k `%g]
variants with an explicit tape (?(tape (pair styl tape)), (list ?(tape
(pair styl styx))), etc.) before realizing that all my use-cases were
^-(styx:x "foo")
^-(styx:x ~['f' [``%r "o"] 'o']))
^-(styx:x :(welp "f" [``%r "o"]~ "o"))
^-(styx:x :(welp "foo" [``%r "bar"]~ [``%g "baz"]~))
^-(styx:x ~[[``%r "foo"] [``%g "bar"] [``%b "baz"]])
As for inherited/cascading styles, I don't think we need a ++unit --
there's already an outer list, so the only reason to nest is to inherit.
And both ++tint and ++deco already include null. In other words, I'd
^-(styx:x ~['f' [``%r ~['o' [`[%un ~] "o"]]]])
^-(styx:x ~['f' [``%r "o"] [`[%un %r] "o"]])
As I described in #214 <https://github.com/urbit/arvo/issues/214>,
some use cases...) It seems simplest to amend ++dill-blit with something
(and maybe short-circuit ++blit?)
That move would be produced by flattening ++styx, applying ++trip and
++tuba, reifying inherited and implicit ++styl, and splitting long lines
into multiple moves.
what does the upgrade path look like for a change that affects bin/urbit
and Arvo? Is there a mechanism for graceful degradation (such as a facility
within Arvo to probe the binary for capabilities), or do you just push the
breaking change and announce that everybody needs to build?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/212#issuecomment-234854497>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALyAVX3y5rRVWFLJSAjpwjjsOgQ8aIOks5qZFzzgaJpZM4JTe9e>
.

[Travis J I Corcoran]

Joining this thread late, and without context, but it looks like we're
discussing text decoration in the terminal?

If so, one request and one comment:

* request: it should be possible to turn it off, for those times when one
is forced to use a color-free terminal (typically color markup displays as
cruft in that case)
* comment: as of a year or so ago, the terminal code blew up when invoked
inside of an emacs shell; until we get around to rewriting emacs in Hoon [
:) ], the ability to run urbit inside there would be nice.

TJIC

Post by Curtis Yarvin
You seem well enough engaged with this problem, so please consider these
suggestions no more than advisory...
I kind of want [bg fg] to be a pair. But it would be nitpicking.
I considered regarding the default in your ++tint and ++deco as a unit
case. I don't think that's right, though. If it was right, it's a little
tacky to build in the null to a data structure; ++deco should be {$bl $br
$un}, etc. If it's *not* right, "default" actually means something
semantically; it's a mysterious color or decoration defined by the terminal
but not by the protocol. In this case, `~` should *not* inherit, because
then there's no way to get back to "default" within a nested span.
It would be ideal to get the breaking change in sooner rather than later,
because we have a big breaking change scheduled for August. Admittedly it
doesn't change the term.c interface. But there is simply no way to upgrade
the Urbit interpreter over the wire.
Alternatively, %blit could apply the ANSI codes itself and just rely on
them slipping gracefully into term.c, even though this is architecturally
very bad. On the other hand, it could keep the change non-breaking.
~& is never output and nothing, including :talk, should rely on it :-)
I forget where splitting of long lines happen. Isn't it performed at the
very end in term.c? If so, I would keep it that way. It's true that the
terminal tells us its preferred line width, but...

Thanks! That all makes sense, and is a big help.
=x |%
++ tint ?($~ $r $g $b $c $m $y $k $w) :: text color
++ deco ?($~ $bl $br $un) :: text decoration
++ styl (trel tint deco tint) :: bg/deco/fg
--
++styl is a triple ordered by reverse (expected) frequency -- that is, I
``%r
`[%br %r]
++ mtrx [%k `%g]
variants with an explicit tape (?(tape (pair styl tape)), (list ?(tape
(pair styl styx))), etc.) before realizing that all my use-cases were
^-(styx:x "foo")
^-(styx:x ~['f' [``%r "o"] 'o']))
^-(styx:x :(welp "f" [``%r "o"]~ "o"))
^-(styx:x :(welp "foo" [``%r "bar"]~ [``%g "baz"]~))
^-(styx:x ~[[``%r "foo"] [``%g "bar"] [``%b "baz"]])
As for inherited/cascading styles, I don't think we need a ++unit --
there's already an outer list, so the only reason to nest is to inherit.
And both ++tint and ++deco already include null. In other words, I'd
^-(styx:x ~['f' [``%r ~['o' [`[%un ~] "o"]]]])
^-(styx:x ~['f' [``%r "o"] [`[%un %r] "o"]])
As I described in #214 <https://github.com/urbit/arvo/issues/214>,
some use cases...) It seems simplest to amend ++dill-blit with something
(and maybe short-circuit ++blit?)
That move would be produced by flattening ++styx, applying ++trip and
++tuba, reifying inherited and implicit ++styl, and splitting long lines
into multiple moves.
what does the upgrade path look like for a change that affects bin/urbit
and Arvo? Is there a mechanism for graceful degradation (such as a facility
within Arvo to probe the binary for capabilities), or do you just push the
breaking change and announce that everybody needs to build?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/212#issuecomment-234854497>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALyAVX3y5rRVWFLJSAjpwjjsOgQ8aIOks5qZFzzgaJpZM4JTe9e>
.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.