fix: render text/html display_data output instead of raw IPython repr

[merlinran]

When a kernel cell produces a rich display object like
IPython.display.HTML, the display_data message includes both
text/html (the actual content) and text/plain (the Python repr,
e.g. <IPython.core.display.HTML object>).

All three display_output paths — colab exec, colab run, and
the REPL — only checked for text/plain in the data dict and printed
that raw repr, which is useless to the user.

This adds a text/html branch ahead of the text/plain fallback
in all three locations. HTML tags are stripped for terminal display
via html.parser.HTMLParser. The result isn't a full HTML renderer,
but it surfaces the actual content — which is a clear improvement
over the current behavior of printing the Python object repr.

Fixes in:

• execution.py — display_output()
• automation.py — inline output loop in run_automation()
• repl.py — ColabREPL.display_output()

[merlinran]

Before:

Starting training...

<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
<IPython.core.display.HTML object>
...

After:

Starting training...





      [   2/1075 : < :, Epoch 0.00/5]




      Step
      Training Loss
      Validation Loss









      [   3/1075 00:08 < 2:32:58, 0.12 it/s, Epoch 0.01/5]




      Step
      Training Loss
      Validation Loss









      [   4/1075 00:16 < 2:31:04, 0.12 it/s, Epoch 0.01/5]
...

[teeler]

Hi there,

Thanks for the PR - please glance at https://github.com/googlecolab/google-colab-cli/blob/main/CONTRIBUTING.md

That said - I do like this idea, but I'm wondering if there is a better/more exciting alternative than just stripping out the tags (this is why i prefer to have the discussion btw, so we can sort out these details before having folks write any code)

Instead of stripping, i'm wondering if there's a nicer way to render the HTML outputs in the terminal? Eg, using something like rich?

[merlinran]

Yeah I mostly use this as an idea for the discussion. I'm not very familiar with this domain. A quick search suggests that rich is great at exporting stuff as html, but not for taking html as input. Would https://pypi.org/project/html2text/ be a good fit?

[merlinran]

Updated to use html2text + rich (left text/latex unhanlded). With test_display.py

uv run colab new -s display-test
uv run colab exec -s display-test -f /tmp/test_display.py
uv run colab stop -s display-test

[teeler]

@merlinran what do you think? I think that looks pretty good!

@sethtroisi any thoughts?

[merlinran]

This works good enough to me. Just tested with a finetuning task.

Starting training...

[ 2/1075 : < :, Epoch 0.00/5]


 Step  Training Loss  Validation Loss
 ────────────────────────────────────

[ 3/1075 00:08 < 2:39:12, 0.11 it/s, Epoch 0.01/5]


 Step  Training Loss  Validation Loss
 ────────────────────────────────────

[ 4/1075 00:17 < 2:36:37, 0.11 it/s, Epoch 0.01/5]


 Step  Training Loss  Validation Loss
 ────────────────────────────────────

[ 5/1075 00:26 < 2:37:36, 0.11 it/s, Epoch 0.02/5]
...

[teeler]

Yea html2text was a good find, i think i've used that one before.

Can we add some tests here? If you're using an agent, they can read AGENTS.md i think there is some testing guidance in there.

[merlinran]

Extracted the logic into a single utility with test coverage. Also squashed into a single commit for better history.

[teeler]

Extracted the logic into a single utility with test coverage. Also squashed into a single commit for better history.

GH will squash & merge when we accept the PR, jfyi you don't need to do it proactively (in many cases its actually nice to see, esp. if there are review comments)

[teeler]

probably want to migrate all the typer.echo() calls in automation.py to Console.print, but we can do that later.

[teeler]

Thanks!