Hi.
While setting up Geany as my haxe-IDE I saw that I can now add custom templates (for haxe e.g.). This is quite new, isn't it? Thanks for that :-) But templates in haxe are always commented like this: // // name: unknown // @param // @return while C-templates are commented like this: /* * * name: unknown * @param * @return */ Is there a switch somewhere to change this, i.e. make haxe use /**/-style comments?
Also the keywords in the haxe-filedef are not quite right. Shall I send you a corrected version?
-- Mockey
On Sat, 4 Jul 2009 13:46:53 +0200, Andreas wrote:
But templates in haxe are always commented like this: // // name: unknown // @param // @return while C-templates are commented like this: /*
- name: unknown
- @param
- @return
*/ Is there a switch somewhere to change this, i.e. make haxe use /**/-style comments?
Changing comment_open and comment_close in filetypes.haxe should help.
Also the keywords in the haxe-filedef are not quite right. Shall I send you a corrected version?
Sure. Maybe also contact blackdog who contributed this list IIRC.
Regards, Enrico
On Sat, 4 Jul 2009 15:34:57 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Changing comment_open and comment_close in filetypes.haxe should help.
No, that was my first thought also. But that doesn't change anything about the comment-style for header and function description. Also the c-filedef has comment_open=// set by default and it still uses /**/ for header and function description (// for multiline comments, though).
Sure. Maybe also contact blackdog who contributed this list IIRC.
I'll ask in the haxe mailing-list, if there is an official keyword-list. In the current list, there are definitely some keywords missing and some keywords that just don't exist (e.g. "protected").
-- Mockey
On Sat, 4 Jul 2009 18:54:56 +0200, Andreas wrote:
On Sat, 4 Jul 2009 15:34:57 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Changing comment_open and comment_close in filetypes.haxe should help.
No, that was my first thought also. But that doesn't change anything about the comment-style for header and function description.
Yeah, sorry again. It *should* that but it doesn't do yet :(. Have a look at src/templates.c make_comment_block() and remove the case for Haxe. I guess blackdog preferred the // style when we added the filetype. Not sure what's best as the default. We should rewrite this function so that it uses the comment_open/comment_close settings but there is still the lack for the line_prefix information. We could either add line_prefix to the filetype definition files or magically guess it. But I don't like both ways that much. Not sure what to do best.
Sure. Maybe also contact blackdog who contributed this list IIRC.
I'll ask in the haxe mailing-list, if there is an official keyword-list. In the current list, there are definitely some keywords
Ok, keep us up2date.
Regards, Enrico
On Sun, 5 Jul 2009 16:47:23 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
It *should* that but it doesn't do yet :(. Have a look at src/templates.c make_comment_block() and remove the case for Haxe.
OK, I see.
I guess blackdog preferred the // style when we added the filetype. Not sure what's best as the default.
Not sure either. I thought multiline comments with /**/ were more common ...
We should rewrite this function so that it uses the comment_open/comment_close settings
Definitely. Then you can choose yourself.
but there is still the lack for the line_prefix information.
You mean tabs or spaces at the beginning of the lines? That would have been my next request :-)
We could either add line_prefix to the filetype definition files or magically guess it. But I don't like both ways that much. Not sure what to do best.
I'd prefer magically. There might be different line_prefixes depending on the place of the comment. Another thing that would be nice to have is filling function name and params automagically function declarations :-) I think I saw that once in Eclipse ...
-- Mockey
On Sun, 5 Jul 2009 17:52:14 +0200, Andreas wrote:
We should rewrite this function so that it uses the comment_open/comment_close settings
Definitely. Then you can choose yourself.
but there is still the lack for the line_prefix information.
You mean tabs or spaces at the beginning of the lines?
No, the line_prefix means to insert an asterisk at the beginning of lines inside the multi line comment, e.g. /* * blah * blah */
line_prefix would be " *" in this case.
We could either add line_prefix to the filetype definition files or magically guess it. But I don't like both ways that much. Not sure what to do best.
I'd prefer magically. There might be different line_prefixes depending on the place of the comment.
Well, I thought of something like: if comment_close is set, then check the second char of comment_open and use it as line_prefix. E.g. comment_open=/* comment_close=*/
second char of comment_open == * so we have a line_prefix = * and this we prefix with some whitespace and we get what we have currently hardcoded. But this might fail for other comment types which are not so C-like.
Another thing that would be nice to have is filling function name and params automagically function declarations :-)
Function name should be inserted into the template if it is known. I just tested it with C and it works provided that the cursor is inside the function definition so that Geany knows on what function it should operate. This can be improved but doesn't necessarily need to. About params: bah. Implement it if you need it, I don't think it's necessary.
Regards, Enrico
On Sun, 5 Jul 2009 18:47:09 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
No, the line_prefix means to insert an asterisk at the beginning of lines inside the multi line comment, e.g. /*
- blah
- blah
*/ line_prefix would be " *" in this case.
I see.
Function name should be inserted into the template if it is known. I just tested it with C and it works provided that the cursor is inside the function definition so that Geany knows on what function it should operate.
Wow, really. Didn't know this.
This can be improved but doesn't necessarily need to.
I'll have a look at the code. Maybe I can make it work for haxe, too ...
-- Mockey
On Sun, 5 Jul 2009 19:11:50 +0200, Andreas wrote:
This can be improved but doesn't necessarily need to.
I'll have a look at the code. Maybe I can make it work for haxe, too ...
The problem is that Geany doesn't really know about the current scope. Check the 'scope' field in the statusbar, for the few Haxe examples files I have here it says most often 'unknown' or it finds a scope which is just wrong. And that is why the function template doesn't subsitute the function name because the subsitution is based on the scope information.
So, fixing this means to fix the code which determines the current scope which is not completely trivial but surely possible. Have a look at symbols_get_current_function(), the code uses information from Scintilla and from tagmanager to determine the scope.
Regards, Enrico
On Sun, 5 Jul 2009 19:17:10 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
So, fixing this means to fix the code which determines the current scope which is not completely trivial but surely possible. Have a look at symbols_get_current_function(), the code uses information from Scintilla and from tagmanager to determine the scope.
I see. Functions in haxe always start with:
function name_of_function(function_params) {
So it shouldn't be too difficult to track them.
I think the parse_cpp_function_at_line-function which is probably used for haxe doesn't work because the styles in haxe appear a bit strange. "function" is listed in keywords under primary and I'd expect SCE_C_IDENTIFIER for it (which should make the parse_cpp-function work) but its style is SCE_C_WORD. Any normal text is styled as SCE_C_IDENTIFIER on the other hand. The keywords in secondary are styled as SCE_C_WORD2. Is this intentional? And where is this set? I had a look at highlighting.c but I don't understand where you set which keywords get which style ...
Symbols for haxe are recognized pretty well BTW.
-- Mockey
On Sun, 5 Jul 2009 21:00:57 +0200, Andreas wrote:
On Sun, 5 Jul 2009 19:17:10 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
So, fixing this means to fix the code which determines the current scope which is not completely trivial but surely possible. Have a look at symbols_get_current_function(), the code uses information from Scintilla and from tagmanager to determine the scope.
I see. Functions in haxe always start with:
function name_of_function(function_params) {
So it shouldn't be too difficult to track them.
I think the parse_cpp_function_at_line-function which is probably used for haxe doesn't work because the styles in haxe appear a bit strange. "function" is listed in keywords under primary and I'd expect SCE_C_IDENTIFIER for it (which should make the parse_cpp-function work)
Nah, "function" is a keyword, not an identifier. The function name instead is indeed an identifier (and without having checked it, I guess the lexer defines the function name also as identifier).
but its style is SCE_C_WORD. Any normal text is styled as SCE_C_IDENTIFIER on the other hand. The keywords in secondary are styled as SCE_C_WORD2.
"secondary keywords" (=2) is styled with the keyword style 2 (SCE_C_WORD2), so yes, this is intentional even though defined by Scintlla, see below.
Is this intentional? And where is this set? I had a look at highlighting.c but I don't understand where you set which keywords get which style ...
This is all done and defined by the Scintilla lexer in use, in this case LexCPP.cxx.
That all being said, it might still be that the code in parse_cpp_function_at_line() might need some tweaking for Haxe or maybe other places in Geany. I didn't really have a look yet.
Regards, Enrico
Hi.
On Thu, 9 Jul 2009 00:45:46 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Nah, "function" is a keyword, not an identifier. The function name instead is indeed an identifier "secondary keywords" (=2) is styled with the keyword style 2 (SCE_C_WORD2), so yes, this is intentional even though defined by Scintlla, see below.
Ah, OK. Then we have: [keywords] -> primary: get styled as SCE_C_WORD ([styling] -> word) [keywords] -> secondary: get styled as SCE_C_WORD2 ([styling] -> word2) Right?
In filetypes.haxe there are also "classes" defined under [keywords]. But they show no styling. If I understand the code in highlighting.c, styleset_haxe() correctly, it should be: SSM(sci, SCI_SETKEYWORDS, 3, (sptr_t) style_sets[GEANY_FILETYPES_HAXE].keywords[2]); instead of: SSM(sci, SCI_SETKEYWORDS, 2, (sptr_t) style_sets[GEANY_FILETYPES_HAXE].keywords[2]); for it to work, because LexCPP takes &keywords4 = *keywordlists[3] and styles it with SCE_C_GLOBALCLASS. Seems logical to me, will try that out ... Having separately colored classes would be nice.
Another question: I saw that adding some tags-files like gtk216.c.tags or standard.css.tags changed the highlighting, e.g. things like "gchar" get highlighted in C then. How does that work?
That all being said, it might still be that the code in parse_cpp_function_at_line() might need some tweaking for Haxe or maybe other places in Geany. I didn't really have a look yet.
Well, parse_cpp_function_at_line() *should* actually work with haxe then at first glance. Maybe symbols_get_current_function does something wrong? I'll try to debug it ...
-- Mockey
On Thu, 9 Jul 2009 13:50:10 +0200, Andreas wrote:
Hi.
On Thu, 9 Jul 2009 00:45:46 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Nah, "function" is a keyword, not an identifier. The function name instead is indeed an identifier "secondary keywords" (=2) is styled with the keyword style 2 (SCE_C_WORD2), so yes, this is intentional even though defined by Scintlla, see below.
Ah, OK. Then we have: [keywords] -> primary: get styled as SCE_C_WORD ([styling] -> word) [keywords] -> secondary: get styled as SCE_C_WORD2 ([styling] -> word2) Right?
In filetypes.haxe there are also "classes" defined under [keywords]. But they show no styling. If I understand the code in highlighting.c, styleset_haxe() correctly, it should be: SSM(sci, SCI_SETKEYWORDS, 3, (sptr_t) style_sets[GEANY_FILETYPES_HAXE].keywords[2]);
Yes, good catch. Amazing that nobody noticed that earlier. It might indicate how many users do use Haxe with Geany...:( I will fix this unless you want to provide a patch?
Another question: I saw that adding some tags-files like gtk216.c.tags or standard.css.tags changed the highlighting, e.g. things like "gchar" get highlighted in C then. How does that work?
Well, the manual describes it basically: http://geany.org/manual/#generating-a-global-tags-file
In theory, it should work for Haxe files as well. The generation is based on the symbol parser, so it will be as good as the files you pass in when generating the tags file and as good as the Haxe symbol parser works :). Give it a try and ask if anything is not clear.
That all being said, it might still be that the code in parse_cpp_function_at_line() might need some tweaking for Haxe or maybe other places in Geany. I didn't really have a look yet.
Well, parse_cpp_function_at_line() *should* actually work with haxe then at first glance. Maybe symbols_get_current_function does something wrong? I'll try to debug it ...
Cool, much appreciated.
Regards, Enrico
On Thu, 9 Jul 2009 16:25:09 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, good catch. Amazing that nobody noticed that earlier. It might indicate how many users do use Haxe with Geany...:(
From what I've seen, blackdog did quite a lot of haxe stuff for Geany, like his hxDev-plugin, but at some point didn't update it anymore.
I will fix this unless you want to provide a patch?
Well, a patch for changing a "2" into a "3" is not really necessary.
Well, the manual describes it basically: http://geany.org/manual/#generating-a-global-tags-file In theory, it should work for Haxe files as well. The generation is based on the symbol parser, so it will be as good as the files you pass in when generating the tags file and as good as the Haxe symbol parser works :). Give it a try and ask if anything is not clear.
OK. I'll try it on some haxe files. The symbol parser works generally pretty good. I understand that you get autocompletion lists from these tag files. But I don't understand how you get the different highlighting, like for gint, gchar and so on.
-- Mockey
On Thu, 9 Jul 2009 17:19:05 +0200, Andreas wrote:
I will fix this unless you want to provide a patch?
Well, a patch for changing a "2" into a "3" is not really necessary.
Ok, committed.
Well, the manual describes it basically: http://geany.org/manual/#generating-a-global-tags-file In theory, it should work for Haxe files as well. The generation is based on the symbol parser, so it will be as good as the files you pass in when generating the tags file and as good as the Haxe symbol parser works :). Give it a try and ask if anything is not clear.
OK. I'll try it on some haxe files. The symbol parser works generally pretty good. I understand that you get autocompletion lists from these tag files. But I don't understand how you get the different highlighting, like for gint, gchar and so on.
Well, gint, gchar and such are C typedefs, defined in the GLib header files. These are parsed by Geany when generating the tags file and then written into the tags file with the appropriate tag type. Geany then reads these tags (symbols_load_global_tags() in symbols.c) and notice that 'gint' is a type and adds it to the keyword list 1 of the Scintilla lexer (update_type_keywords in document.c). I hope this makes it a bit clearer. It's not completely trivial how this is handled but I guess after reading a bit of the code you should get a rough picture of how it is done. If not, just ask.
Regards, Enrico
On Thu, 9 Jul 2009 17:32:12 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, a patch for changing a "2" into a "3" is not really necessary.
Ok, committed.
Thanks. Works nicely :-)
Well, gint, gchar and such are C typedefs, defined in the GLib header files. These are parsed by Geany when generating the tags file and then written into the tags file with the appropriate tag type.
By tags file you mean gtk216.c.tags?
Geany then reads these tags (symbols_load_global_tags() in symbols.c) and notice that 'gint' is a type and adds it to the keyword list 1 of the Scintilla lexer (update_type_keywords in document.c).
OK. Found the declaration of gchar, gint, etc. now in the tags file. Missed it somehow...
I hope this makes it a bit clearer. It's not completely trivial how this is handled but I guess after reading a bit of the code you should get a rough picture of how it is done.
Yes. Thanks.
-- Mockey
On Sun, 12 Jul 2009 19:12:15 +0200, Andreas wrote:
On Thu, 9 Jul 2009 17:32:12 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, a patch for changing a "2" into a "3" is not really necessary.
Ok, committed.
Thanks. Works nicely :-)
Well, gint, gchar and such are C typedefs, defined in the GLib header files. These are parsed by Geany when generating the tags file and then written into the tags file with the appropriate tag type.
By tags file you mean gtk216.c.tags?
Yes.
Geany then reads these tags (symbols_load_global_tags() in symbols.c) and notice that 'gint' is a type and adds it to the keyword list 1 of the Scintilla lexer (update_type_keywords in document.c).
OK. Found the declaration of gchar, gint, etc. now in the tags file. Missed it somehow...
Oh sorry, I should have been clearer on this. Yes, the type declarations of gint, gchar and such are in the tags file, the gtk26.c.tags.
Regards, Enrico
On Thu, 9 Jul 2009 16:25:09 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, parse_cpp_function_at_line() *should* actually work with haxe then at first glance. Maybe symbols_get_current_function does something wrong? I'll try to debug it ...
Cool, much appreciated.
Seems like the symbol parser for haxe is the cause. There are many different parsers in the /tagmanager directory. Where do they come from? The ActionScript parser e.g. uses some regex and recognizes function scopes quite good at least. The haxe parser does without regex and misses all private functions e.g. Is there some documentation for writing a tagmanager parser somewhere?
-- Mockey
On Mon, 13 Jul 2009 02:52:54 +0200, Andreas wrote:
On Thu, 9 Jul 2009 16:25:09 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, parse_cpp_function_at_line() *should* actually work with haxe then at first glance. Maybe symbols_get_current_function does something wrong? I'll try to debug it ...
Cool, much appreciated.
Seems like the symbol parser for haxe is the cause. There are many different parsers in the /tagmanager directory. Where do they come from?
Almost all are identical (minus a few different header includes and other very minor changes) with the parsers from the Ctags project (http://ctags.sourceforge.net).
The ActionScript parser e.g. uses some regex and recognizes function scopes quite good at least. The haxe parser does without regex and misses all private functions e.g.
There are two types of parsers: regex based parsers which parse each line of the file on its own and apply regular expressions to find symbols. An example for this is the PHP parser (and the Actionscript parser you mentioned). While this is pretty easy to implement, it is also not completely accurate in some cases but this depends on the language. E.g. for PHP it works pretty fine except when you have multiline comments which contain the keyword 'function', e.g. /* some test * function foo_bar is commented out because it doesn't work */ then the parser will find 'foo_bar' as a PHP function because the regex matches. And there is no easy way to get rid of this mistake because the regex based parsing is done line by line without any state information of previous lines. That is, the parser doesn't know there is an open multi line line comment when it sees the line " * function foo_bar ...".
The other type of parsers are more complex, they parse the file either character by character or also line by line but then keep state information of previous lines to detect and properly handle multi line comments or wrapped lines or whatever.
To summarise it, regex based parsers are probably easier to implement but are also more likely to produce wrong results due to less information they have about the parsed line.
Is there some documentation for writing a tagmanager parser somewhere?
On the Ctags project website I found http://ctags.sourceforge.net/EXTENDING.html.
Regards, Enrico
On Tue, 14 Jul 2009 21:19:34 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On the Ctags project website I found http://ctags.sourceforge.net/EXTENDING.html.
Thanks for the detailed information. Will look into it.
-- Mockey