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...
On Sun, Jul 24, 2016 at 11:51 PM, Joe Bryan <notificati...@github.com>
wrote:
> Thanks! That all makes sense, and is a big help.
>
> Adding background colors, we get:
>
> =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
> ++ styx (list $@(@t (pair styl styx))) :: styled text
> --
>
> ++styl is a triple ordered by reverse (expected) frequency -- that is, I
> expect foreground colors to be the most common use-case:
>
> ``%r
> `[%br %r]
>
> And we'll need this, of course:
>
> ++ mtrx [%k `%g]
>
> There's a little black magic in that $@ mold! I spent time testing
> variants with an explicit tape (?(tape (pair styl tape)), (list ?(tape
> (pair styl styx))), etc.) before realizing that all my use-cases were
> already covered:
>
> ^-(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
> expect these examples to render the same:
>
> ^-(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>,
> %sole-effect is rendered via %dill-blit %out (list @c) and %give %blit
> ~[[%lin (list @c)] ...]. (Note: :talk cheats with ++slog, at least for
> some use cases...) It seems simplest to amend ++dill-blit with something
> like:
>
> {$klr (list (pair styl (list @c)))}
>
> (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.
>
> Interpreting that move will obviously require enhancements to term.c:
> 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 email
to urbit-dev+unsubscr...@googlegroups.com.
To post to this group, send email to urbit-dev@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
