Hi I am a competitive programmer and I like to reuse parts of the code but I find adding snippets in snippets.conf to be a bit tedious. Does a simple way exist?
--
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/2481
The Requirements section of the devhelp plugin page under http://plugins.geany.org lists the following items:
- GTK >= 2.16
- libwebkitgtk >= 1.1.18
- libdevhelp 1.0 >= 2.30.1 or libdevhelp 2.0 >= 2.32.0
Looking at the makefile I see this requirements:
```
[gtk+-2.0 >= ${GTK_VERSION}
webkit-1.0 >= ${WEBKIT_VERSION}
libwnck-1.0 >= ${LIBWNCK_VERSION}
gconf-2.0 >= ${GCONF_VERSION}
gthread-2.0
zlib])
```
On my Ubuntu machine only ```libwebkit``` and ```libwnck``` were missing. Not sure if the list on the plugin page should be extended.
--
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/626
If one creates a Julia file and writes some code into it, one would expect all declared variables to be shown in the symbols list on the left. However, this is not the case, for instance in this code here:
```
a::Int8 = 3
function f(x)
return 2x
end
```
the variable `a` is not shown in the symbols list, but the function `f` is shown. Is this the normal behavior or is it a bug?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3341
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3341(a)github.com>
Every placeholder in the Statusbar Template may also specify width, e. g. `%3l`. Width is the minimum number of characters to be shown. If the value is shorter than width, the result is left-padded with spaces, or right-padded in case of negative width. The value is not truncated even if the result is larger.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3221
-- Commit Summary --
* Statusbar Template enhancement: width specifier.
* Style fix.
* Debug code dropped.
-- File Changes --
M doc/geany.txt (26)
M src/ui_utils.c (71)
-- Patch Links --
https://github.com/geany/geany/pull/3221.patchhttps://github.com/geany/geany/pull/3221.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3221
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3221(a)github.com>
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
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>