Anyhow, yes, this could be improved, and ideally we'd probably not display the encoding in the list if it's not supported by the library we use (iconv), as it makes little sense then.

Would be nice but IIRC last time we discussed this there was no easy way of finding what was supported by g_convert(), and does that only use iconv, or does it use something else on Windows and Macos?

It's (almost, but is for all practical purposes) documented as using g_iconv(), which is documented as using iconv() or libiconv as fallback.

And even if its iconv all the way, there is no programmatic way of determining what it supports.

Oops, I didn't know it was impossible so I did it in the meantime 😄 (not pushed here, but I have something locally)
More seriously though, no there don't seem to be any way of querying the list of encodings it supports, but there is a way to query whether a particular combination is supported or not: just use g_iconv_open(A, B) and it'll error out with EINVAL if the conversion from B to A is not supported.

So probably it would involve shell testing iconv -l at install time and adapting the menu. Too hard.

Yeah, no, that's not gonna happen I don't think.

So yes, we could display it, it's a Mere Matter of Programming™, to report that error all the way up to the caller that will show the error.

A perfectly good thing to put in a PR called "Various encodings conversion fixes" he says hopefully?

Fair enough :smile: I should stop those fairly generic names even when I ended up fixing a various things on the way, I end up getting sidetracked forever :upside_down_face:

Maybe the lowest level function could display the message if it was force otherwise don't worry about it because its just Geany trying all encodings it knows again ;-)

Meh, that's a bit to ~~Geanyic~~as-hoc, but the error could definitely be propagated.

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