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,
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.
Hello all,
I have installed a buildenvironment on my Win32 virtualbox.
I want to investigate in the source code and have some debug output from
the running application.
I tried printf as well as geany_debug. I also set G_MESSAGES_DEBUG=all.
However starting the application from the commandshell cmd:
- returns immediatel to the promt, without waiting the application to close,
- does not output any debug hint on the console.
Could you guide me how to have some informative output from the running
application.
Regards,
Adib.
--
Hi, I recently started to need to open 2 different instances of geany on
windows to fit the two monitors and realized that the right click on tab
--> Open in New Window does not work in windows os.
I also tried the nightly build and the bug is still not fixed.
I wanted to ask you if you plan to fix it for the next release and
otherwise if there is a howto about building geany on windows (or how to
cross compile it from linux) so that I can fix the bug myself and send you
the patch.
Thank you for your work, All the Best,
Giuseppe.
I want to say, that it would be nice, if a DocumentMap/MiniMap would be added to Geany. Please add it to the Wishlist on your side.
Notepad++ have something called "Document Map":
http://notepad-plus-plus.org/assets/images/docMap.png
Sublime Text have something called "MiniMap":
http://www.sublimetext.com/screenshots/new_theme_large.png
Since some time, Kate have a MiniMap, too:
http://kate-editor.org/2012/11/03/busy-katekdevelop-sprint-results-in-mini-…
All three have a line, where with very small fonts a bigger part of the document is shown and the current visible part of the Textarea have a colored background in the map.
But they differ in additional functionality of it.
Where Sublime Text only shows the MiniMap, Kate on the other side, can replace the scrollbar with it. And on Notepad++ it is a mix between the two. The scrollbar is still there, but you can click in parts of the Document Map, to jump to that position.
An additional point I want to mention, is a bug in your Webside-software.
As I wanted to add this wish to the wishlist, I clicked at the bottom of the page on "edit this page" of the line "(If you have another idea/wish which should be listed here, edit this page)".
Then it asks for a username and password. Because I don't have an account for it, and I find no place to register, I have somewhat input. After that it shows be an empty page and Geany.org was no longer available.
I thought, it would be an coincidental/hazard/fortuity/hap, that that happens.
But now there was again Geany.org reachable, then I tried it again. And again the Geany-side was after that down. :-(
So please update your Geany homepage software. Or it is really a very big coincidental/hazard/fortuity/hap, that in two times the Geany side goes in that time down, I tried to login there.
Greatings
theuserbl
Hi all,
I have received several bugreports about PairTagHighlighter plugin. The
subject is described on Github
<https://github.com/vmkononenko/pair-tag-highlighter/issues/1>.
While debugging I see that plugin is trying to clear highlighting on
appropriate ranges, but nothing happens after SCI_INDICATORCLEARRANGE. BTW,
I've checked, that clearing range is called for the correct indicator.
The issue is not reproducible on 1.23.1, while on 1.24.1 it has stable
reproducibility.
I've found the issue <http://sourceforge.net/p/scintilla/bugs/1604/> in
Scintilla, which I suppose is related to subject. This issue was fixed in
Scintilla after 3.4.2. In Geany codebase Scintilla was updated to 3.4.4
with 46affaf commit. I want to check if the issue is reproducible on this
revision and one revision before.
Please, tell me how to build a certain version of Geany and plugin for it,
because my playing with --with-geany-libdir and --prefix was unsuccessful.
If you have another ideas why the issue could happen, please let me know.
Thanks in advance!
--
Best regards,
Volodymyr Kononenko
http://kononenko.ws
Dear all,
Recently I've discovered Coverity, a code checking tool, and went
ahead and submitted the Geany code for static analysis by this
service:
https://scan.coverity.com/projects/1388
Coverity has uncovered ~55 implementation defects in the code
base, with 25 or so of high severity (memory corruption, resource
leaks, etc.) To view the defects, you need to connect with your Github
account (or create one with Coverity) and request 'Add me to project'
(which I shall then approve). Coverity provides overall metrics like
defect density (Geany scores an impressive 0.23), but also classifies
uncovered bugs by type and severity, and provides a nice UI trying to
explain to the devels the specifics of the bug and how to address it
(e.g. where it happens, why it's an issue, etc.)
This tool is being used by heavyweights like LibreOffice, the Linux
Kernel, Firefox or Python to improve the robustness of their code
base. I suspect that Coverity could prove invaluable when trying to
hunt down frustrating implementation issues causing obscure bugs.
In any case the identified bugs are now ready for inspection by the
devels, so feel free to drop by!
Regards,
Liviu
--
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library
