The scope plugin hangs Geany on some systems because it triggers a bug in some versions of the Glib libraries.
Although no longer the plugin maintainer, Scopes original developer has, to his credit, proposed a workaround [patch](https://github.com/geany/geany/pull/1461) to Geany to mitigate the effect. However despite his assurances its safe and only applies to the scope plugin, there has been reluctance to apply the patch to Geany in case it has other undesired effects. It certainly should not be applied this close to the 1.33 release.
I therefore suggest that Scope be disabled by default for this release or until the issue is resolved so that distros don't provide a plugin that hangs without having to actually enable it. But I don't know how to hack the m4 to do that. Can anybody who agrees and knows how to provide a PR?
I therefore suggest that Scope be disabled by default for this release or until the issue is resolved so that distros don't provide a plugin that hangs without having to actually enable it.
All that's gonna do is drive users to use the worse, not at all maintained debugging plugins which should've been removed years ago.
All that's gonna do is drive users to use the worse, not at all maintained debugging plugins which should've been removed years ago.
Indeed, but better that than hanging Geany with no way out.
All that's gonna do is drive users to use the worse, not at all maintained debugging plugins which should've been removed years ago.
Correction, __Scope__ is the unmaintained plugin, debugger has a maintainer and Geanygdb has been removed.
IMO, we should just apply #1461 which has been tested by multiple users (and code reviewed with no blocker comments AFAICT), and claimed that it's ready to merge by the author.
It seems a bad idea to apply a hacky patch to Geany where it affects all users, especially just before a release. At least scope won't be provided on distros that have gone to GTK3 now anyway :)
It seems a bad idea to apply a hacky patch to Geany where it affects all users, especially just before a release.
The problem I see is, that it will always be seen as a hacky patch if only some people who tryout the scope plugin manually apply the patch to their private versions/installations of geany and no one else. Possible side effects will not be found this way I guess.
What do you think about the following: - for 1.33 disable scope as suggested by @elextr - after geany 1.33 and geany-plugins 1.33 have been released, apply the workaround patch in geany master (if @b4n agrees) - I could take maintenance of the scope plugin. I can't promise much improvements because I am also working on other plugins and projects but I used it a bit from time to time and like it more than the debugger plugin
That way the patch would at least be tested by all developers in every day use. If we find any side-effects we can study them and decide to fix them or to remove the patch.
Possible side effects will not be found this way I guess.
Yeah, thats my biggest concern, unexpected side effects outside the plugin, and since the plugin does not work on GTK3 I expect that nobody has tested the patch on GTK3 at all yet.
after geany 1.33 and geany-plugins 1.33 have been released, apply the workaround patch in geany master (if @b4n agrees)
As soon after as possible, we didn't manage that last release period, and since @b4n has assigned himself to the PR it would be rude to do it without his agreement :grin:
That way the patch would at least be tested by all developers in every day use.
With this particular patch its also important that it be tested on a range of different versions of Glib as the bug only manifests on some versions.
I could take maintenance of the scope plugin. I can't promise much improvements because I am also working on other plugins and projects but I used it a bit from time to time and like it more than the debugger plugin
@LarsGit223 that would be very much appreciated. In terms of improvements I would have thought that GTK3 is the biggest one thats needed immediately, as distros are starting to distribute Geany with GTK3.
Currently neither of the debugger plugins run on GTK3 and so no debugger plugins are available on those distros. I don't have any idea of the scope [pun intended] of that work, it might be very minimal, or it might not.
.."no debugger plugins are available on those distros" - for the users who are trying to debug with Geany it's really a show-stopper. I didn't know of Geany until few days ago when tried to replace CodeBlocks (unstable) with something lighter, because Pi 3 has limited memory.
@AGenchev not sure the point of your comment.
@elextr it's just (related to the lack of debugger) grief about the lost ability to use Geany as IDE. But I decided that you were right to disable it by default.
no debugger plugins are available on those distros
There is an open PR, porting the debugger plugin to GTK3, see #645. Anyway, I will probably port the scope plugin in the future. I guess the PR for the debugger plugin will give me some good hints.
I'm afraid I cannot test the Gtk3 ports at the moment so I need input.
@frlan If there are directions how to compile those plugins, I can try testing 'em on Raspberry Pi. Geany itself works, but GTK3 windows "render" in 2 passes, e.t. not as fast as with Gtk2. Even java apps render their dialogs faster.
@LarsGit223
Anyway, I will probably port the scope plugin in the future.
Thanks, to return to the issue (its not actually not about GTK3), its because Scope __hangs__ Geany due to a bug in some versions of Glib, not GTK, I want to disable it on both GTKs by default for that reason.
Any pointers/PRs from M4 literate persons??
Any pointers/PRs from M4 literate persons??
I believe (without testing) that you could replace `auto` with `yes` [here](https://github.com/geany/geany-plugins/blob/1.32.0/build/scope.m4#L3). That said, IMO we shouldn't be making packaging decisions upstream as it will just cause packagers to further customize their scripts to enable specific features, causing more problems in the long run. Also, if we disabled all plugins with known bugs by default, half of the plugins wouldn't be built.
Also, if we disabled all plugins with known bugs by default, half of the plugins wouldn't be built.
Agree, its only because this one hangs Geany losing all the users unsaved work in progress. Thats not nice.
The distros should only enable it if their version of Glib is safe, but I don't think packagers necessarily test stuff much (for example see the GTK3 theme complaints that would have been obvious to any packager testing their handywork).
I believe (without testing) that you could replace `auto` with `yes` [here](https://github.com/geany/geany-plugins/blob/1.32.0/build/scope.m4#L3).
Almost, yet it's actually misleading and the second value is whether to *enabled* or not the plugin, so it would be changing this to `no`.
However, I wonder whether if we want to force people to make a decision we shouldn't actually go hackier than that and add e.g. an option `--yes-i-am-sure-i-want-to-enable-the-debugger-plugin-and-i-know-about-the-glib-hanging-issue`, so that people that went the extra mile of adding `--enable-debugger` because they are packaging it have to notice and take action.
Anyway… I'm don't really know what to do here, because on one hand I agree that it's fairly bad not to have the fix that already exist for a while, but I'm not 100% sure it's totally trivial (yet it seems to just be less optimized when it kicks in)
Ping. Release 1.33 is out. IMHO if the patch shall be merged to master it should be done a.s.a.p. to increase the testing time.
@LarsGit223 probably best to ping the actual PR on Geany #1461 and @b4n the (self) assignee.
Personally I couldn't care less if the debugger plugins work or not, but I understand that is my personal view, and that some people are in love with them. But I will only ever be testing the patch does not affect anything outside the Scope plugin.
Closed #688.
But I will only ever be testing the patch does not affect anything outside the Scope plugin.
Fair enough and testing the side effects in the only critical thing I guess.
github-comments@lists.geany.org