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: Jose E. Marchesi
Subject: Re: [RFC] Convention for marking pretty-printers output
Date: Mon, 28 Oct 2019 09:36:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

    
    > 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.
    
Sounds awesome :)




reply via email to

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