Add hiccup and/or html output in addition to ANSI

[sbitteker]

It would be cool to add hiccup and/or html output in addition to ANSI to czprint. For instance you could add ...

(s/def ::color-output-types #{:ansi :hiccup :html})
(s/def ::color-output ::color-output-types)

where ANSI is the default for backward compatibility with :color? switch, if the new :color-output is not defined.
converting color-str in ansi.cljc to a defmethod trio for ansi, hiccup and html.

(defn color-str
"Wraps a string with hiccup expressions."
[s & ansi]
(let [style-str (apply str (interpose ; (map html-codes ansi)))]
[:span {:style style-str} s]))

html-codes might look something like this

(def html-codes
{:bold "font-weight:bold"
:faint "opacity:50%"
:italic "font-style:italic",
:underline "text-decoration: underline"
:blink ""
:reverse ""
:hidden "display: none"
:strike "text-decoration: line-through"
:normal "text-decoration: none"
:italic-off "font-style:normal"
:underline-off "font-style:normal"
:blink-off ""
:reverse-off ""
:hidden-off "display: unset"
:strike-off "text-decoration: none"
:black "color:black"
; ....
})

[kkinnear]

An interesting idea, and one that came up many years ago. I didn't pursue it because, unlike most programmers these days, I don't spend my days writing code that eventually shows up in a browser -- so I don't know what the correct output would look like. I spent some time looking at some peoples html for code, and it was all over the map, or at least that is my memory.

I'm interested in your use case for the hiccup or html output.

You have sketched in some ideas on how to pursue this, above, and maybe that is all I would need. But I expect that to make this move forward it would take a good bit of back and forth to it to work. I think there are a few things that are needed before I jump into this:

1. Some idea of your use case.
2. Some sense from you of how generally useful this might be.
3. Some examples from you of what you would expect to see in the html output. Maybe you've done that above, I haven't studied it in detail yet.
4. Your willingness to answer questions and look over intermediate results (and probably try an alpha version or two) as this moves forward.

I'm open to pursuing this (modulo some sense of how useful this might be to people), and I'm willing to try to figure out the code, but I'm not willing to go it alone. It is worth knowing that I'm not positive if this is even possible given the current architecture of zprint, though I expect that it is. There is an intermediate format for the output that is currently post-processed into the ANSI format, and it would probably be possible post-process it into a variety of other output formats pretty easily.

Anyway, let me know how your thoughts, and we'll see where we go from there. If you don't hear back from me quickly, it will be because of the holidays.

[sbitteker]

Thank you for your reply and considering adding this feature!

In my case, I'm already using zprint within a hiccup :pre tag. It's already nicely intended from zprint and colorizing would be the next step.

[:pre (zp/zprint-str (the-code column-width indent-cfg)]

Showing the formatted code from a webpage (or in my case a REST service) is to allow transparency of the derived field's business logic. The number of lines in my case can range from 1 to about 300. This type of functionality of code-to-html exists on Github and Bitbucket for instance, with the addition of line numbering and stripping, but to my knowledge it doesn't exist as a standalone jar like zprint. Another use case might be to format and colorize code on a webpage from cljs as you're editing it for display purposes (or something else) before saving to the data store.

I cloned zprint and quickly added in part what I described above to see if it would work before I posed the question. Effectively instead of wrapping the code string with ANSI escape characters, you're substituting with or [:span] and the html color and possible style(s).

Similar to the current ANSI functionality (czprint) where you can define various indent parameters and colors for different language tokens the same could hold true for the hiccup/html wrappers. I imagine the correct output looks similar to the ANSI colorized and indented output you'd see in a command line.

I'd be willing to test, comment, discuss, contribute and debug this functionality with/for you.

[kkinnear]

My apologies for letting this slide for so long. I'm still getting my head around "discussions", and I lost track of this because it wasn't an "issue". I didn't even see the "Create issue from discussion" button before. Sigh.

So, on closer examination, it looks like you have largely (or completely?) implemented the :hiccup output format? If that is the case, I'm certainly all for integrating it into zprint.

To be painfully clear, the problem I have is that I'm not particularly familiar with either :hiccup or html. Despite html being a big part of what many programmers do these days, my knowledge of html is more or less at the level of "yes, that sure looks like html". I've used Clojure to generate some nifty SVG pictures of sequence diagrams, but I wasn't really working at the html level. So if the changes you suggest above truly generate :hiccup output that would turn into html, then that's really great! But I'm not able to verify if it is 90% of a solution or 10% of a solution by just looking at it. I can certainly try it out and see what comes out. And I will. I'm a little hesitant as I don't know how much effort maintenance might be, but I'll cross that bridge when I come to it.

What are you thinking for actual html output? Are you thinking of using hiccup directly to turn the :hiccup output into html, or is there some other approach you had in mind? I have worked very hard to reduce the dependency footprint for zprint, so I'm not all that excited about adding hiccup to it. Ideally, zprint would product :ansi or :hiccup output and if you want html, you will use hiccup yourself to generate it. If you really want zprint to produce html (assuming you don't have some brilliant hack to do so directly), I could see connecting to hiccup if it was available, which would not burden people who don't care about that capability with another library. I've done that before in zprint, though it has been some years. I'm also not sure how it would work now that I produce graalVM binaries, so that remains something that might well not happen.

Anyway, let me know how you were thinking to produce html, and I'll see about hacking what you've done into zprint as a feasibility test.

[kkinnear]

So, I've been experimenting with what you sketched in. I have something working, but I don't feel confident in the results.

Here is what I'm testing with, at the REPL:

(zprint i229s {:parse-string? true})
(assoc my-map
  :key1 :val1
  :key2 :val2)

If I get it to generate :hiccup output, and then turn it into html, here is what I get:

(zprint-str i229s {:parse-string? true :output {:format :hiccup} :color? true})
[:p {:style "font-family: Courier, monospace"} [:span {:style "color:green"} "("] [:span {:style "color:blue"} "assoc"] [:span {:style "color:black"} "&nbsp"] [:span {:style "color:black"} "my-map"] [:span {:style "color:black"} "<br>&nbsp&nbsp"] [:span {:style "color:magenta"} ":key1"] [:span {:style "color:black"} "&nbsp"] [:span {:style "color:magenta"} ":val1"] [:span {:style "color:black"} "<br>&nbsp&nbsp"] [:span {:style "color:magenta"} ":key2"] [:span {:style "color:black"} "&nbsp"] [:span {:style "color:magenta"} ":val2"] [:span {:style "color:green"} ")"]]
zprint.core=> (html *1)
"<p style=\"font-family: Courier, monospace\"><span style=\"color:green\">(</span><span style=\"color:blue\">assoc</span><span style=\"color:black\">&nbsp</span><span style=\"color:black\">my-map</span><span style=\"color:black\"><br>&nbsp&nbsp</span><span style=\"color:magenta\">:key1</span><span style=\"color:black\">&nbsp</span><span style=\"color:magenta\">:val1</span><span style=\"color:black\"><br>&nbsp&nbsp</span><span style=\"color:magenta\">:key2</span><span style=\"color:black\">&nbsp</span><span style=\"color:magenta\">:val2</span><span style=\"color:green\">)</span></p>"

If I put that in a file and display it with Safari on my Mac, it looks fine.

My questions:

1. Is &nbsp really how to do spaces?
2. Is the :p the right way (or at least an ok way) to get a monospaced font?
3. Does it make sense to make the font-size something external to the zprint output?
4. Does this produce something that you could actually use?
5. Can you live with having to process the :hiccup output yourself, and not having zprint product html directly?

Thanks!

[kkinnear]

So, I've been moving forward on this, and I've gotten the both :hiccup and :html output working (without using the actual hiccup library). The conversion to from :hiccup output to .html was trivial, given that my :hiccup output is highly constrained. I made the style for the paragraph configurable as a string, so you can have whatever font and size you want. Are you interested, at this late date, in reviewing any of the output? If so, let me know, otherwise I'll probably just release it when I next release zprint. Thanks!