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>
Fixes #3424.
This is my alternate proposal over #3578, as suggested there. If nobody complains, I'll use that -- but even better, somebody else could test and merge :wink:
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3597
-- Commit Summary --
* Fix meson build without git repo
-- File Changes --
M meson.build (10)
-- Patch Links --
https://github.com/geany/geany/pull/3597.patchhttps://github.com/geany/geany/pull/3597.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3597
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3597(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>
If the "Change history" feature is enabled in Geany, it might lead to styling issues in the tooltip displaying the diff of the current hunk. So always disable this feature for the tooltip where it is not needed.
I don't think we ever need the "Change history" in the diff tooltip, as the tooltip itself is already the improved version of the change history :).
This happens when the "Change history" feature is enabled in Geany, so it gets also enabled in the Scintilla widget for the tooltip where we don't need it.
For some reason, by setting the margin widths to 0 in https://github.com/geany/geany-plugins/blob/master/git-changebar/src/gcb-pl… the background colors in the Scintilla widget are reset to white (or something else happens with a similar result, I don't understand completely the relation between the margin visibility and the line background color).
Anyway, disable change history prevents this issue.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1281
-- Commit Summary --
* GitChangebar: disable Scintilla's Change History in diff tooltip
-- File Changes --
M git-changebar/src/gcb-plugin.c (1)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1281.patchhttps://github.com/geany/geany-plugins/pull/1281.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1281
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1281(a)github.com>
To keep a healthy amount of breakages before the release, here's one for git-changebar. After updating Scintilla to 5.3.7, the popup that shows the diff when a mouse cursor is placed on the marker in the sidebar shows a wrong thing:
<img width="1018" alt="Screenshot 2023-10-11 at 20 51 03" src="https://github.com/geany/geany-plugins/assets/713965/4dda14ca-cc29-4015-b7f…">
<img width="1018" alt="Screenshot 2023-10-11 at 20 50 27" src="https://github.com/geany/geany-plugins/assets/713965/8fcd16e3-0e2e-428d-921…">
It appears to be showing the same value for all diffs in the file.
The commit introducing this issue is
19336d22946b77bbcb5131544ea0e6317cdcf6b5 Update Scintilla to version 5.3.7
The commit before works as expected.
@b4n Any idea what might be wrong?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1279
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1279(a)github.com>
After updating to Scintilla 5.3.7 the Scintilla popup with the diff against git shows the wrong number.
It seems that gtk_widget_set_size_request() scrolls Scintilla view so despite it was set previously, it isn't set correctly after this call and has to be re-set.
Note that the call to SCI_SETFIRSTVISIBLELINE has to stay at the original location too, otherwise subsequent calculation using SCI_POINTXFROMPOSITION doesn't work because the line may not be visible.
@b4n Does this look OK to you? Maybe there's a better way to fix this problem so take this only as a hint where the problem is.
Fixes #1279
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1280
-- Commit Summary --
* git-changebar: Re-set first visible line after Scintilla size request
-- File Changes --
M git-changebar/src/gcb-plugin.c (4)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1280.patchhttps://github.com/geany/geany-plugins/pull/1280.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1280
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1280(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
When given, it specifies the kind introducing the scope information. May be another way to speed up parsing of scope in addition to the sZ field.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3598
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3598(a)github.com>