It would be useful if Geany supported build profiles (sets of build commands) and let you assign a different build profile to each geany tab. The user should be able to pick a default build profile that new tabs / files will use by default and geany should remember which build profiles were assigned to specific files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2607
There are times I like auto-scroll and times I don't like it, when I'm looking at errors/warnings during an ongoing compile I don't like it, I would appreciate the auto-scroll disabling when I move it away from the bottom, only re-enabling when it is put back, this can easily be detected by simply grabbing both value prior to adding in a line, adding the line then checking the values are the same, if auto-scroll is handled by a different thread then it just needs to check the distance is within 1 line as it is very unlikely the thread would be further behind than one waiting for input from another process
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2772
For a fluent coding I love to not change my hand position to use the
arrow keys!
I realy like auto-closing.
If I activate the auto closing brackets, braces, parenthesis and
quotes feature, the closing characters are inserted, but to continue after
these, the arrow keys are necessary.
The modification I made: if autoclosing AND consuming is activated in
options, if a closing character is typed and the following character
matches this, not both characters stay - one deleted - curr pos
afterwards.
Example: the | marks the curr position:
"|"
"hallo|"
[Then the " is hit]
"hallo"|
The " is reachable without changing hand pos. Same for the other
"autoclosers".
I saw this in other IDEs and I want it in my Geany.
I don't know about internationatlization, so this is an incomplete
feature.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2122
-- Commit Summary --
* Consume closing brackets, braces, parenthesis, single and double quotes
-- File Changes --
M data/geany.glade (239)
M scintilla/include/Scintilla.h (1)
M scintilla/src/Editor.cxx (5)
M src/editor.c (67)
M src/editor.h (1)
M src/keyfile.c (2)
M src/prefs.c (43)
M src/sciwrappers.c (9)
M src/sciwrappers.h (3)
-- Patch Links --
https://github.com/geany/geany/pull/2122.patchhttps://github.com/geany/geany/pull/2122.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2122
Never had any of these issues on Linux. Geany would load the full session in <1s, never frozen.
No plugins.
Behavior:
1) Geany takes about 20 seconds to startup/load.
Only about 20 documents open with about 10-15k lines of code total.
Memory usage after done loading/starting up: 16MB.
2) This happens about 80% of the time. Sometimes Geany opens normally.
Sidebar, tabs and editing window is frozen (can't type, can't highlight text, can't resize the boundary between sidebar and editing window, etc.
Only the menu and toolbar seem responsive.
Also, if opening a second geany window, the second window is responsive (no session).
If I re-open a session in the second window, it takes about 20 seconds again to load (up to several seconds for a single file), however the interface is responsive.
Here's how the app looks (all text and filenames removed): https://i.imgur.com/GnZEnWN.png
The sidebar is really small and can't be resized while frozen. Everything else looks visually normally.
The most consistent way I've found to get Geany unfrozen is by clicking a different tab than the one already open towards the center left side of the screen, though this will often close a tab even though you're not touching a X (upon unfreezing, the tabs shifts somewards towards the right, the sidebar resizes to the previously used size, etc).
Randomly clicking spots in the text will sometimes work too, but it's inconsistent.
Update: looks like a factor to whether Geany will be frozen after loading up or not depends on the size of the currently = previously selected/focused file.
With a C++ file of 900 lines total selected Geany opened consistently in a frozen state.
With a C++ file of only 15 lines total selected Geany opened consistently in an unfrozen/responsive/proper state.
Loading times is the same in both cases though.
In sharp contrast notepad++ opens the same files in <1s after opening the application on Windows, so it's definitely not the files or the filesystem that's at fault.
Casually monitoring geany.exe: it's utilizing almost a full CPU core while loading files, but its memory is only increasing by about 0.25MB/s.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2844
PHP 7.3 has changed the Heredoc/Nowdoc syntax, so that the ending delimiter doesn't need to be at the beginning of a line, and can be followed by other expressions. the following examples are valid php code now:
```
<?php
$var = <<<EOL
this is a test
EOL;
```
```
<?php
$vector = [<<<EOL
this
is
a
test
EOL, 'other value' ];
```
But both syntax examples are not properly parsed/highlighted on Geany.
I'm not sure if this is a Scintilla bug or a Geany bug - I can see Geany has a php parser, which today is unable to parse the new syntax (code is [here](https://github.com/geany/geany/blob/master/ctags/parsers/php.c)). I tried to open a ticket on Scintilla about this, but I am not allowed to do so (looks like you need approval from the project owners to open a ticked there).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2414
Xubuntu 20.04
Geany 1.37.1, GTK 3.24.20, GLib 2.64.3
```
(gdb) run
Starting program: /usr/local/bin/geany
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff548c700 (LWP 80774)]
[New Thread 0x7ffff4be7700 (LWP 80775)]
[New Thread 0x7fffecc9e700 (LWP 80776)]
[New Thread 0x7fffe7fff700 (LWP 80777)]
[Detaching after fork from child process 80778]
[Thread 0x7fffe7fff700 (LWP 80777) exited]
(geany:80770): GLib-GObject-CRITICAL **: 08:43:38.441: g_object_get_data: assertion 'G_IS_OBJECT (object)' failed
Thread 1 "geany" received signal SIGSEGV, Segmentation fault.
0x00007fffedc844e5 in gsdlg_option (label=0x555556413338 "DICT", value=0x555556413308 "dict",
key=0x555556412e18 "proto", dlg=0x555556403ed0) at gsdlg.c:479
479 cw=g_object_get_data(G_OBJECT(hbox), DataKey);
```
For test use [complex-dialog.lua](https://github.com/geany/geany-plugins/blob/master/gean…
Also I tried GTK2-version (Geany 1.36, GTK 2.24.32 and GLib 2.64.3): works fine.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1027
Hello everyone,
Since the migration to Ubuntu 20.04, Geany no longer displays underscores.
I have to zoom in considerably to see them.
Any ideas on how to solve this annoying problem? Thanks for this fabulous software !
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2502
At the moment Scintilla V5 is still regarded as unstable, IIUC it will be V5.1 thats stable "soon".
This issue is to discuss how we should approach the Scintilla V5 changes, the API changes, the Lexilla/Scintilla split, how to make the process scalable, massive single commits are simply not viable.
Then there needs to be a discussion about importing Scintilla/Lexilla it will be done in Geany after the changes to separate Scintilla and Lexilla.
To be blunt, the mechanics of getting the parts Geany uses from the Scintilla repos is the least of a Scintilla upgrade, be it git subprojects or a bash/Python script doesn't matter, its a minor part of the work needed for the upgrade, even now Scintilla and Lexilla are separate. So the simplest for everyone to understand is the best.
The main part of a Scintilla upgrade is the manual work for each lexer:
1. checking if any of the syntactic elements from the lexers have changed,
2. changing the mapping of those to Geany entities in `highlightingmappings.h`
3. adding them to `filetypes.xxx`,
4. checking for any lexer properties that need to be added or removed.
These are manual actions at the moment and make up most of the work creating and reviewing a Scintilla upgrade and are why the upgrades take so long.
IIUC there are some additional scripts or similar that come with Scintilla/Lexilla 5 that may make at least part of that work automatic, identifying changes at least. That needs to be explored to allow supporting the current number of languages to remain viable.
ATM its just too much work and nobody has the time.
Also potentially making Lexilla changes separate from Scintilla would help, IIUC Neil will be issuing them as separate releases in the future, and even better if each filetype could be done by itself. Then whoever is interested in a language can submit a smallish PR that would be easy to review and commit.
Huge commit bombs are simply not viable into the future, thoughts anyone?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2824
These changes allow us to create future release builds for Windows for the x86_64 platform and finally use GTK3.
Also since the GTK bundle creation and the NSIS installer scripts get more flexible, this helps to create fullly automated cross-compiled builds.
Changes in the bundle creation script:
- the GTK (and other dependencies) bundle is now created for the x86_64 platform
- the new parameter "-x" allows to run script on a Linux system using Wine, therefore it is necessary to run the post-install scripts after all packages have been extracted.
- use "-Sdd" for Pacman to ignore dependencies as we resolve them manually
- do not use "tar -x --xz" as Pacman nowadays also downloads .zst packages, instead just download the file and let tar choose the format automatically based on the filename
- install grep with Pacman as the build and target platform are now identical
- update GTK dependencies to match current packages
Changes in the NSIS installer script:
- remove hard-coded paths and installer name from NSIS installer script - This makes the paths for external resources configurable using command line flags (e.g. /DGEANY_THEMES_DIR=/something/geany-themes) and also the resulting installer filename can be set via command line flags
- the "INCLUDE_GTK" command line is removed as we always include the GTK bundle
- the GTK version detection was removed and now we always bundle the GTK3 specific CSS files.
Do NOT merge before 1.37 is released as we should make first a final GTK2/i686 release before switching.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2590
-- Commit Summary --
* Windows: Create GTK bundle for x86_64 and suppt non-native execution
* Remove hard-coded paths and installer name from NSIS installer script
-- File Changes --
M geany.nsi.in (96)
M scripts/gtk-bundle-from-msys2.sh (106)
-- Patch Links --
https://github.com/geany/geany/pull/2590.patchhttps://github.com/geany/geany/pull/2590.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2590
This issue is to make our Windows builds (nightly, CI and release builds) easier and better.
And also to satisfy @elextr 's long-time wish to have GTK3 Windows builds :).
My goal is to create Windows builds:
- with GTK3 only
- for x86_64 (aka amd64 aka 64bit) only
- fully automated on a Linux box
I've written a Dockerfile which sets up a cross-compilation environment with mingw64-gcc, wine and a couple other necessary tools. It also bootstraps a minimal MSYS2 environment so packages can be installed with `pacman`.
In the resulting build environment we start a script which does:
- clone Geany repository if necessary (i.e. if it is not bind-mounted into the container)
- cross-compile Geany for Windows 64bit and GTK3
- sign all binaries and installer (if /certificates exist and contains cert.pem and key.pem)
- download Geany-Themes for bundling
- create GTK3 bundle with all dependencies (including grep and sort)
- create the NSIS installer in ${OUTPUT_DIRECTORY}
- test the created NSIS installer and compiled Geany
- test uninstaller and check there is nothing left after uninstalling
This is already working pretty nicely (even digitally signing the binaries!!).
I guess I'll put the Dockerfile and the build script into a new repository.
However there are some tasks left for discussion and to do:
- do you think it is safe to switch to x86_64 builds only? I guess since Windows 7 almost everybody should have a x86_64 installation by default it she didn't anything against it on purpose. But I'm not sure enough and I didn't find proper resources on the net.
- there is a bug on Windows with GTK3 causing the message window to constantly loose some height between starts of Geany (#2591)
- we need to decide which GTK3 theme we use by default:
- the default theme (I think it's Adwaita) looks a bit alien on Windows, see screenshots below
- there is a "win32" theme natively in GTK3 which can be enabled in GTK3's `settings.ini`, it doesn't look quite right either :(.
I would say let's try with the default theme even GUI elements feel a bit huge.
Or we find another good looking theme or someone hacks something. I definitely won't work on this.
Dependant issues and PRs:
- [ ] #2591
- [ ] #2590
- [ ] #2572
Geany GTK3 Default Theme:
){kind=link}
){kind=link}