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