Yuyi Wang
No. I ran the tests on my devices... The prefix parser converts all `/` to `\` in the beginning so it's OK to hardcode here.
> It looks like Cygwin will take `//.` as well, but only `//.\C:` not `//./C:`. Go figure Well... You're right then. So when does Cygwin doesn't take `/` in a...
Seems that Cygwin treats `//./` and `//../` as `//`. Wierd but I think I can handle that...
I think I need more time to think how to handle the `//././../././../` prefix as `//`... If there's no better way, I think I should remove the prefix parser for...
Now they are handled. Based on my experiments, only `//./` (together with `//../`) is special and should be dealt with. `\\.\`, `\\./`, `//.\` are valid device paths. I have to...
I don't think it's a bug now. It's only a little wierd. Due to the design of rust std, I choose to identify the whole `//././?/C:` as a prefix.
Tested on Cygwin and I found that Cygwin even treats `//./?/C:/msys64/../../../?/D:/msys64` equal to `D:\msys64`. So Cygwin really thinks that's a POSIX path. I think I should follow it. The path...
What's the progress of this feature? It's very useful and necessary when handling i18n.
I have a solution that's a little hacky and doesn't introduce new macros. https://github.com/compio-rs/winui3-rs/blob/winui3-lite/winui3/src/compose.rs The hacky part is the trait `ChildClass`. * It needs the Factory object to create a...
I'm sure that it would be fixed by #5828, but no maintainer takes care of it.