ANSI rendering bug with "0;"

[petermm]

Environment

• Elixir & Erlang/OTP versions (elixir --version): 1.12.3 24.1

• Operating system: macOS

• How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): iex -S mix phx.server

• Livebook version (use git show if running with mix): current latest - commit 026945e (HEAD -> main, origin/main, origin/HEAD)

• Browsers that reproduce this bug (the more the merrier): All

• Include what is logged in the browser console: n/a

• Include what is logged to the server console: n/a

Current behavior

Notice ANSI bug and wrong rendering by doing:

Mix.install([
  {:eqrcode, "~> 0.1.10"}
])

"small qr"
|> EQRCode.encode()
|> EQRCode.render()

Expected behavior

Correct ANSI rendering.

Context

the code failing is from https://github.com/SiliconJungles/eqrcode/blob/8ce379a07d260e74b88f0671b7b0ec4004e37c65/lib/eqrcode/render.ex#L30

eg the "\e[0;107m \e[0m" string:

iex()> "\e[0;107m  \e[0m" |> LivebookWeb.Helpers.ANSI.ansi_string_to_html()
{:safe, ["\e[0;107m  "]}

in contrast to:

iex()> "\e[40m  \e[0m" |> LivebookWeb.Helpers.ANSI.ansi_string_to_html()   
{:safe,
 [
   ["<span style=\"", "background-color: var(--ansi-color-black);", "\">", "  ",
    "</span>"]
 ]}

Hackish fix

adding string = string |> String.replace("0;", "0m\e[")
before this line does remedy it - but surely this is not the proper fix..

livebook/lib/livebook/utils/ansi.ex

Line 51 in 026945e

[head | ansi_prefixed_strings] = String.split(string, "\e")