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