Hi List
This is a first post. I've been using geany for about 3 months, and in fact hacked it for the haXe (http://www.haxe.org) programming language. I didn't submit my hack as it wasn't in good enough shape or generic enough, and indeed fellow haxers had issues with my code completion for haXe. If you're interested in my old hacks I blogged about it here http://blackdog-haxe.blogspot.com/2007/05/geany-errr-haxedevelop.html
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
1. get currently selected class, variable etc from the Symbol tree. 2. keyboard short cuts for plugins. 3. process management, one of the issues i had in my old geany code was I had to fire off my own processes for the haXe code completion, it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks for you hard work, I hope I can add to it.
Cheers
bd
On 07/25/2007 04:04:19 PM, blackdog wrote:
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
- get currently selected class, variable etc from the Symbol tree.
I think you can access document::tag_store, but perhaps that's not enough information, if you want to check that the selected item is e.g. a class. It might need a patch for Geany to do it neatly. The symbol list GtkTreeStore now has a (hidden) line number column, but this could be replaced with a TMTag pointer, so you can tell what the tag type is as well as the line number.
- keyboard short cuts for plugins.
I've thought a bit about that, but not started on it yet.
- process management, one of the issues i had in my old geany code
was I had to fire off my own processes for the haXe code completion,
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support, which may be some work unless it is similar enough to JavaScript to use that lexer and parser.
it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Perhaps we can refactor a function to do this - you could look at the code for the 'Send selection to' command.
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks, although we have to make sure it stays that way ;-)
BTW the plugin system API is getting written as people need it, generally by whoever needs it extended; patches welcome. As long as it's a common function, it will probably get added. I don't see it being very powerful, as Geany has to remain lightweight.
Regards, Nick
Hi Nick
Thanks, although we have to make sure it stays that way ;-)
yes all this talk of VMs is scary :), that's why I'm excited about the plugin system - and why i knew my old patches wouldn't be accepted.
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support,
haxe is a bit funny as it uses type inference so it's difficult to infer lookups without running the full compiler, so the compiler has has an option to produce all type and variable info at a particular character in the source file, i.e. . or (, without producing code. Luckily the compiler is very fast. So that's why I need external processes. This is the standard way of doing this stuff in haXe (http://blog.haxe.org/entry/7)
I have haxe file support, which I'm patching from my old sources to the latest CVS. I'll send some patches later for all the basics, including symbol parser. Any funky bloated VM stuff :) will go into the plugin which will be released in a week or so if all continues to go well.
Thanks for the info
bd
Wed, 25 Jul 2007 17:03:05 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/25/2007 04:04:19 PM, blackdog wrote:
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
- get currently selected class, variable etc from the Symbol tree.
I think you can access document::tag_store, but perhaps that's not enough information, if you want to check that the selected item is e.g. a class. It might need a patch for Geany to do it neatly. The symbol list GtkTreeStore now has a (hidden) line number column, but this could be replaced with a TMTag pointer, so you can tell what the tag type is as well as the line number.
- keyboard short cuts for plugins.
I've thought a bit about that, but not started on it yet.
- process management, one of the issues i had in my old geany code
was I had to fire off my own processes for the haXe code completion,
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support, which may be some work unless it is similar enough to JavaScript to use that lexer and parser.
it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Perhaps we can refactor a function to do this - you could look at the code for the 'Send selection to' command.
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks, although we have to make sure it stays that way ;-)
BTW the plugin system API is getting written as people need it, generally by whoever needs it extended; patches welcome. As long as it's a common function, it will probably get added. I don't see it being very powerful, as Geany has to remain lightweight.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Something I'm not sure of is
filetypes[GEANY_FILETYPES_FORTRAN]->lang = 18;
where is the lang # defined? It doesn't match with GEANY_FILETYPES_ id or the FILETYPE enumeration.
Thanks
bd
On Wed, 25 Jul 2007 12:25:51 -0400 blackdog blackdog@ipowerhouse.com wrote:
Hi Nick
Thanks, although we have to make sure it stays that way ;-)
yes all this talk of VMs is scary :), that's why I'm excited about the plugin system - and why i knew my old patches wouldn't be accepted.
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support,
haxe is a bit funny as it uses type inference so it's difficult to infer lookups without running the full compiler, so the compiler has has an option to produce all type and variable info at a particular character in the source file, i.e. . or (, without producing code. Luckily the compiler is very fast. So that's why I need external processes. This is the standard way of doing this stuff in haXe (http://blog.haxe.org/entry/7)
I have haxe file support, which I'm patching from my old sources to the latest CVS. I'll send some patches later for all the basics, including symbol parser. Any funky bloated VM stuff :) will go into the plugin which will be released in a week or so if all continues to go well.
Thanks for the info
bd
Wed, 25 Jul 2007 17:03:05 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/25/2007 04:04:19 PM, blackdog wrote:
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
- get currently selected class, variable etc from the Symbol
tree.
I think you can access document::tag_store, but perhaps that's not enough information, if you want to check that the selected item is e.g. a class. It might need a patch for Geany to do it neatly. The symbol list GtkTreeStore now has a (hidden) line number column, but this could be replaced with a TMTag pointer, so you can tell what the tag type is as well as the line number.
- keyboard short cuts for plugins.
I've thought a bit about that, but not started on it yet.
- process management, one of the issues i had in my old geany
code was I had to fire off my own processes for the haXe code completion,
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support, which may be some work unless it is similar enough to JavaScript to use that lexer and parser.
it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Perhaps we can refactor a function to do this - you could look at the code for the 'Send selection to' command.
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks, although we have to make sure it stays that way ;-)
BTW the plugin system API is getting written as people need it, generally by whoever needs it extended; patches welcome. As long as it's a common function, it will probably get added. I don't see it being very powerful, as Geany has to remain lightweight.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Another suggestion
BeforeCompile, AfterCompile BeforeBuild, AfterBuild
callbacks that can be hooked into via the plug-in system.
they have these in monodevelop where you can hook in scripts and stuff during the compilation process.
bd
On Wed, 25 Jul 2007 12:50:02 -0400 blackdog blackdog@ipowerhouse.com wrote:
Something I'm not sure of is
filetypes[GEANY_FILETYPES_FORTRAN]->lang = 18;
where is the lang # defined? It doesn't match with GEANY_FILETYPES_ id or the FILETYPE enumeration.
Thanks
bd
On Wed, 25 Jul 2007 12:25:51 -0400 blackdog blackdog@ipowerhouse.com wrote:
Hi Nick
Thanks, although we have to make sure it stays that way ;-)
yes all this talk of VMs is scary :), that's why I'm excited about the plugin system - and why i knew my old patches wouldn't be accepted.
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support,
haxe is a bit funny as it uses type inference so it's difficult to infer lookups without running the full compiler, so the compiler has has an option to produce all type and variable info at a particular character in the source file, i.e. . or (, without producing code. Luckily the compiler is very fast. So that's why I need external processes. This is the standard way of doing this stuff in haXe (http://blog.haxe.org/entry/7)
I have haxe file support, which I'm patching from my old sources to the latest CVS. I'll send some patches later for all the basics, including symbol parser. Any funky bloated VM stuff :) will go into the plugin which will be released in a week or so if all continues to go well.
Thanks for the info
bd
Wed, 25 Jul 2007 17:03:05 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/25/2007 04:04:19 PM, blackdog wrote:
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
- get currently selected class, variable etc from the Symbol
tree.
I think you can access document::tag_store, but perhaps that's not enough information, if you want to check that the selected item is e.g. a class. It might need a patch for Geany to do it neatly. The symbol list GtkTreeStore now has a (hidden) line number column, but this could be replaced with a TMTag pointer, so you can tell what the tag type is as well as the line number.
- keyboard short cuts for plugins.
I've thought a bit about that, but not started on it yet.
- process management, one of the issues i had in my old geany
code was I had to fire off my own processes for the haXe code completion,
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support, which may be some work unless it is similar enough to JavaScript to use that lexer and parser.
it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Perhaps we can refactor a function to do this - you could look at the code for the 'Send selection to' command.
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks, although we have to make sure it stays that way ;-)
BTW the plugin system API is getting written as people need it, generally by whoever needs it extended; patches welcome. As long as it's a common function, it will probably get added. I don't see it being very powerful, as Geany has to remain lightweight.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 07/25/2007 07:27:25 PM, blackdog wrote:
Another suggestion
BeforeCompile, AfterCompile BeforeBuild, AfterBuild
callbacks that can be hooked into via the plug-in system.
Maybe, what do you need them for? If you want to submit a patch, I would use the build_type enum:
void after_build(build_type btype);
Instead of having one callback for each type of build action.
Regards, Nick
Hi Nick
I was using these events in monodevelop, you can use them for anything, i was uploading stuff after a build. I was just thinking of stuff which maybe easy to add and is competitive with other packages - not that that is so important.
However, on reflection, but on the same lines, what maybe is more useful, is an event system where any code in geany can register an event, fire and listen. Maybe gobject has this already, need to investigate, maybe you have something already that I'm not aware of?
Anyway with some kind of event system, my first suggestion would just get implemented naturally in a plug in when it was needed, so really an event system is key, not which events.
cheers
bd
On Fri, 27 Jul 2007 11:27:39 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/25/2007 07:27:25 PM, blackdog wrote:
Another suggestion
BeforeCompile, AfterCompile BeforeBuild, AfterBuild
callbacks that can be hooked into via the plug-in system.
Maybe, what do you need them for? If you want to submit a patch, I would use the build_type enum:
void after_build(build_type btype);
Instead of having one callback for each type of build action.
Regards, Nick
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Hi all together!
I'm a python developer and at the moment I'm writing my own editor style. It looks very nice but one thing I did not found was the color of the line highlightning. Is that changeable? Because my style has a dark background and the line will be displayed white. That's not really nice ;)
Thanks much for that nice editor!
Regards, Christopher Grebs
On 7/27/07, Christopher Grebs chrissiG@gmx.net wrote:
Hi all together!
I'm a python developer and at the moment I'm writing my own editor style. It looks very nice but one thing I did not found was the color of the line highlightning. Is that changeable? Because my style has a dark background and the line will be displayed white. That's not really nice ;)
Hi Christopher,
If you're setting your colorscheme manually (without using set_geany_colors.py), then it's in filetypes.common as "current_line". If you're using set_geany_colors.py, it's now "curr_line_bg".
Note, I just updated set_geany_colors.py such that your own ~/.geany/colorschemes/foo.conf files no longer need those extra outer underscores in the names listed under "[colorschemes]".
http://www.milliwatt-software.com/jmg/files/set_geany_colors.py.bz2
(Of course, if you get rid of (or rename) your colorschemes directory and run the program again, it'll regenerate a new directory and example colorscheme for you.)
---John
Never mind, found it
bd
On Wed, 25 Jul 2007 12:50:02 -0400 blackdog blackdog@ipowerhouse.com wrote:
Something I'm not sure of is
filetypes[GEANY_FILETYPES_FORTRAN]->lang = 18;
where is the lang # defined? It doesn't match with GEANY_FILETYPES_ id or the FILETYPE enumeration.
Thanks
bd
On Wed, 25 Jul 2007 12:25:51 -0400 blackdog blackdog@ipowerhouse.com wrote:
Hi Nick
Thanks, although we have to make sure it stays that way ;-)
yes all this talk of VMs is scary :), that's why I'm excited about the plugin system - and why i knew my old patches wouldn't be accepted.
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support,
haxe is a bit funny as it uses type inference so it's difficult to infer lookups without running the full compiler, so the compiler has has an option to produce all type and variable info at a particular character in the source file, i.e. . or (, without producing code. Luckily the compiler is very fast. So that's why I need external processes. This is the standard way of doing this stuff in haXe (http://blog.haxe.org/entry/7)
I have haxe file support, which I'm patching from my old sources to the latest CVS. I'll send some patches later for all the basics, including symbol parser. Any funky bloated VM stuff :) will go into the plugin which will be released in a week or so if all continues to go well.
Thanks for the info
bd
Wed, 25 Jul 2007 17:03:05 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/25/2007 04:04:19 PM, blackdog wrote:
The addition of the plugin system allows me to write something significant without stepping on toes which I wasn't able to do before. I'm doing a Neko VM plugin for geany (Neko is the haxe VM, see http://www.nekovm.org). This allows the creation of geany plugins in haXe using my hxGtk library. Anyway that's a work in progress, right now I'm wondering if anyone is working on the the plugin API in the following areas:
- get currently selected class, variable etc from the Symbol
tree.
I think you can access document::tag_store, but perhaps that's not enough information, if you want to check that the selected item is e.g. a class. It might need a patch for Geany to do it neatly. The symbol list GtkTreeStore now has a (hidden) line number column, but this could be replaced with a TMTag pointer, so you can tell what the tag type is as well as the line number.
- keyboard short cuts for plugins.
I've thought a bit about that, but not started on it yet.
- process management, one of the issues i had in my old geany
code was I had to fire off my own processes for the haXe code completion,
Perhaps you're doing something special to lookup the code completion, but to do it efficiently you would generate a tags file for haXe, put it in ~/.geany/tags and Geany would use it when editing haXe files. Of course, that would require haXe filetype support, which may be some work unless it is similar enough to JavaScript to use that lexer and parser.
it would be good if there was a standard way of executing a an external process and getting the result in a friendlier way for toolwriters rather than g_spawn_async_with_pipes
Perhaps we can refactor a function to do this - you could look at the code for the 'Send selection to' command.
Just want to say it's a great project and I find the small footprint and speed extremely refreshing, I was using JEdit prior to Geany and really got ticked off with 60MB RAM consumption.
Thanks, although we have to make sure it stays that way ;-)
BTW the plugin system API is getting written as people need it, generally by whoever needs it extended; patches welcome. As long as it's a common function, it will probably get added. I don't see it being very powerful, as Geany has to remain lightweight.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany