Closed pR0Ps closed 3 years ago
@SnowyMouse I've updated the PR to include better error checking and messages. At this point I think this is done. Let me know if you have any questions/suggestions.
Rebased on master to include the build check (it works! And you can download the artifact to test it without having to checkout+compile it yourself!)
Note that #68 is needed to see the error messages since the show_error_box
function currently segfaults if the ini file hasn't been parsed (I removed the fix from this branch to avoid merge conflicts).
Thanks!
When running Chimera
1ef91c18
with a non-ASCII path (set via the-path
arg, thepath=...
setting inchimera.ini
, or just the default path with your Windows username in it), Chimera would crash, sometimes creating 2 new folders with mangled names (one with just thechimera/lua
folder, other other with the rest of the files). An example of a problematic path is "ÁÉÚÝÍÓŠ".Note that ANSI is used as a shorthand by programs for "the system's preferred 8-bit encoding". In my case that's
CP-1252
(en-US
locale).When running with![prev_ansi](https://user-images.githubusercontent.com/466941/106094946-e7b19000-6100-11eb-8d9d-e16c819486b8.png)
-path ÁÉÚÝÍÓŠ
or using a ANSI-encodedchimera.ini
(halo crashed):When using a UTF-8-encoded![prev_utf8](https://user-images.githubusercontent.com/466941/106094952-e97b5380-6100-11eb-92cd-b4c8f67edea6.png)
chimera.ini
(notepad.exe and notepad++ both saved in UTF-8 by default) (halo crashed):Setting the locale of the program to match the system's configured locale fixes the issues with the default path and the
-path
argument. It also allowschimera.ini
to be read properly as long as the file is encoded using ANSI.Because ANSI isn't portable across systems and most text editors now save everything in UTF-8 by default, the ini parser was modified to parse values as UTF-8 strings and internally convert them to their ANSI equivalents. Error messages have been added for cases where the file isn't encoded properly, as well as when a properly-encoded UTF-8 character can't be converted to ANSI.
Many thanks to Adam Šliperski for discovering these issues and working with me to fix them.
Some screenshots with the fixes applied to give an idea of the different error conditions:
non-ASCII characters encoded in ANSI:![invalid_encoding](https://user-images.githubusercontent.com/466941/106093441-4e817a00-60fe-11eb-95e9-0acb8a57e31b.png)
Same as above but only in a comment:![working_ansi](https://user-images.githubusercontent.com/466941/106093472-5f31f000-60fe-11eb-8ed4-a695c9e098d4.png)
A valid UTF-8 character that can't be converted to ANSI:![invalid_character](https://user-images.githubusercontent.com/466941/106093457-56411e80-60fe-11eb-9327-15dd84bb1837.png)
Same as above, but only in a comment:![working_utf8](https://user-images.githubusercontent.com/466941/106093468-5c36ff80-60fe-11eb-9523-0809a960e0ce.png)