02:45 <i509vcb> From a practical standpoint, it is reasonable to assume ALL wayland xml protocol specifications that anyone really cares about will be encoded in UTF-8?

08:44 <jadahl> i509vcb: all protocol files in w-p start with <?xml version="1.0" encoding="UTF-8"?> so yes. the DTD verification in wayland-scanner also assumes it's utf8

08:50 <i509vcb> I did test and UTF-16 appears to generate just fine. Shift-JIS just explodes and wayland-scanner core dumps

08:50 <i509vcb> (event with --strict)

08:50 <i509vcb> s/event/even

08:54 <i509vcb> Hmm nope just made a bad file for the Shift-JIS testing

08:54 <i509vcb> so wayland-scanner can generate with Shift-JIS encoding.

08:54 <i509vcb> Yes this is probably unreasonable to test

11:44 <dottedmag> Why not decree the encoding and forget about headaches? What would be the use-case for Shift-JIS-encoded protocol specifications?

18:48 <i509vcb> I'd definitely prefer if wayland-scanner just mandated UTF-8 for protocol xml files, but the scanner accepts UTF-16 and Shift-JIS xmls and runs fine so there would be a very theoretical regression unless we decide to not care there.

18:51 <i509vcb> Context here for this whole encoding discussion was me turning wayland-rs' wayland-scanner into a library and realizing that quick-xml just assumes a stream of bytes instead of UTF-8 strings. So there are a lot of String::from_utf8 conversion around the place.

21:02 <DemiMarie> i509vcb: I would be absolutely fine with mandating UTF-8.

21:03 <DemiMarie> In fact, I would recommend it.

21:04 <emersion> same

21:05 <DemiMarie> Also why does the scanner need two XML parsers?

21:07 <emersion> what do you mean?

21:21 <i509vcb> I think one of the parsers is for DTD validation