Hi all,
I just made a test build of Geany Plugins 1.22 for Windows.
A little surprisingly for me, it all worked fine on the first attempt :).
I only had problems loading the Geany-Lua plugin with some strange error
message which I didn't investigate yet:
http://pastebin.geany.org/EUmwJ/
The error message occurs on plugin loading. I'm not sure whether it is
caused by my system or something else.
If anyone wants to test it, any feedback is appreciated.
The installer...
http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe
... requires an existing Geany 1.22 installation.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi everyone,
I don't use my Windows VM very often, but I realized today that the
completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell
me whether it works for them or not, and their Windows and GTK versions?
I myself tried on XP SP3 with GTK 2.24.10.
I found a way to fix the issue, and although it doesn't make any sense,
it seem to fix it reliably. Unfortunately it has a small side effect
that completion popup will have a minimal height that might be taller
than necessary when there is only one item in the list. But this
cosmetic detail is probably less problematic than a blank popup, right? :)
But I'd like to know if the problem happens to everyone or not, and
whether the attached patch fixes the problem for everyone with the issue.
Thanks in advance!
Colomban
[1]
http://git.geany.org/geany/commit/?id=4d66bd3745eb3759539b116e7784d11d035eb…
Hi guys,
I've noticed the GeanyLua plugin does not build with Lua versions
greater than 5.2. I've stumbled over this since I updated to the
current version of Fedora 22 Beta which is with Lua 5.3.0 already.
Is someone able to fix the issues and make the plugin compatible with
Lua versions greater than 5.2? Otherwise it will be quite a pity since
I would have to disable the plugin in the Geany Plugins Fedora package
then.
I unfortunately am not able to have deeper looks into this myself, for
both reasons, missing knowledge and missing time.
Regards,
Dominic
--
Dominic Hopf
http://dominichopf.de/
Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
On 10.4.2015 г. 18:36, Colomban Wendling wrote:
> waf: Fix the checks for openpty() on FreeBSD
ACK. Please, be sure to use the same check for debugger, it probably
needs it.
While on configuring, the README file still lists gtk+ 2.16 as a minimum
requirement for Geany - but it's actually 2.18 with GtkInfoBar now,
right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is
the minimum required version...
--
E-gards: Jimmy
Le 12/04/2015 22:54, Enrico Tröger a écrit :
> Branch: refs/heads/master
> Author: Enrico Tröger <enrico.troeger(a)uvena.de>
> Committer: Enrico Tröger <enrico.troeger(a)uvena.de>
> Date: Sun, 12 Apr 2015 20:54:16 UTC
> Commit: f03206744361baac1c811db97f5d2816409d7787
> https://github.com/geany/geany/commit/f03206744361baac1c811db97f5d2816409d7…
>
> Log Message:
> -----------
> Windows: Compile geany_private.rc into Geany.exe for version data and icon
Should we integrate geany_private.rc in the library too? This isn't
done with Autotools, but could be added.
Though, `waf build -v` warns that geany_private.rc.o is created more
than once (doesn't seem to be a real problem though).
On 20.4.2015 г. 20:09, Frank Lanitz wrote:
> Log Message:
> -----------
> Scope: Fix a typo
>
> -<property name="label" translatable="yes">Show =li_brary messages</property>
> +<property name="label" translatable="yes">Show li_brary messages</property>
That's not a typo, they are =library-...
"library" alone does not carry enough info.
--
E-gards: Jimmy
Hi,
If you package Geany for Linux, you might like to have a quick look at
PR #461[0], I want to make sure the absolute path in the desktop file
won't cause anyone issues.
Cheers,
Matthew Brush
[0]: https://github.com/geany/geany/pull/461
Hi,
To offload the discussion from PR#441 [1] from this partly off-topic
discussion and give it more visibility, I'm moving it here to the ML.
There already was a thread on the subject that got mostly forgotten, see
[2].
I apologize for the long and complex email, but I don't know how to
present that in a more concise way without losing important information
or clarity.
Note: I will use *NIX-style command lines as examples. The ones for
Windows are slightly different, but the problematic is basically the
same (though we don't use the shell there so it's a bit simpler).
1. So, what are we talking about?
Some of our commands can contain placeholders. The most important ones
are the build commands, but also e.g. the terminal tool has '%c'. These
placeholders are replaced by Geany with various things, like file names,
paths, line numbers etc.
Some of the commands are executed by a shell (build commands) and some
aren't (terminal command).
2. What is the problem?
The replacement for these placeholders can be anything, so they might
contain characters that have a meaning in a command. The most obvious
example is quotes: imagine a file named `foo "bar.c`. If we just
replace the placeholder with the raw value (as we currently do) in a
build command, e.g. `gcc -c -o %e.o "%f"`, it gives this:
gcc -c -o foo "bar.o "foo "bar.c"
which is obviously incorrect (see [1] or [2] if it's not obvious for you ;)
We need to escape (or quote) replacements in some way or another.
3. So, how can we fix this?
Several solutions have been suggested (well, actually 3.5 is new!), each
with pros and cons:
3.1. Insert quoted replacement as needed where they appear
This is what I first implemented: track the quotes in the user command,
close them before inserting a quoted/escaped replacement, and reopen it
right after. With the above command, it would give this:
gcc -c -o 'foo "bar'.o ""'foo "bar.c'""
which is valid and as we want it (again, see [1] and [2] if it's not
clear that it's valid).
This is what the patch at [3] (and [2], but the version there is
outdated) does.
3.1.1. Pros
* compatible with any current user commands (no breakage of the user
configuration, and fixes replacement in them);
* the user doesn't have to worry about the issue.
3.1.2. Cons
* requires understanding of the shell quoting rules (including sub-shell
like `` and $()), which might be non-trivial.
* if it gets something wrong, the users are mostly screwed (the only
thing they could do would be try to adapt the command in a way for Geany
to get it right)
3.2. Insert quoted replacements everywhere blindly
Replace blindly each placeholder with an escaped/quoted version of
itself. This is like 3.1 but doesn't try to manage quotes in the input
command. It would give:
gcc -c -o 'foo "bar'.o "'foo "bar.c'"
(which is incorrect, see the cons below)
3.2.1. Pros
* easy to implement;
* simple, the user can easily know exactly what happens.
3.2.2. Cons:
* Incompatible with (some) current user commands: as the placeholder is
replaced without care, the placeholders need to appear outside other
quotes. E.g. the above example would have to be altered to remove
quoting around the %f placeholder not to be quoted twice: `gcc -c -o
%e.o %f`.
3.3. Provide format modifier performing specific quoting
Dimitar suggested introducing format modifiers like %"f or %'f that
would quote in various ways (see
https://github.com/geany/geany/pull/441#issuecomment-87272057).
3.3.1. Pros
* The users can quote in various ways as they see fit;
* Explicit control on how things are quoted/escaped;
* Could support recursive quoting (quoting twice or even more), so Lex
could use it in a `python -c` or similar called by the shell ;) e.g.
`python -c "print(%\""f.replace(' ', '_'))"` could end up in `python -c
"print("foo\ \\\"bar.c".replace(' ', '_'))"` -- assuming we implement
the escaping Python requires. happy? :)
3.3.2. Cons
* it doesn't fix existing user commands (needs to make use of the new
format modifiers);
* requires to implement various kind of quoting (which requires knowing
several shell escaping rules);
* complex and uncommon format modifiers (the users have to pick the
right one, which might not be obvious);
* the users can screw themselves up if they don't use the appropriate
format (could work with some replacement but not others).
3.4. Parse command as an argument vector and replace in each argument
Instead of working on the command itself, use g_shell_parse_argv() and
perform replacements in argv[1:] (each argument separately).
3.4.1. Pros
* no need for quoting or escaping the replacement (as each argument is
done on its own).
3.4.2. Cons
* doesn't work with shell constructs, so it's not a solution for build
commands (as an argv is an argv, which can't support sub-shell, piping
and whatnot).
3.5. Use environment variables, not placeholders
Change the whole logic and use the environment to pass what currently
uses placeholders. E.g. a command could be `gcc -c -o
"${GEANY_FILENAME_NOEXT}.o" "$GEANY_FILENAME"`.
3.5.1. Pros
* quite easy to implement (but see cons);
* no need for quoting or escaping replacements;
* works the same as any environment or shell variable;
* environment variables can then also be used by the called commands
themselves, not only on their command line.
3.5.2. Cons
* it doesn't fix existing user commands (needs to make use of the new
variables);
* requires separate logic (e.g. 3.4) when the command is not run in a
shell (as something has to read the replace on the command line itself);
* the users can screw themselves up if they don't use the appropriate
quoting around the variables (could work with some replacement but not
others).
4. So, what?
I like 3.1 ("smart" replacement) and 3.5 (environment variables) mostly.
3.1 is the only solution here that doesn't require changes in user
commands, so it is seamless on the user. 3.5 leaves the actual
replacement to the shell (so the limitations are the ones of the shell),
and also gives the information to the children, grandchildren, etc.
Note that we perhaps could use something like 3.1 simply to upgrade user
commands to the format of one of the other solutions. This way an error
in the implementation of 3.1 can be fixed by the user.
What do you think?
Regards,
Colomban
[1] https://github.com/geany/geany/pull/441
[2] http://lists.geany.org/pipermail/devel/2012-December/007329.html
[3] https://github.com/geany/geany/pull/441#issuecomment-87336184 and
https://gist.github.com/b4n/4c100d6f1defd4751217
Hello,
tl;dr -> scroll down
I am working on a new plugin architecture that deals with some of the
shortcomings of the current state. My primary motivation is to be able
to use libpeas to load plugins, both C and non-C (Python!), as you might
have learned from other threads I started. However the situation can be
improved regardless of that goal.
List of current shortcomings:
- (A separate change but nevertheless: ) Currently geany exports a
pointer to a struct, that contains more structs, which contain function
points to the API functions. Fortunately this is nicely hidden to
developers via macros. But due to gtkbuilder all functions and nothing
prevents plugins from accessing these. And the macros are awkward and
strange anyway. There is currently the linkage-cleanup PR in the works
which improves this by actually exporting the API functions, and _only_
the API functions to plugins.
- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in theory).
Luckily on unix or win32 systems this is not a problem because they can
restrict the symbol visibility of shared libraries. It's still bad
practice. Ideally plugins should have zero global symbols, everything
being static or hidden to the plugin binary.
- The plugin entry points / callbacks are inconsistent w.r.t to the
parameters they receive, and none receive some kind of a plugin handle
referencing to the plugin itself (there is only the geany_plugin global).
- The plugin entry points / callbacks do not allow for the plugin
associate private/user data with the plugin handle, except hand-maintain
hash tables. This is not a problem for the most part because it can be
stored in some plugin-wide static variable, however it does become
problematic when you attempt to have one plugin act as a proxy for other
plugins (see geanypy or my pluxy effort)
- The plugin does the ABI/API verification. We currently trust the
plugins to use PLUGIN_VERSION_CHECK() or otherwise implement
plugin_version_check() correctly. Plugins decide whether they are
api/abi compatible with geany. Pure crazyness!
- Plugins cannot register plugins recursively. It would be awesome if
a plugin could register a plugin on behalf of others, in such a manner
that they appear in the PM dialog and can be handled by the user like
normal plugins (*proper* proxy plugins are not possible).
To improve the situation I propose the following mechaism and new plugin
hooks:
tl;dr <-
Key functions
gboolean geany_load_module(GeanyPlugin *, GModule *)
gboolean geany_plugin_register(GeanyPlugin *, gint api, gint abi,
PluginHooks *(see below), gpointer)
The plugin defines a single global function,
geany_load_module(GeanyPlugin *, GModule *). This is the only function
that geany learns about using g_module_symbol(). And the only thing this
function ought to do is to call geany_plugin_register(). This does 4 things
1) Provide the plugin handle to the plugin very early
2) Perform abi and abi checks, so this is finally done inside geany.
Added bonus is that geany knows the requested api and can possibly apply
backcompat workarounds on a per plugin basis (instead of globally), warn
about very old plugins or even deny loading them.
3) Register the remaining hooks and callbacks (see below)
4) Associate a userdata pointer to the plugin, geany will pass this
pointer back to future calls into the plugin (good for proxies)
In the future geany_plugin_register should be able to be used to
register plugins recursivly, by passing the appropriate GeanyPlugin
pointer, i.e. plugin A should be able to call
geany_plugin_register(plugin_B, ...) to realize pluxies.
Now to the plugin hooks:
typedef struct _PluginHooks
{
PluginCallback *callbacks;
void (*set_info) (GeanyPlugin *plugin, gpointer pdata);
void (*init) (GeanyPlugin *plugin, gpointer pdata);
GtkWidget* (*configure) (GeanyPlugin *plugin, GtkDialog *dialog,
gpointer pdata);
void (*help) (GeanyPlugin *plugin, gpointer pdata);
void (*cleanup) (GeanyPlugin *plugin, gpointer pdata);
}
PluginHooks;
These are analogous and semantically equivalent to the current
functions. The only difference is the parameters that are passed to
them, and of course how they are registed. Additionally the existing
PluginCallbacks pointer registered here for all plugins that want
statically defined signal handlers.
There is no version_check() hook because that's now done inside geany,
and the long deprecated configure_single is phased out. Please also note
that each hook receives the GeanyPlugin pointer and the userdata
pointer, these are the same passed to geany_plugin_register.
With this new mechanism, proxy plugins are more than doable. geanypy
should benifit as well.
I have implemented this so far and adapted the demo plugin. The code is
at[1]. Please have a look and/or comment on my proposal or contribute
your ideas. Thanks!
[1] https://github.com/kugel-/geany/tree/new-plugins
Best regards
Hello,
I was asked to share a bit about my roadmap regarding plugins. I'll try
to give you a better idea with this post.
My ultimate goal is to implement a clean and maintainable way to support
non-C plugins, preferably using existing widely used techniques. I
concluded that libpeas[1] in conjunction with gobject-introspection can
provide the base for this. Since Geany is not at all prepared for this I
have several infrastructure which I do want to get merged into Geany.
When Geany core is sufficiently setup for this, the non-C plugin
enablement can happen outside the core, as a plugin, to stabilize there.
So, here's the set of infrastructure changes for the core. Please let me
stress that all of this will happen in backward-compatible manner, no
existing plugins break as part of this.
- linkage-cleanup (PR#429) - This changes the way plugins access Geany
API functions. Instead of exporting a pointer to a struct of structs of
API function pointers, now the APIs are exported directly. This work
also includes an effort to stop exporting all function (we do this
currently as a workaround to allow gtkbuilder to work), so *only* API
function are exported and plugins cannot call internal function anymore.
This change is also required to allow gobject-introspection to find
geany functions at runtime (through g_module_symbol()) in the future.
- new API functions for registering keybindings (PR#376). The current
API functions do not allow context information to be stored and passed
to the key handler function. This makes it very hard for non-C plugins
to use these function. So what's needed are key handlers that get the
necessary context information. This allows interprepted language plugins
to register keybindings.
- A new plugin loader mechanism (a thread about this is already running
on the devel list): Similarly to the keybindings, the plugin_* functions
implemented by plugins do not carry any context information, making it
hard for non-C plugins to implement them properly. Therefore a new
loader mechaism is needed so that the context information can be passed.
The loader works such that an API function is called to register a
function pointer table. This is crucial to possibly support plugins that
register other plugins (so called pluxies) which is simply not possible
with the current mechaism. The current loader is kept for backwards
compatibility (but will not receive new features).
- New API functions to allow plugins to act as proxy plugins (pluxies).
These pluxies can then implement whatever is needed to execute code in
the in the actual plugin, like invoking an interpreter or firing up a
java vm. The pluxies call the new loader's API function on behalf of the
actual plugin. The API function to implement the pluxies is a simple
geany_register_pluxy() that, much like the normal plugin loader, that
pluxies use to pass a function pointer table which implements the
necessary hooks (probe(), load() and unload())
Once this is in place in the core, my roadmap contains the following
items, which are implemented (at least initially) in a plugin, so no
further changes to the cure should be necessary.
- Modify geanypy to use the new pluxy APIs. This will finally enable
geanypy to show the python plugins in the normal PM dialog and support
keybindings
- Create a new pluxy that supports libpeas-based plugins (codename:
peasy). Peasy will use libpeas to load plugins and their metadata.
- Part of the peasy work is also work on creating vala and
gobject-introspection bindings for Geany's API functions, so that we can
support python, javascript and lua out of the box.
This is my roadmap so far. It changed quite a bit since I started this
non-C-plugins effort a year ago, but I hope it will be good for
everyone. Please share your opinions on this or ask questions.
Best regards.