Hi.
I started to write a plugin for auto-completion of haxe-code. The Haxe compiler has a feature that it compiles up to a certain point in a file and then spits out a list of possible classes and types for the file at that point, see here: http://ncannasse.fr/blog/haxe_completion There once was a plugin for using it called hxDev (latest version hxDev2): http://lib.haxe.org/p/hxDev2 But it doesn't compile with the newest plugin-API anymore. I couldn't really figure out what to change and where to make it work, so I tried to start from scratch. Thanks to your nice plugin-API and good documentation of it I managed to get a running plugin in a couple of days, although it's my very first attempt in GTK-programming.
Now I have a couple of questions: - Would it make sense to add it to the geany-plugins repository (because it's very language-specific)? - I'm not sure what kind of build-system to use now. ATM I simply added my plugin to wscript and use waf. Is waf deprecated now with the new merged plugin-build-system? Is a makefile or a autogen.sh script better? - The plugin depends on editor-notify of PluginCallback. Is it OK to add that signal globally (will be called for all documents then, right?) and then check for haxe-files or would it be better to add that signal only when a haxe-file is active? - I saw a property "type" in the GeanyProjects-struct that seems to mean that projects can be extended by plugins. Is there some documentation for this? It would be really nice to be able to add some options for haxe-projects. I also read in a post here that there is a build-system-upgrade in the making with lots of options that can be set from projects. Maybe this would do already. Any plans when this will be merged in the trunk?
Best regards and thanks for making this great editor.
-- Mockey
2009/6/28 Andreas Mokros am@medienpensionat.com
Hi.
I started to write a plugin for auto-completion of haxe-code. The Haxe compiler has a feature that it compiles up to a certain point in a file and then spits out a list of possible classes and types for the file at that point, see here: http://ncannasse.fr/blog/haxe_completion There once was a plugin for using it called hxDev (latest version hxDev2): http://lib.haxe.org/p/hxDev2 But it doesn't compile with the newest plugin-API anymore. I couldn't really figure out what to change and where to make it work, so I tried to start from scratch. Thanks to your nice plugin-API and good documentation of it I managed to get a running plugin in a couple of days, although it's my very first attempt in GTK-programming.
Now I have a couple of questions:
- Would it make sense to add it to the geany-plugins repository
(because it's very language-specific)?
- I'm not sure what kind of build-system to use now. ATM I simply added
my plugin to wscript and use waf. Is waf deprecated now with the new merged plugin-build-system? Is a makefile or a autogen.sh script better?
- The plugin depends on editor-notify of PluginCallback. Is it OK to
add that signal globally (will be called for all documents then, right?) and then check for haxe-files or would it be better to add that signal only when a haxe-file is active?
- I saw a property "type" in the GeanyProjects-struct that seems to
mean that projects can be extended by plugins. Is there some documentation for this? It would be really nice to be able to add some options for haxe-projects. I also read in a post here that there is a build-system-upgrade in the making with lots of options that can be set from projects. Maybe this would do already. Any plans when this will be merged in the trunk?
The build-system upgrade is making the build menu fully configurable from projects and/or preferences overriding the defaults, allowing both menu item labels and commands to be configured. I'm not sure if this will help you, although extra filetype configurable commands may be helpfull. Currently the structures and functions relating to this are not part of the plugin api, more discussion would be needed about extending the api (pro more capability for plugins, con more to maintain and limits on changing Geany internals, potential unexpected interactions between plugins and configuration).
It is progressing, although it is taking longer than expected to untangle interactions with other parts of Geany. A prototype should be available on the build-system branch late next week, watch this ML. With such a big change I guess a bit ;-) of testing will be needed prior to merge to trunk.
Cheers Lex
Best regards and thanks for making this great editor.
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 27 Jun 2009 17:01:40 +0200, Andreas wrote:
Hey Mockey,
I started to write a plugin for auto-completion of haxe-code. The
Cool.
Now I have a couple of questions:
- Would it make sense to add it to the geany-plugins repository
(because it's very language-specific)?
Why not. If users don't want it because they don't use Haxe, they don't have to compile/install it. And still you can choose whether you want to have it as part of the geany-plugins project with its advantages like no need to maintain an own build system and getting translations and releases for free (i.e. you don't need to manage it yourself) or by just hosting your plugin at the "geany-plugins" Sourceforge project while maintaining it on your own, with own build system and such. It's completely up to you.
- I'm not sure what kind of build-system to use now. ATM I simply added
my plugin to wscript and use waf. Is waf deprecated now with the new merged plugin-build-system? Is a makefile or a autogen.sh script better?
Waf is by no means deprecated, on the contrary, now we can very easily build the plugins even on Windows, thanks to the Waf build system we are using. More generally about the build systems for plugins: we recently merged some existing plugins into a common geany-plugins project which mainly means that all the merged plugins now use one common build system (actually, we use Waf and autotools in parallel, i.e. the user can choose which one to use) but the plugins don't have an own build system anymore. Reasons and advantages of this approach can be found in the list archives (happened in the last two weeks). So, neither Waf nor autotools are deprecated at all, we just moved some plugins and changed their organisation a bit.
- The plugin depends on editor-notify of PluginCallback. Is it OK to
add that signal globally (will be called for all documents then, right?) and then check for haxe-files or would it be better to add that signal only when a haxe-file is active?
Just add it globally, this is how it is intended to be used. In the handler simply add a prominent check like this:
if (editor->document->file_type != GEANY_FILETYPES_HAXE) return FALSE;
This should be ok.
- I saw a property "type" in the GeanyProjects-struct that seems to
mean that projects can be extended by plugins. Is there some documentation for this? It would be really nice to be able to add
No, not really. AFAIK the only plugin which makes use of this is the geanyprj plugin. Maybe having a look at its sources gives some insight.
Regards, Enrico
Hi.
On Sun, 28 Jun 2009 11:40:35 +1000 Lex Trotman elextr@gmail.com wrote:
The build-system upgrade is making the build menu fully configurable from projects and/or preferences overriding the defaults, allowing both menu item labels and commands to be configured. I'm not sure if this will help you, although extra filetype configurable commands may be helpfull.
This should really help a lot already.
Currently the structures and functions relating to this are not part of the plugin api, more discussion would be needed about extending the api (pro more capability for plugins, con more to maintain and limits on changing Geany internals, potential unexpected interactions between plugins and configuration).
I see. As of now for my haxe-projects it would be nice to have a gui-dialog for defining (several) .hxml-files (config-files for the compiler) and maybe be able to choose amongst them when compiling. I'll see how the new system turns out and think about useful additions.
It is progressing, although it is taking longer than expected to untangle interactions with other parts of Geany. A prototype should be available on the build-system branch late next week, watch this ML. With such a big change I guess a bit ;-) of testing will be needed prior to merge to trunk.
Sure. I'll be happy to help testing the branch.
-- Mockey
Hi.
On Sun, 28 Jun 2009 11:07:49 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
And still you can choose whether you want to have it as part of the geany-plugins project with its advantages like no need to maintain an own build system and getting translations and releases for free (i.e. you don't need to manage it yourself)
As I really don't know yet how to set up a proper build system, I'd say this is good idea. Just what I needed actually :-) So I'd have to add a Makefile.am in my plugin-dir like the other plugins do now?
Waf is by no means deprecated, on the contrary, now we can very easily build the plugins even on Windows, thanks to the Waf build system we are using.
I remember I compiled some plugins some time ago on Windows, but haven't tried waf yet. Will try it for my plugin.
So, neither Waf nor autotools are deprecated at all, we just moved some plugins and changed their organisation a bit.
I saw the reordering and I also saw that the waf-script had changed a bit (and that adding my plugin still worked flawlessly). Using autotools would mean run ./autogen.sh, right? Are there any options for it as well for compiling just one plugin?
Just add it globally, this is how it is intended to be used. In the handler simply add a prominent check like this: if (editor->document->file_type != GEANY_FILETYPES_HAXE) return FALSE;
You mean editor->document->file_type->id, right? I have: if (nt->nmhdr.code == SCN_CHARADDED && editor->document->file_type->id == GEANY_FILETYPES_HAXE && (nt->ch == '.' || nt->ch == '(')) haxe_completion(...); return FALSE; So I always return false, because in the docs it says: Your callback function should return FALSE to allow Geany processing the event as well. Should be OK? BTW: Is it OK to put all conditions in that one if-clause?
No, not really. AFAIK the only plugin which makes use of this is the geanyprj plugin. Maybe having a look at its sources gives some insight.
I think some project-modifying code in geanyprj was removed recently. It used to hide the standard projects menu, but doesn't do this anymore. Also it uses its own config files and all. Anyway, will have a look ...
-- Mockey
On Sun, 28 Jun 2009 19:17:08 +0200, Andreas wrote:
Hi.
On Sun, 28 Jun 2009 11:07:49 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
And still you can choose whether you want to have it as part of the geany-plugins project with its advantages like no need to maintain an own build system and getting translations and releases for free (i.e. you don't need to manage it yourself)
As I really don't know yet how to set up a proper build system, I'd say this is good idea. Just what I needed actually :-) So I'd have to add a Makefile.am in my plugin-dir like the other plugins do now?
Either you or (I guess) Chow will do it otherwise. Just talk to him, he is the release manager for geany-plugins and also maintains the autotools based build system.
For general SVN write access, just tell me your Sourceforge username, then I add you to project.
Waf is by no means deprecated, on the contrary, now we can very easily build the plugins even on Windows, thanks to the Waf build system we are using.
I remember I compiled some plugins some time ago on Windows, but haven't tried waf yet. Will try it for my plugin.
Well, the initial setup might be a bit tricky: - first of all you need Python, install it somewhere and add the path to the global PATH environment variable so that running 'python' from the command line interpreter will work - then you need pkg-config working and it needs to find the installed headers and libs of the GTK stack - you need a geany.pc and copy it to your pkg-config installation directory as well as the necessary header files for Geany, the easiest way may be to simply copy these from your Linux installation
But then, 'python waf configure' in the geany-plugins directory should work, at least it does on my system :).
So, neither Waf nor autotools are deprecated at all, we just moved some plugins and changed their organisation a bit.
I saw the reordering and I also saw that the waf-script had changed a bit (and that adding my plugin still worked flawlessly). Using autotools would mean run ./autogen.sh, right? Are there any options for it as well for compiling just one plugin?
Don't know, ask Chow as said above. But you don't need to use it if you don't want to. As said earlier, the autotools based and the Waf build systems can be used alternatively, that is they work in parallel. Just decide for one and use it (or even use both if you are too bored, lol).
Just add it globally, this is how it is intended to be used. In the handler simply add a prominent check like this: if (editor->document->file_type != GEANY_FILETYPES_HAXE) return FALSE;
You mean editor->document->file_type->id, right?
Yes, sorry. I should have checked it before sending :).
I have: if (nt->nmhdr.code == SCN_CHARADDED && editor->document->file_type->id == GEANY_FILETYPES_HAXE && (nt->ch == '.' || nt->ch == '(')) haxe_completion(...); return FALSE; So I always return false, because in the docs it says: Your callback function should return FALSE to allow Geany processing the event as well. Should be OK?
It depends what haxe_completion() actually will do. But for now, it should be ok.
BTW: Is it OK to put all conditions in that one if-clause?
It's up to you, whatever you like.
Regards, Enrico
Hi.
On Mon, 29 Jun 2009 23:53:26 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
For general SVN write access, just tell me your Sourceforge username, then I add you to project.
Username is: mockey. But no need to hurry. I want to do some more testing (especially on Windows) before I commit something.
It depends what haxe_completion() actually will do. But for now, it should be ok.
haxe_completion runs the haxe compiler with some special parameters and then spits out some XML which I show as an autocomplete list (or a calltip). Works pretty good and proves to be really useful :-)
One thing which is a bit disturbing though is that when I have automatic symbol completion turned on, after the set number of chars the symbol list sometimes appears and my list disappears. I think automatic symbol completion is pretty useful otherwise, so I don't want to switch it off completely. Would it be possible to disable it temporarily (for as long as my list is shown)? Another question: It seems that you use "\n" as a separator in the completion lists (" " seems to be the default). Will I stay like this or should I better check with SCI_AUTOCGETSEPARATOR?
-- Mockey
On Sat, 4 Jul 2009 13:38:58 +0200, Andreas wrote:
Hi.
On Mon, 29 Jun 2009 23:53:26 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
For general SVN write access, just tell me your Sourceforge username, then I add you to project.
Username is: mockey. But no need to hurry. I want to do some more testing (especially on Windows) before I commit something.
Ok, I will add you soon.
It depends what haxe_completion() actually will do. But for now, it should be ok.
haxe_completion runs the haxe compiler with some special parameters and then spits out some XML which I show as an autocomplete list (or a calltip). Works pretty good and proves to be really useful :-)
One thing which is a bit disturbing though is that when I have automatic symbol completion turned on, after the set number of chars the symbol list sometimes appears and my list disappears. I think
This is why the editor-notify handler can stop the default handler from being invoked. You want to return TRUE if your haxe_completion() code does display your userlist and return FALSE if not. This should do the trick. Maybe I'm wrong, hard to say without seeing any code.
Another question: It seems that you use "\n" as a separator in the completion lists (" " seems to be the default). Will I stay like this or should I better check with SCI_AUTOCGETSEPARATOR?
Er, this is completely up to you which character you use assuming you are using your own userlist (index > 1).
Regards, Enrico
On Sat, 4 Jul 2009 15:32:20 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
This is why the editor-notify handler can stop the default handler from being invoked. You want to return TRUE if your haxe_completion() code does display your userlist and return FALSE if not. This should do the trick.
Ah, yes. I will try this. Will have to set a flag somewhere I think.
Another question: It seems that you use "\n" as a separator
Er, this is completely up to you which character you use assuming you are using your own userlist (index > 1).
Hmm, I don't know what you mean by "userlist (index > 1)" actually. I'm using:
scintilla_send_message(sci, SCI_AUTOCSHOW, 0, (sptr_t)compl_text);
to show the autocompletion list. And compl_text is a gchar that has to be separated with "\n".
-- Mockey
On Sat, 4 Jul 2009 15:32:20 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
You want to return TRUE if your haxe_completion() code does display your userlist and return FALSE if not. This should do the trick.
Thanks for the hint. This is working great now.
On Sat, 4 Jul 2009 18:19:35 +0200 Andreas Mokros am@medienpensionat.com wrote:
Another question: It seems that you use "\n" as a separator
Er, this is completely up to you which character you use assuming you are using your own userlist (index > 1).
Hmm, I don't know what you mean by "userlist (index > 1)" actually.
Ah, I just saw that user lists are another Scintilla feature. Sorry, I just started with all this GTK and Scintilla stuff. Is it better to use user lists? And does index > 1 mean that you use index = 1 in Geany and anything above is free to use? The separator for user lists is also set with SCI_AUTOCSETSEPARATOR, though, right? So if I'd set my own separator it would influence other lists as well, wouldn't it? I have no problem with "\n". I just wanted to know if it's the general separator to use for lists in Geany ...
-- Mockey
On Sun, 5 Jul 2009 00:04:15 +0200, Andreas wrote:
Hey,
Another question: It seems that you use "\n" as a separator
Er, this is completely up to you which character you use assuming you are using your own userlist (index > 1).
Hmm, I don't know what you mean by "userlist (index > 1)" actually.
Ah, I just saw that user lists are another Scintilla feature. Sorry, I just started with all this GTK and Scintilla stuff. Is it better to use user lists? And does index > 1 mean that you use index = 1 in Geany and anything above is free to use?
I just had a look at the code and we are currently using only index 0 in Geany, so you could use index 1. The problem is there is currently no way to find out what indixes are already in use. That is, if there is another plugin which uses userlists, they could interfere eachother by using the same index, We probably need to some API and a bit code behind to maintain used indexes. But for now, if you want to use the userlist feature, use index 1. Index 0 is in use by Geany.
The separator for user lists is also set with SCI_AUTOCSETSEPARATOR, though, right? So if I'd set my own separator it would influence other lists as well, wouldn't it? I have no problem with "\n". I just wanted to know if it's the general separator to use for lists in
Well, if you use your own userlist (index > 0 as mentioned above) you can use whatever separator you want and set it SCI_AUTOCSETSEPARATOR for the used userlist index.
If you use the autocompletion list, you should keep the \n separator to not confuse Geany too much :). But then you must also maintain the SCN_AUTOCSELECTION and SCN_AUTOCCANCELLED notifications to stop Geany handling them if your plugin shows the autocompletion list. Otherwise there could be weird side effects when Geany receives these notifications from Scintilla which are triggered by your plugin.
So, I'd say you better use an userlist even though you need a bit more code handling the event when the user chose an item from the list. For an example how to do that, see the actest plugin I wrote some time ago (http://lists.uvena.de/pipermail/geany/2009-June/004655.html, the code is attached to the mail on the link).
Regards, Enrico
Hi.
On Sat, 4 Jul 2009 15:32:20 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
You want to return TRUE if your haxe_completion() code does display your userlist and return FALSE if not. This should do the trick.
Pretty close, but not quite there yet.
The problem with returning TRUE is that *all* the Geany-handling on editor-notify is disabled, i.e. also updating of the file-saved status, updating of the statusbar, etc. That's not so nice.
Now I set a flag, when I show my completion list and set it back to false when the list disappears. There are apparently two notifications for this: SCN_AUTOCSELECTION (user makes a selection) and SCN_AUTOCCANCELLED (user cancels with mouse or keystroke). *But* the list can apparently also be cancelled by the editor (when typing a wrong key e.g.). And there seems to be no event for this. So in this case flag stays set -> no Geany-handling notify handling anymore. What would be nice is a notification when a user list is shown, but there is only a notification, when something is selected in a user list (SCN_USERLISTSELECTION) ...
-- Mockey
Hi.
On Sun, 5 Jul 2009 16:56:58 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I just had a look at the code and we are currently using only index 0 in Geany, so you could use index 1.
Ah, so these are autocompletion lists? I thought you were using user lists ... Sorry, but this is a bit confusing. In Scintilla docs it says: Index must be greater than 0 as this is how Scintilla tells the difference between an autocompletion list and a user list.
That is, if there is another plugin which uses userlists, they could interfere eachother by using the same index,
That's what I was afraid of, so I'd better ask.
Well, if you use your own userlist (index > 0 as mentioned above) you can use whatever separator you want and set it SCI_AUTOCSETSEPARATOR for the used userlist index.
Uhm, confusing again. There is no index-parameter for SCI_AUTOCSETSEPARATOR and I'd rather thought that this is a setting for all lists (haven't tried, though).
If you use the autocompletion list, you should keep the \n separator to not confuse Geany too much :).
I'll do.
But then you must also maintain the SCN_AUTOCSELECTION and SCN_AUTOCCANCELLED notifications to stop Geany handling them if your plugin shows the autocompletion list. Otherwise there could be weird side effects when Geany receives these notifications from Scintilla which are triggered by your plugin.
I haven't thought about this, but the plugin works pretty good as is. Probably Geany does exactly what I want here :-) The only thing which is not so good is the standard Geany autocompletion appearing while my list is shown, as I said.
So, I'd say you better use an userlist even though you need a bit more code handling the event when the user chose an item from the list. For an example how to do that, see the actest plugin I wrote some time ago (http://lists.uvena.de/pipermail/geany/2009-June/004655.html, the code is attached to the mail on the link).
OK. I'll have a look at it. But not today. Enough Scintilling for now :-)
-- Mockey
On Sun, 5 Jul 2009 18:28:26 +0200, Andreas wrote:
Hi.
On Sun, 5 Jul 2009 16:56:58 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I just had a look at the code and we are currently using only index 0 in Geany, so you could use index 1.
Ah, so these are autocompletion lists? I thought you were using user lists ... Sorry, but this is a bit confusing. In Scintilla docs it says: Index must be greater than 0 as this is how Scintilla tells the difference between an autocompletion list and a user list.
Shame on me! We are using the autocompletion list in Geany *and* we are using a userlist with index 1. So you need to use index 2 or above. Sorry for the confusion, I had a look at the code and still failed. /me hides.
Well, if you use your own userlist (index > 0 as mentioned above) you can use whatever separator you want and set it SCI_AUTOCSETSEPARATOR for the used userlist index.
Uhm, confusing again. There is no index-parameter for SCI_AUTOCSETSEPARATOR and I'd rather thought that this is a setting for all lists (haven't tried, though).
You caught me again. Better don't count much on my words, seems I don't really know what I'm talking about. I was really sure SCI_AUTOCSETSEPARATOR can be set for each list but you are right, it is set for all lists. So, you are stuck to '\n'.
But then you must also maintain the SCN_AUTOCSELECTION and SCN_AUTOCCANCELLED notifications to stop Geany handling them if your plugin shows the autocompletion list. Otherwise there could be weird side effects when Geany receives these notifications from Scintilla which are triggered by your plugin.
I haven't thought about this, but the plugin works pretty good as is. Probably Geany does exactly what I want here :-) The only thing which is not so good is the standard Geany autocompletion appearing while my list is shown, as I said.
I hesitate to comment on this, I will probably fail again :). Maybe SCI_AUTOCCANCEL helps you if called before or after your list is shown but really not sure without knowing your code.
So, I'd say you better use an userlist even though you need a bit more code handling the event when the user chose an item from the list. For an example how to do that, see the actest plugin I wrote some time ago (http://lists.uvena.de/pipermail/geany/2009-June/004655.html, the code is attached to the mail on the link).
OK. I'll have a look at it. But not today. Enough Scintilling for now :-)
Same here, my comments confuse you more than they help, sorry :(.
Regards, Enrico
On Sun, 5 Jul 2009 17:50:31 +0200, Andreas wrote:
Hi.
On Sat, 4 Jul 2009 15:32:20 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
You want to return TRUE if your haxe_completion() code does display your userlist and return FALSE if not. This should do the trick.
Pretty close, but not quite there yet.
The problem with returning TRUE is that *all* the Geany-handling on editor-notify is disabled, i.e. also updating of the file-saved status, updating of the statusbar, etc. That's not so nice.
Indeed.
Now I set a flag, when I show my completion list and set it back to false when the list disappears. There are apparently two notifications for this: SCN_AUTOCSELECTION (user makes a selection) and SCN_AUTOCCANCELLED (user cancels with mouse or keystroke). *But* the list can apparently also be cancelled by the editor (when typing a wrong key e.g.). And there seems to be no event for this. So in this case flag stays set -> no Geany-handling notify handling anymore. What would be nice is a notification when a user list is shown, but there is only a notification, when something is selected in a user list (SCN_USERLISTSELECTION) ...
Such a notification is missing in Scintilla. On the other hand, you maybe can workaround this by checking checking the list display status with SCI_AUTOCACTIVE when receiving the SCN_UPDATEUI. But really, this is just a guess and depends on how your code works.
Regards, Enrico
On Sun, 5 Jul 2009 18:58:22 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
We are using the autocompletion list in Geany *and* we are using a userlist with index 1. So you need to use index 2 or above. Sorry for the confusion, I had a look at the code and still failed. /me hides. I was really sure SCI_AUTOCSETSEPARATOR can be set for each list but you are right, it is set for all lists. So, you are stuck to '\n'.
OK. No problem.
Maybe SCI_AUTOCCANCEL helps you if called before or after your list is shown but really not sure without knowing your code.
I had a brief look at your actest-code and it seems I have to change my notify-function (returning TRUE only when needed). And probably using a user list is better ...
-- Mockey
On Sun, 5 Jul 2009 19:11:30 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On the other hand, you maybe can workaround this by checking checking the list display status with SCI_AUTOCACTIVE when receiving the SCN_UPDATEUI.
Yep. I think about something like this. Thanks for now.
-- Mockey