[racket-users] Re: Can `parameterize` work with pretty printing?

[Ryan Kramer]

I found `make-tentative-pretty-print-output-port` and 
`tentative-pretty-print-port-transfer` which looks like it might be the 
right way to go. I changed `write-now` as follows:

(define (write-now proc x port mode)
  (if (pretty-printing)
  (let* ([alt-port (make-tentative-pretty-print-output-port port

(pretty-print-columns)
(λ () 
(void)))]
 [_ (proc x alt-port mode)])
(tentative-pretty-print-port-transfer alt-port port))
  (let* ([alt-port (open-output-string)]
 [_ (proc x alt-port mode)]
 [str (get-output-string alt-port)])
(write-string str port

And it looks like it mostly works, except that now it seems to ignore my 
`prop:custom-print-quotable 'never`, or else I am missing it somewhere... 
I'll investigate more.


But I don't understand how the `overflow-thunk` of 
`make-tentative-pretty-print-output-port` should be used. From the docs: 
"The overflow-thunk procedure is called if more than width items are 
printed to the port or if a newline is printed to the port via 
pretty-print-newline; it can escape from the recursive print through a 
continuation as a shortcut, but overflow-thunk can also return, in which 
case it is called every time afterward that additional output is written to 
the port."

Does that mean its return value is ignored? It seems like it. And when (if 
ever) should I call `tentative-pretty-print-port-cancel` instead of 
`tentative-pretty-print-port-transfer`?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8aefe2fa-49bf-4d05-84c1-612a54d99ff5%40googlegroups.com.

[racket-users] Can `parameterize` work with pretty printing?

[Ryan Kramer]

I am `gen:custom-write` and `make-constructor-style-printer` on an object 
graph that may contain cycles. Within my custom write procedure, I use 
`parameterize` to register an object into dictionary and later in the 
writing process I can check that dictionary, detect the cycle, and do more 
custom write logic.

But I have noticed that sometimes that my `parameterize` has gone out of 
scope by the time the printer gets deeper into the object graph. I was able 
to work around this issue by using another port, then copying the result to 
the real port like this:

(define-syntax-rule (write-now proc x port mode)
  (let* ([alt-port (open-output-string)]
 [_ (proc x alt-port mode)]
 [str (get-output-string alt-port)])
(write-string str port)))

This is better than just doing `(proc x port mode)` because it always 
prints the string that I expect. However, it breaks pretty printing. I've 
noticed that the built-in pretty printing logic will sometimes hit the same 
leaf object multiple times, as if it is testing to see how wide the result 
is and backing up and trying again. Perhaps it can also delay evaluation? 
That would explain why my `parameterize` has ended.

Is there a way to use `parameterize` within custom write logic and keep 
pretty printing working? Is there a better approach I should take?



Additional Information
===
https://github.com/default-kramer/morsel/blob/master/morsel-lib/private/essence/base-query-printer.rkt#L22
The `write-now` macro, as written, is "correct but unpretty". I can change 
it to "incorrect but pretty" as follows:

(define-syntax-rule (write-now proc x port mode)
  (proc x port mode))


https://github.com/default-kramer/morsel/blob/master/morsel-lib/private/essence/from.rkt#L373
This is a test that fails in "incorrect but pretty" mode. Rackunit reports:

location:   from.rkt:373:2
actual:
  "(from #0=a/0 \"A\" (attach #1=b/1 \"B\" (attach #2=c/2 \"C\") #3=(list 
#0# #1# #2#)))"
expected:
  "(from a/0 \"A\" (attach b/1 \"B\" (attach c/2 \"C\") (list a/0 b/1 
c/2)))"


Here are two screenshots, one pretty and one unpretty:

[image: pretty.png]

[image: unpretty.png]

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/6369f1c7-a8a5-470e-af9f-ce1c133469ca%40googlegroups.com.