Documentation Channel for #raku | This channel is logged | Roadmap: github.com/raku/doc/wiki
Set by [Coke] on 23 May 2022.
Geth doc: pelevesque++ created pull request #4282:
Reduce size of entry for READMEs in other languages		 04:45
08:01 sena_kun joined
lizmat do we have a reason why E<> formatting codes aren't directly rendered to graphemes ? 09:36
Q: if $=pod would become immutable, would that pose an issue with parsers? 11:59
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?
[Coke] lizmat: with which rendering? text, html? 13:09
10 years ago, I would have said thge html entities were safer. 13:10
today? yah, seems fine to just to go to unicode and always emit utf8 13:11
lizmat [Coke] any rendering 14:37
[Coke] Yah, seems reasonable to me. 14:57
we shouuld only encode on output if it's *required*, not if it's optional.
IMO
lizmat [Coke]: wrt to mutability, do you think it's going to be a problem if $=pod becomes immutable ? 15:01
hmmm... I just saw that formatting codes are not honoured in pod tables ? 15:03
is that intentional ?
[Coke] Feels more like it's NYI 16:25
I feel like $=pod *should* be immutable, but I'm not sure if it'll break anything. 16:26
feels like it's "whatever was in the source when we compiled"
lizmat right 16:31
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:32
[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:47
lizmat ack 16:48
[Coke] ? 16:50
For tables, I imagine we'd render all the cells *first* and then construct the table knowing the rendered sizes of everything. 16:51
for *text* tables
21:39 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!