I've been happily using Geany for a little while now, coding mostly in
Python. I have a couple questions:
1. For a dark color scheme, eg Vibrant Ink, how do i get the active
line to not be highlighted. White text + white highlighting =
invisible text on the line I'm trying to edit. Arrgh!
2. Any debugger advice for python? I am finding winpdb is pretty slow
and actually crashes on my machine a fair amount.
I'm on a windows 7 64 bit installation.
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow
I've noticed that when I click on word in Split Window, and when I press
Ctrl+Shift+M, I do not get marked all words as the one selected.
Am I doing something wrong?
Thank you in advance.
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 .
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!
in the last couple of weeks I've been playing with Geany on OS X and got it
to the state where Geany is fully functional, integrated with OS X and have
a self-contained app bundle so Geany can be distributed without any
additional external dependencies. Apart from the few limitations listed
below I'm not aware of any problems.
This is where I would find it very useful if the brave souls among you who
are not scared of running unknown binaries from the Internet and who use OS
X could try out the binaries I uploaded here:
Any feedback is welcome.
* Integrated menubar
* Opening files from Finder using Open With
* Opening files using drag and drop to Geany icon
* Double-click on project file in Finder opens the project
* Retina font rendering
* All basic plugins (without extra dependencies) and themes included by
* The VTE terminal is missing (VTE doesn't work, seems to be a problem in
* Scrolling the editor window is somewhat slow using the mouse
* OS X 10.7 or higher (I have tested just with Yosemite)
* x64 processor
I will try to get all the necessary patches into Geany mainline (some are
already being reviewed, some - the integration ones - I haven't published
yet) and will make a github project with the app bundle creation
instructions + all the necessary config files, themes, icons, etc. I also
plan to provide OS X binaries for all the future Geany releases.
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 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
- 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
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.
I am using *geany 1.24* with *python 2.7* on *windows7*.
*Problem:* When i execute the python program immediately after
installation, It running good with out any problem. But if I execute after
closing the Geany at least once, it first opens the windows command window,
then asks permission to execute python. Then the program executes and two
windows will be opened. One of it will close so fast that I can not read
anything from it. the second window shows the message press enter to
When I have added, raw_input() at the end of the program, the first
window stood still on successful execution of the program only, but not in
the other instances.
I tried in interne to find solution. But I am not able to trace what has
to be done.