Isaac Freund

> My quick guess is there's a discrepancy in the stage1 and self-hosted tokenizers. I'll browse the C++, hopefully it's narrowly-scoped. To be pedantic, the difference is in the parser...

> The tokenizer is shared between Zig syntax and all dialects. One tokenizer to rule them all. This is the one thing about this proposal that I'm iffy on. The...

> > Alternatively, we could skip over the inline asm specific source during "main" zig tokenization, for example by requiring that all asm dialects ensure disallow unmatched curly braces and...

> semicolons are already required at the end of statements. the situations you described that do not require one are not statements at all, they're expressions/blocks. They are statements according...

To clarify more, there are three major levels which the grammar defines: top/decl level, block/statement level, and expression level. The first deals with unordered declarations inside a container type (note:...

This is a compile error regardless of whether one tries to use it on the C ABI, and this is 100% intentional: ```zig const Foo = packed struct(u32) { x:...

IMO mach should namespace its environment variables with a `MACH_` prefix to avoid conflicts with other programs. It wouldn’t surprise me if some other software also reads `$PLATFORM`, it’s pretty...

I agree that having all configuration be reversible is desirable as needing to restart the compositor is annoying. One idea I had with regards to this was a command that...

> The completion scripts for all the different shells having to be updated separately certainly is an issue. As an alternative solution I propose the following: Have one file containing...

@tiosgz Hmm, yes something like that should be implemented for pointer and touch input devices to make the X11/Wayland backends work properly. That wouldn't solve this issue however, which is...