Re: Libtextstyle in Jitter and Poke: sub-package mode and CSS installation

[Jose E. Marchesi]

    On 2019-10-30 at 09:37 +0100, Jose E. Marchesi wrote:
    
    > I would have expected for the Jitter user (in this case poke) to provide
    > whatever customizations for the classes.  Jitter should provide a list
    > of these classes.
    
    But why?  It is fine if you want to override them because you dislike
    some default, but Jitter's classes are VM-independent, and only deal
    with VM code and disassembly.  There is nothing directly interesting for
    Poke there.

Ok, let's settle on some terminology:
- What you call "VM code" is what I call "PVM disassembly"
- What you call "disassembly" is what I call "native disassembly"

In PVM disassembly, I am using custom printers for several things,
particularly PVM values, which can be arrays, structs, closures and the
like.  These values use the same classes than the ones used at the REPL
to print values.

For the native disassembly, there yeah I agree, I don't care about
styling that :)
    
    > I achieve that using a custom printer:
    >
    > void
    > pvm_literal_printer (FILE *out, jitter_uint val)
    > {
    >   /* XXX what about out.  */
    >   fflush (out);
    >   pvm_print_val ((pvm_val) val, poke_obase, 0);
    >   pk_term_flush ();
    > }
    >
    > Note the flushing and the fact I'm not using `out'.
    
    The fact that you are *not* using out when doing your own printing is
    more interesting, to me.  Your printer, if I understand correctly,
    relies on the output being on stdout, and it would misbehave if you
    wanted to print a VM program to stderr or to an actual file, for
    example.

pvm_print_val uses pk_term_* services, which in turn use a global
poke_ostream that is styled after poke.css.

Still, I would like to get my poke_ostream thru an argument in the
custom printer, instead of having to rely on a global variable.

    > It is expressive.  But I don't understand why the user cannot print
    > structured literals with internal styling in the custom printers.  I am
    > doing exactly that right now.
    
    As long as I am not misunderstanding, your solution is good as a
    temporary fix.  But a good printer API should support output to any
    stream.

Yeah.

    Of course in the good printer API the FILE * argument will be replaced
    by something more abstract -- but not a libtextstyle stream, because
    libtextstyle might be unavailable or disabled.  It will be something
    abstract.
    
    And still, even if the printer received a libtextstyle stream as a
    parameter, that would not be helpful to you: my output style is for
    printing Jittery VM routines, while yours is for printing Poke's data.
    So they would be two different, incompatible streams.
    The literal printer should only see yours.

Just give me a void* pointer in the custom printers, and I will be
happy, I think... :)