Add Owl.Data.from_ansidata/1

[zachallaun]

Implements #9. This isn't quite ready to merge, but wanted to open it as a draft for now. The primary things left are to add docs and quite a lot more tests.

Notes:

• I've created an internal Owl.Data.Sequence module that takes a similar approach to IO.ANSI. It's responsible for identifying escape sequences, grouping sequences into types, knowing what the defaults are, etc.
• maybe_wrap_to_tag, reverse_and_tag, and collapse_sequences are unchanged, just moved.
• I'm not making an effort to "combine" tags in any intelligent way at the moment. See the nested red/underlined test for example. Other than for aesthetic purposes, I don't know that there's a real benefit to this and I believe it would make the implementation rather more complicated.

Example:

%{foo: 1, bar: "two", baz: 'three'}
|> Inspect.Algebra.to_doc(Inspect.Opts.new(syntax_colors: IO.ANSI.syntax_colors()))
|> Inspect.Algebra.format(80)
|> Owl.Data.from_ansidata()
|> Owl.IO.puts()

[zachallaun]

Rebased with main, added additional tests, and updated docs!

[fuelen]

Played a bit with it. Looks nice, good job.
Just noticed that it doesn't work with binaries, so getting data from cmd and trying to parse it won't work. Technically, binary is a part of iodata

> "test" |> Owl.Data.tag(:red) |> Owl.Data.to_ansidata() |> to_string() |> Owl.Data.from_ansidata()
"\e[31mtest\e[39m\e[0m"

[zachallaun]

Just noticed that it doesn't work with binaries, so getting data from cmd and trying to parse it won't work. Technically, binary is a part of iodata

This is a documented limitation for now, see here.

It wouldn't be too hard to parse binaries to split out escape sequences in the future, but I chose not to add that for this first iteration. I agree that it would be nice to have in order to consume data from cmd. My personal use-case was focusing on consuming ansidata from IO.ANSI.

Edit to add: Another edge-case if we get into parsing escape sequences that are embedded in binaries: iodata doesn't care whether the sequence is split.

Given this, probably the best way to handle this would be to toss the existing code that traverses ansidata and just to_string(ansidata) and parse character-by-character when a \e is encountered.

[fuelen]

Yes, let's do binary parsing in a new iteration.

Thank you for the PR! ❤️

[fuelen]

Looking at coverage and this line is red. This is for char list, right?

[zachallaun]

Yeah, it’s just to handle individual character literals in ansidata. [“hello”, \?]

Should’ve added a test, sorry!