Havn't reviewed yet, but just on the point of actually doing this at all.

Ok, despite what g_utf8_validate () claims NUL is a UTF-8 code point. So I suppose there is an argument that it should be loaded. But due the number of C NTS functions used in Geany its pretty much going to be a lottery if it edits, so loading it read-only is a good idea (if display and parse and search and any other function that will access an readonly file is NUL safe). But thats only loading files as UTF-8, any other encoding is going to depend on the system iconv implementation underlying the g_convert()

Showing an infobar identifying that its readonly, and why, allows the user to understand why they can't edit it, and where the problem is an encoding error, to locate where that occurred so they might be able to fix it with a hex editor or similar seems useful.

But why saving it? Its readonly, so it won't change. If the problem is encoding, then LOAD it with the correct encoding, don't save a new encoding of an incorrectly decoded file. If the file has wrong encoding (or mixed encodings) then saving it again won't fix it.

As for editing it, I have yet to see a real use-case for editing such files in a text editor/IDE, and given the amount of changes to Geany it would take to safely allow editing I do not see the point of making any changes to support more than loading and displaying files with NULs until a real use-case is provided.

So unless a compelling use-case is presented I would say load it, and lock it read-only, and tell the user why to help them find the problem, but I do not support starting any changes to allow editing, or saving.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.