[04:45] <Geth> ¦ doc: pelevesque++ created pull request #4282: Reduce size of entry for READMEs in other languages

[04:45] <Geth> ¦ doc: review: https://github.com/Raku/doc/pull/4282

[08:01] *** sena_kun joined
[09:36] <lizmat> do we have a reason why E<> formatting codes aren't directly rendered to graphemes ?

[11:59] <lizmat> Q: if $=pod would become immutable, would that pose an issue with parsers?

[11:59] <lizmat> I would hope not, as the fact that $=pod is mutable atm, is really an implementation detail as we're supposed to assume it's immutable?

[13:09] <[Coke]> lizmat: with which rendering? text, html?

[13:10] <[Coke]> 10 years ago, I would have said thge html entities were safer.

[13:11] <[Coke]> today? yah, seems fine to just to go to unicode and always emit utf8

[14:37] <lizmat> [Coke] any rendering

[14:57] <[Coke]> Yah, seems reasonable to me.

[14:57] <[Coke]> we shouuld only encode on output if it's *required*, not if it's optional.

[14:57] <[Coke]> IMO

[15:01] <lizmat> [Coke]: wrt to mutability, do you think it's going to be a problem if $=pod becomes immutable ?

[15:03] <lizmat> hmmm... I just saw that formatting codes are not honoured in pod tables ?

[15:03] <lizmat> is that intentional ?

[16:25] <[Coke]> Feels more like it's NYI

[16:26] <[Coke]> I feel like $=pod *should* be immutable, but I'm not sure if it'll break anything.

[16:26] <[Coke]> feels like it's "whatever was in the source when we compiled"

[16:31] <lizmat> right

[16:32] <lizmat> I guess lining up columns with markup is a bit harder, but I don't see why that wouldn't be allowed to work

[16:47] <[Coke]> Yah, I think it was just "hard". - should be easy on the HTML renderer, though, which is most of our use case for tables at this point.

[16:48] <lizmat> ack

[16:50] <[Coke]> ?

[16:51] <[Coke]> For tables, I imagine we'd render all the cells *first* and then construct the table knowing the rendered sizes of everything.

[16:51] <[Coke]> for *text* tables

[21:39] *** sena_kun left