poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Convention for marking pretty-printers output


From: Bruno Haible
Subject: Re: [RFC] Convention for marking pretty-printers output
Date: Mon, 28 Oct 2019 02:35:01 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-165-generic; KDE/5.18.0; x86_64; ; )

Hi José,

> actually I want to support multi-line output as well.
>     
>     I'm asking because the algorithm used for this purpose in
>     Common Lisp [1] is not really good: it has the tendency to move to
>     the right border quickly and then produce many lines of output,
>     each beginning with 60 or more spaces. There are better ones.
> 
> Do you know of some free software program implementing the better ones?

Yes, GNU CLISP has one of the better ones :)

Its pretty-printer is in the CLISP core; therefore it requires some work
to make it work outside of CLISP.

The plan would be as follows:

  * I add to libtextstyle an ostream subclass 'pprint_ostream', that
    encapsulates a styled_ostream and provides the following interface:
    - a constructor that specifies a couple of parameters:
        - number of available screen columns,
        - maximum depth for nested lists,
        - maximum length of lists,
        - where to place closing parentheses/braces,
        - whether to print a newline before multiline objects.
    - the styled_ostream interface,
    - methods like
        open_parenthesis()
        close_parenthesis()
        open_brace()
        close_brace()
        indent_start(delta)
        indent_end()
        justify_start(n)      - starts a justify block
        justify_space()       - separates two elements of a justify block
        justify_end_fill()    - collects short blocks even in multi-liners into 
one line
        justify_end_linear()  - in multi-liners each block occupies its own line
        ...

  * You allocate an instance of 'pprint_ostream' and use it everywhere
    where you currently use a 'styled_ostream'. Additionally, you insert
    function calls to the methods listed above, in order to tell the
    pretty-printer where logical blocks begin and end, where you want
    justified text blocks, and so on.

  * The pprint_ostream does all the rest, by reorganizing blocks of text
    (with interspersed styling commands!) depending on the available space.

It's nice that styling does not change the width of a text block. Therefore
it's possible to do the pretty-printing *before* the styling gets executed.
This has the advantage that I'll one implementation of 'pprint_ostream',
not different ones for term_styled_ostream and html_styled_ostream.

Such a pretty-printer would be reusable by gdb, for JSON, etc.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]