Geany 1.38 GTK+ 3.24.30 Glib 2.68.0 Macbook Pro M1 2021 macOS Ventura 13.1
Sometimes if the Find window is positioned over the main Geany window, clicks on Find window buttons act on the main window below as if the Find window was not there. The only way around this is to position the Find window off to the side so that no buttons overlap the main window. This happens regularly but not all the time, and it's not clear why.
There are various weird problems related to GTK event handling on macOS which we unfortunately cannot fix in Geany itself. I'm not sure if I saw this particular problem but I've seen problems similar to this one in the past. I recently made a new build of Geany with latest versions of libraries from gtk-osx (with GTK 3.24.36) which is available here
https://download.geany.org/snapshots/geany-1.38_osx_arm64.dmg
so you can give it a try.
Hello, thanks very much for that. Your new build does seem to have fixed the Find window focus issue. I'll post again if the problem recurs, however your new build is **very** slow to start: 100% CPU, unresponsive, UI eventually appears only after several minutes
Uh, that's weird, I don't see anything like that here. Do you use some plugins that could possibly cause that? Have you tried disabling them?
The only plugins I use are "Addons" to get Tools->Copy File Path option, and "Project Organizer". Disabling these makes no difference to the startup time.
I could imagine that for instance ProjectOrganizer could be the problem if you let it index some huge project directory or the whole home directory but if you say the same problem persists when it's disabled, it must be something else then.
Do you have some big file open for instance? When you open Activity Monitor of macOS, do you see some big disk activity when you switch to the Disk tab? Is it the Geany process that consumes those 100% CPU or some other process too? Do you see some suspicious messages in the Console macOS application (the one for viewing logs)?
One other thing you could try is to rename the `~/.config/geany` directory to something else (when Geany isn't open) so when you launch Geany it creates new configuration files in case something is wrong with your configuration.
OK, I can try those suggestions, however the startup performance was not a problem with the Geany build I was using previously (as documented in my original post), with the same configuration, plugins and open files.
OK, I can try those suggestions, however the startup performance was not a problem with the Geany build I was using previously (as documented in my original post), with the same configuration, plugins and open files.
Would you try reinstalling the previous version to see if the problem disappears?
The other option is it's something in Geany or plugins (I used the current git master version in this build). There were many changes related to ctags parsers and you could hit some problem we didn't see. What file types are the files you have open in Geany?
Geany consumes 100% CPU by itself, no other process is involved. It does not show any excessive activity in the Disk tab. Startup attempts are logged in the Console Diagnostic Reports tab for excessive CPU, but otherwise there is nothing related to Geany there. I have reinstalled the previous version ("Sulamar", details per original post) and can confirm that startup is then more or less instantaneous. The only file types I have open are .sql (Oracle PL/SQL scripts) and simple .txt One difference I notice between your build and Sulamar is that folders in the Documents tab are arranged as a hierarchy in yours (a huge improvement!) and as a single level without a hierarchy in Sulamar.
The only file types I have open are .sql (Oracle PL/SQL scripts) and simple .txt
What happens if you close those files and re-launch Geany?
If I close all files, stop and uninstall Sulamar, then reinstall, the new build of Geany also starts instantaneously.
If I then reopen the most recent files, Geany continues to start instantaneously.
Possibly one of the previously open files had content which the new ctags parsers choke on: I'll carry on with the new build, and see if the startup time becomes a problem again. For now, I think we have a workable solution, so thanks very much for your time and effort.
OK, great. I suspect it will be some of the files you had open then. It would be nice if you manage to figure out which one it was and will be able to share it or create a shareable file with which you are able to reproduce the problem so we can have a look at it.
OK, will do. None of the files are particularly large, and they all have pretty similar syntax, but if I can pin down the culprit I'll let you know.
I think I have identified two files which exhibit the problem. Any attempt to open the files, update the files, or even change the cursor position within the files, causes 100% CPU for an appreciable time. They are, by the standards of most of our code, large files containing fairly complex PL/SQL, but it's hard to identify specifically what makes them behave as they do. I am reluctant to post the files on an open forum: any suggestions?
Can you run Geany under a debugger and when the 100% happens interrupt it and see where in Geany it is?
Possibly, but my Macbook is not setup for the kind of development that needs a debugger! What's the quickest and easiest to install?
What's the quickest and easiest to install?
@techee might know, thats why I asked rather than suggested :-)
Basically unless a source file that causes the problem is available (no criticism, your choice) so we can reproduce the problem it needs you to do the investigations for us.
Or can you make a rubbish pl/sql file that hides your secrets but causes the problem?
I'm happy to provide the file, but directly to someone investigating the problem, e.g. via email, not as an attachment to a post where everyone can look at it. On further investigation, by splitting the file into smaller pieces, the problem appears to be related to the size of the file rather than its content. The original file is 750K and 16700 lines, and is a problem. If split into two, the problem is much reduced, but still noticeable. If split into ten, the problem goes away completely. Regrettably splitting the file is not a viable option.
I would first suggest trying the current ctags binary if it exhibits the same problem so we are sure it's the ctags parser problem. You can for instance install homebrew and use the ctags version here:
https://formulae.brew.sh/formula/universal-ctags
If you reproduce the problem (i.e. long parsing time), you could then bisect it to the ctags version that causes the problem. To get build tools (and also the debugger as Lex suggested), it's best to install XCode - either from the App Store or from Apple's developer website (but I think for the second option you have to create a developer account at Apple first). When you first launch XCode, it should install the necessary command-line tools for you.
Then you can install build dependencies for ctags using ``` brew install automake pkg-config bash libxml2 jansson libyaml gdb docutils pcre2 ```
clone the git ctags repo from here ``` https://github.com/universal-ctags/ctags ```
and build it ``` ./autogen.sh ./configure ./make -j 9 ```
This will create the `./ctags` binary inside the ctags directory you can then test (make sure you are running this file and not the installed homebrew ctags version). You can manually bisect the ba commit by checking various ctags versions where the sql parser was changed:
https://github.com/universal-ctags/ctags/commits/master/parsers/sql.c
or by using `git bisect`. And of course if you have a linux box around or a VM, you can do it there and avoid installing XCode and homebrew.
I'm happy to provide the file, but directly to someone investigating the problem, e.g. via email, not as an attachment to a post where everyone can look at it.
I can do it if you send it to me (some time later today). You'll find my email in Geany's git commit history if you clone it to your machine.
Sent, thanks.
FYI, I followed the suggestion at [https://github.com/geany/geany/issues/791%5D(url) and that fixes the problem as far as I'm concerned, because all I lose is the Symbols tab, and that's a bit flakey anyway for PL/SQL code. The advantages of the build with the later GTK library (consistent focus, cursor changing correctly depending on context) far outweigh the loss of symbol functionality.
all I lose is the Symbols tab, and that's a bit flakey anyway for PL/SQL code
The biggest problem with the parser was that the file you provided was filled with conditional code that had this form: ``` $IF $$VERSION > 1 $THEN ... $END ``` The `$$VERSION` clashed with PostgreSQL's "dollar quoted strings" having the form `$$this is a string$$`. So for the parser everything after `$$` was a string until the next `$$` in the code. Not only this skipped large parts of the code so you didn't see many functions in the symbols tab (because they appeared to be inside a string), but also these big strings were the cause of the slow parsing. I tried to address this problem in
https://github.com/universal-ctags/ctags/pull/3654
After the patch, parsing the file seems to work correctly and all the functions are correctly reported and shown in the Symbols tab.
I've just made the following builds:
Geany 1.38 built with the latest GTK and other dependencies, including some extra fixes which I plan to release as the official macOS build on the Downloads page unless there are some problems with it: https://download.geany.org/snapshots/geany-1.38_osx-5.dmg https://download.geany.org/snapshots/geany-1.38_osx_arm64-2.dmg
Like the above but Geany and plugins are from current git master: https://download.geany.org/snapshots/geany-1.38_osx.dmg https://download.geany.org/snapshots/geany-1.38_osx_arm64.dmg
Both of these builds should fix the original window focus problem because they use the latest GTK. In addition, the SQL problem shouldn't be present in the 1.38 build as it uses the latest parser. The git verson should also work because it contains this woraround:
https://github.com/geany/geany/pull/3433
The fix for PL/SQL selection directives
https://github.com/universal-ctags/ctags/pull/3654
isn't included in this build so it's possible not all symbols will be displayed.
Closed #42 as completed.
github-comments@lists.geany.org