I just upgraded geany from 1.36 to 1.38 (Windows 10, version 1909), and the new UI is very bloated and greyscale and borderless. It looks pretty, but its hard to read. It also takes up WAY to much space, far more than it ever did. And its mostly wasted whitespace. On 1.36, its about 29 pixels between each open file on the left (about the height of the font, plus a small margin), on an 1.38, its 38 pixels between. Thats a 30% increase, but the font doesn't scale to justify the bloat. It makes it a lot harder to have a lot of open files, since the entire file pane is wasted whitespace
In addition, theres no border lines between open files, and everything is SUPER greyed out when it loses keyboard focus. Its pretty! But not very functional.
Is there any way to turn this off? I always liked geany as a "poweruser" editor. Functional, lightweight, and to the point
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3063
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3063(a)github.com>
There was a mistake in my fix for wayland popups, as @b4n correctly noticed in https://github.com/geany/geany/pull/3011#issuecomment-1279825987. The problem was that the "Go to symbol definition" did not open the popup in correct location.
This PR contains two commits:
- First fixes the problem
- Second removes support for prehistoric versions of GTK
The first commit might be used separately, but I have to openly admit that the #ifdefed code is not tested, because I couldn't find any system in my reach with old enough GTK. The second commit should not be merged until GTK 3.24 is officially required for Geany. But I guess that it should not be a problem, this PR can probably wait untill then, since no one noticed the bug for a month.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3316
-- Commit Summary --
* Fix go to symbol definition popup location
* Drop support for GTK 3.21 and older
-- File Changes --
M src/callbacks.c (2)
M src/editor.c (2)
M src/msgwindow.c (9)
M src/notebook.c (8)
M src/plugins.c (3)
M src/prefs.c (21)
M src/sidebar.c (8)
M src/symbols.c (91)
M src/ui_utils.c (26)
M src/ui_utils.h (2)
M src/vte.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/3316.patchhttps://github.com/geany/geany/pull/3316.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3316
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3316(a)github.com>
This PR adds a patch that could be applied during the Windows build to make the Prof-Gnome theme look more native. It:
- sets #000000 as the text color
- decreases statusbar height by 6px
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-osx/pull/35
-- Commit Summary --
* Add a patch with Windows-specific changes to Prof-Gnome
-- File Changes --
A prof_gnome_windows_changes.patch (41)
-- Patch Links --
https://github.com/geany/geany-osx/pull/35.patchhttps://github.com/geany/geany-osx/pull/35.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/pull/35
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-osx/pull/35(a)github.com>
A line like `function y = foo(a, b, c)` should yield a tag of `foo`, not `foo(a, b, c)`.
That way, Ctrl-clicking `foo` somewhere in the code will take me there.
The function name is `foo` after all, not `foo(a, b c)`.
Also, fixed issue where a line like `function foo() % this = bug` would yield a tag of `bug` instead of `foo` because the `=` in the comment was not ignored.
Finally, added a check to ensure that the line starts with the keyword `function`, and not any word starting with `function...` which could be a variable name (e.g. `functionality`).
Here I am considering that function names contain only alphanumeric characters (and underscore) as Matlab's documentation states. I'm not aware of the possibility of declaring functions with `.` or other special characters directly using `function`.
Example Matlab file demonstrating the issue:
```matlab
function y = foo(a, b, c) % the function name should be `foo`, not `foo(a, b, c)`
y = a+b+c;
end
function baz() % this = bug
disp('The function name is `baz`, not `bug`');
end
functionality = struct('a', 1, 'b', 2);
```
This used to yield tags `foo(a, b, c)` and `bug`, as well as `struct('a', 1, 'b', 2);` as a function; now it yields tags `foo` and `baz` as expected, and omits the `functionality` thing.
_(If it's any consolation, notice that GitHub also messes up the highlighting of `baz()` because of the `=` in the comment.)_
____
PS: Similarly, it might be good to figure out a way to also exclude occurrences of the substring `"struct"` that aren't the keyword `struct` itself, such as in strings, or as part of words, e.g.:
```matlab
restructure = true;
disp('You are on the way to destruction.');
```
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3358
-- Commit Summary --
* ctags: Matlab: function name only, without args
-- File Changes --
M ctags/parsers/geany_matlab.c (17)
-- Patch Links --
https://github.com/geany/geany/pull/3358.patchhttps://github.com/geany/geany/pull/3358.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3358
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3358(a)github.com>
This is a RFC regarding updating to the current version of Scintilla and getting off of the "fork" of the versions 3.x series (LongTerm3 branch).
The longer we wait to update, especially with the splitting off of lexers from Scintilla itself, we're basically just accumulating technical debt. Eventually the kind fellow currently maintaining the LongTerm3 branch will stop.
As far as I know, the main platforms Geany tries to support all have modern enough compilers/C++ standard libraries by now. There may be some older legacy/LTS platforms with users who won't be able to self-update to latest Geany without more effort, but with such limited developer time/interest/contributions for Geany, I don't think it's unreasonable to make some trade-offs like this in order to ensure Geany doesn't bitrot.
I might be willing to have a look at upgrading the code to work with latest Scintilla, but not if people are opposed, hence this RFC.
--
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/2519
Depends on #2355 for docs.
* Add *Project patterns* to open dialog file filters
* Re-use "File patterns" string in Find in Files dialog vs "Files" for clarity
* Show ungrouped filetypes first in open dialog file filter (fixes #2296 - see [this comment in particular](https://github.com/geany/geany/issues/2296#issuecomment-5337963…)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2356
-- Commit Summary --
* Add *Project patterns* to open dialog file filters
* Show ungrouped filetypes first in open dialog file filter
* docs: Document Open dialog options
* Update filter docs
* Re-use "File patterns" string in Find in Files dialog vs "Files"
-- File Changes --
M data/geany.glade (2)
M doc/geany.txt (40)
M src/dialogs.c (29)
M src/search.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/2356.patchhttps://github.com/geany/geany/pull/2356.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/2356
I tried removing files from /usr/share/geany/filedefs and editing filetype-extensions.conf but neither of those changes resulted in a shorter file pick list. I use less than 10 file types on a regular basis, but picking them out of that scrolling, out of window, file list is a pain. How do I shorten that list?
--
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/2296
After the update to Scintilla 5.1.5, I started getting memory corruption crashes when saving some files. (Sorry for not noticing this before, I thought the Scintilla update didn't contain any changes on the Geany side.) I may be wrong but I think the problem is in
https://github.com/geany/geany/pull/3046/commits/d7c985e47412f8a53c5a8202a0…
and misunderstanding if the following Scintilla API change
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value. The value returned is 1 less than previous versions of Scintilla. Applications should allocate a buffer 1 more than this to accommodate the NUL. The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL. This is more consistent with other APIs.
This part
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value...
> ...The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL.
says that that the returned __length__ doesn't include NUL, not that the returned string misses the NUL character. The rest of the change description says that we should allocate `+1` buffer to accommodate for that.
I believe we should revert the above patch and then go through all the uses of `SCI_GETTEXT`, `SCI_GETSELTEXT`, and `SCI_GETCURLINE` and corresponding `sci_` wrappers and update the code where needed (including plugins). I don't think it's a good idea to update the `sci_` wrappers alone to mirror previous behavior since the whole Scintilla API is part of Geany's API so this is a API change anyway and making `sci_` functions do something else than direct Scintilla calls is confusing.
Rant: I really don't understand why Neil made this change - even though it fixes some inconsistency in Scintilla API, this is a hard to spot backwards incompatible change and such things shouldn't be made in minor releases of a library.
@kugel- @eht16 @elextr What do you think?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3095
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3095(a)github.com>