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>
Because of some problems with the macOS build of git master, I just modified it that instead of cloning the repo it just downloads the current master from https://github.com/geany/geany/archive/refs/heads/master.tag.gz. The tarball, however, doesn't contain a git repository and the build fails with
```
Program python3 found: YES (/Users/jhbuild/gtk/inst/bin/python3)
Program rst2html found: NO
Program rst2pdf found: NO
Program git found: YES (/usr/bin/git)
Running command: /usr/bin/git rev-parse --short --revs-only HEAD
--- stdout ---
--- stderr ---
fatal: not a git repository (or any of the parent directories): .git
../../../../gtk/source/geany-git/meson.build:170:1: ERROR: Command `/usr/bin/git rev-parse --short --revs-only HEAD` failed with status 128.
```
It appears that the problem is the line here which doesn't check if the repo exists (or recovers from the error):
https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc…
Once we make a release, the release tarballs will suffer from the same problem so I think it's something that should be fixed.
@kugel- Since you are the meson expert, any idea what the best solution of this problem should be?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3424
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3424(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
After some more thinking about it, we can fix #3454 very easily by ourselves by checking whether the tag originates from a source file with a known/common C/C++ extension - if not, always set "local" to FALSE.
The first patch adds `is_c_source` flag to TMSourceFile to indicate whether the file has one of the known C/C++ extensions, the second patch uses this flag and for C/C++ sources sets "local" to TRUE only when this flag is set (in addition to ctag's isFileScope flag).
@b4n Does this fix look OK to you?
Fixes #3454.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3490
-- Commit Summary --
* Add a flag to TMSourceFile indicating whether it's a C/C++ source file
* For C/C++ only mark tag as local if it originates from a source file
-- File Changes --
M src/tagmanager/tm_ctags.c (7)
M src/tagmanager/tm_source_file.c (18)
M src/tagmanager/tm_source_file.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/3490.patchhttps://github.com/geany/geany/pull/3490.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3490
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3490(a)github.com>
Having 2 files, *xx.foo* and *something.c* open as C (assume the *.foo* was a header or something):
<details><summary><em>xx.foo</em></summary>
```c
int xx_foo(int n);
```
</details>
<details><summary><em>something.c</em></summary>
```c
int main(void)
{
xx_foo(); // (1)
}
```
</details>
At `(1)`, neither autocompletion nor "go to tag" works, but calltip does.
Quick code look suggests that the `TMTag->lang` probably is wrong (I guess using the ctags-detected language (none?) instead of the actual parer's language?).
Causes real issues with a codebase full of `.hdl`s loaded as C++ (which are auto-generated headers included in just as auto-generated `.hxx`es).
@techee if you have insight that'd be amazing, otherwise I'll try and look at this deeper when (read: if :grin:) I get time.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3454
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3454(a)github.com>
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
When using *Tools->Config Files* to open a user file that doesn't exist.
This fixes the first line of `geany.css` being wrongly uncommented (and the rest unchanged) due to toggle comment being used and CSS not having a line comment.
Split out from #3396 as it's independent of it.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3450
-- Commit Summary --
* Don't comment global content unless it is Conf
-- File Changes --
M src/ui_utils.c (3)
-- Patch Links --
https://github.com/geany/geany/pull/3450.patchhttps://github.com/geany/geany/pull/3450.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3450
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3450(a)github.com>