Please welcome a new way to build Geany and Geany-Plugins for Windows in the CI.
What's in here:
- the workflow job to checkout Geany-Plugins, Geany and Infrastructure repositories
- use the supporting scripts in https://github.com/geany/infrastructure/tree/add_ci_builders/builders to
- build a Docker image with a full MSYS2 installation (or pull the image from the Geany Docker registry if available)
- use this Docker image to:
- build Geany and create a release-like installer for it as build dependency for the G-P build (or use cache if available)
- install Geany from the previously built Geany installer
- build Geany-Plugins and create and test an installer
- store the Geany and Geany-Plugins installer as artifact on Github
Mostly all of the work is done in the builder scripts on https://github.com/geany/infrastructure/tree/add_ci_builders/builders.
Unfortunately, it grew more than than expected in terms of amount of code.
I tried to document at least the basics so anyone else than me will be available to get an idea what is happening.
Let me know if it worked :).
There is a difference to the Linux CI build which more or less aims at using a rather old setup to ensure backwards compability.
The Mingw-w64 build instead always pulls the latest available packages from the MSYS2 repositories.
I think this is OK as this is also what we do on releases and since we bundle all dependencies into the installer (for release builds as well as for CI builds), the result should be consistent.
Best of all: during the CI build Windows installers are created for Geany and Geany-Plugins and they are stored as artifacts and can be downloaded later on (up to 30 days).
TODO:
- this branch needs a bit more testing with this PR
- we need to merge the PR XXX first
- for now, the necessary Docker image was uploaded to https://github.com/geany/infrastructure/pkgs/container/geany-mingw64-ci by me manually. Basically we could push the image also from the CI job but I'm hesitating to allow this because of the risks it offers to malicious users. Maybe I'll add a separate job in the infrastructure repository later to build and push the image there and restrict this job to admins
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1201
-- Commit Summary --
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* Fix g-p source path
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
-- File Changes --
M .github/workflows/build.yml (140)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1201.patchhttps://github.com/geany/geany-plugins/pull/1201.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1201
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1201(a)github.com>
This is a followup of #2630 to fully port the `scripts/create_py_tags.py` script for generating tags for the Python standard library to Python 3.
While continuing on @claudep's work, I noticed plain porting is harder than to more or less rewrite the script. Now the script works by fully importing the modules, if possible, to use Python's `inspect.Signature` API to extract symbols. If this is not possible, the existing regular expression based parser is used as fallback.
Deprecated modules are ignored completely as well as a couple of special modules like the included Idle IDE and executable modules in general.
I'm using the resulting tags file since a few weeks and it feels fine, much better than before especially because of the better extracted argument lists of functions and methods.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3039
-- Commit Summary --
* Refs #2615 - Convert create_py_tags.py to Python 3
* Rewrite Python standard library tags creation script for Python 3
-- File Changes --
M data/tags/std.py.tags (27660)
M scripts/create_py_tags.py (486)
-- Patch Links --
https://github.com/geany/geany/pull/3039.patchhttps://github.com/geany/geany/pull/3039.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/3039
It's inconvenient to build and run a C/C++ program by clicking on both the button "build" and the button "run". Many other IDEs, for example, Code::blocks and Dev-C++, provide a "build and run" botton in their toolbars. Why not add a "compile and run" or "build and run" button to the toolbar of Geany?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3477
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3477(a)github.com>
Geany 1.38 was released in October 2021.
Lots of changes happened since, and people would be interested in them.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3418
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3418(a)github.com>
I’ve been using Geany with patches whereby [typeahead search](https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-v… in the symbols list and in [TreeBrowser](http://plugins.geany.org/treebrowser.html) uses [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-str-match-string) instead of simply matching by prefix.
Now, when I type “ba”, it finds not just `bar` but also `foo_bar` and `foo-bar`, etc. (not `FooBar` though).
It’s convenient.
The change itself is simple (all the heavy lifting is in GTK+/GLib), but I’m pretty sure this behavior cannot be made the default, as it might cause too many false positives, and would break habits.
What do you think of having such a feature as an option?
If suitable, what do you think its granularity should be? Should it be a checkbox for every tree view where it makes sense, like “Use fuzzy search in symbols list”, “Use fuzzy search in documents list” and so on?
(Also, I’m not sure it should be just [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-str-match-string). Maybe typing “ba” should find `FooBar` as well. Maybe typing “fb” should find `foo_bar`, like in [Commander](http://plugins.geany.org/commander.html).)
--
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/1466
Add `parsers/c-based.c` from ctags (the only change was to remove the `macroConditionRoleIndex` argument to `cppInit` as our ctags doesn't have it yet).
This is work in progress, I am making a list of things which aren't handled correctly that were by Geany:
* function template calltips - the runtime parameter list is not shown
* `template` decl members don't have parent
* TODO other things
Improvements:
* `alias foo = bar;` now parsed
* `static if` bodies now parsed but don't set parent
* more tag types rather than reusing existing types, listed under templates, aliases, mixins
* mixin statements now parsed
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3479
-- Commit Summary --
* Add warning that geany_c.c is not used for C & C++
* [D] Switch to mainline ctags parser
* Tweak tagmanager types
-- File Changes --
M ctags/Makefile.am (1)
A ctags/parsers/c-based.c (3073)
M ctags/parsers/geany_c.c (11)
M meson.build (1)
M src/tagmanager/tm_parser.c (20)
-- Patch Links --
https://github.com/geany/geany/pull/3479.patchhttps://github.com/geany/geany/pull/3479.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3479
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3479(a)github.com>
This enables a family of word-related text object commands such as:
"ciw", "diw", "viw" etc.
Fixes https://github.com/geany/geany-plugins/issues/1155.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1240
-- Commit Summary --
* vimode: Refactor motion-word.c so the motion commands can be reused
* vimode: implement "iw", "ow", "iW" and "oW" text objects
-- File Changes --
M vimode/README (4)
M vimode/src/cmd-runner.c (4)
M vimode/src/cmds/motion-word.c (323)
M vimode/src/cmds/motion-word.h (3)
M vimode/src/cmds/txtobjs.c (44)
M vimode/src/cmds/txtobjs.h (4)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1240.patchhttps://github.com/geany/geany-plugins/pull/1240.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1240
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1240(a)github.com>
While it would be nice to get rid of some extra tags, this field is generated in ctags using file name and also some questionable heuristics which doesn't lead to completely reliable results so better to avoid this field.
Reverts #3268.
Fixes #3454.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3457
-- Commit Summary --
* Don't use ctags isFileScope tag information
-- File Changes --
M src/tagmanager/tm_workspace.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/3457.patchhttps://github.com/geany/geany/pull/3457.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3457
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3457(a)github.com>