[Github-comments] Re: [geany/geany] Various encodings conversion fixes (PR #3716)
> It's (almost, but is for all practical purposes) documented as using > g_iconv(), which is documented as using iconv() or libiconv as fallback. Ok, the [code-ocumentation](https://github.com/GNOME/glib/blob/main/glib/gconvert.c) shows its iconv all the way, not a #ifdef windows in sight :-) > 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 we can use that in `init_encodings()` to remove unsupported ones from the list. It won't add any not supported by whoever made the list in `encodings.c`, but hopefully in this time of Unicode that won't be many. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3716#issuecomment-1850996725 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Various encodings conversion fixes (PR #3716)
> > 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 :smile: (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 or view it on GitHub: https://github.com/geany/geany/pull/3716#issuecomment-1850834644 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] non-deterministic anon_struct (Issue #3717)
> This generated name is created by the ctags CXX parser > [here](https://github.com/geany/geany/blob/512e88df8d97284c191459450bce4dd7877b9c2b/ctags/main/parse.c#L4795). And then we rename these in this nice function: https://github.com/geany/geany/blob/512e88df8d97284c191459450bce4dd7877b9c2b/src/tagmanager/tm_ctags.c#L246 It seems nested anonymous tags aren't handled correctly - I'll have a look at it. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3717#issuecomment-1850487935 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] non-deterministic anon_struct (Issue #3717)
This generated name is created by the ctags CXX parser [here](https://github.com/geany/geany/blob/512e88df8d97284c191459450bce4dd7877b9c2b/ctags/main/parse.c#L4795). The value of `parser -> anonymousIdentiferId` is incremented a few lines above, so I suspect its intended to count anon structs and give them incrementing names, but probably it isn't being properly initialised to zero at startup. @techee? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3717#issuecomment-1849891720 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] non-deterministic anon_struct (Issue #3717)
While working on [reproducible builds](https://reproducible-builds.org/) for [openSUSE](https://en.opensuse.org/openSUSE:Reproducible_Builds), I found that our `glfw` package varies in every build since the upgrade to geany-2.0 I extracted this minimal reproducer: ```bash cat > test2.c
