Hi all,
I try to add Vala support in Geany in a better way than just use C# filetype & co. For now, I got a usable filetype, with: * filetype * keywords * syntax highlighting (based on C# one, itself based on C++ one) * usable tag manager (well, most of the work)
For now, the tag manager seems to work correctly. It is small add-ons over C one, as C# one does. The main leak is I've not written a custom tag list. What is not perfect: * Interfaces are shown as "Structs/Typedefs"; * Properties are shown as Members (hack in code because properties are not shown at all); * Signals are handled as simple functions. This is not really annoying, but it may be better to have separate tag list. And Exception types are shown as named enums, but this don't hurt me; should it?
The main goal of this email is to solicit your opinion about what is good, what is not, and perhaps help to improve tags manager (since I mostly do tries to see how it works ^^). Generally, any comment and help is welcome :)
Note that I am not a Vala power-user or a filetype-writing God, and the main reason I would to write a Vala mode for Geany is to learn Vala, then perhaps I made mistakes. If you see so, tell it to me, I'll learn :)
helpful links: http://live.gnome.org/Vala http://www.vala-project.org/doc/vala/
Regards, Colomban.
On Sun, 02 Nov 2008 00:55:05 +0100 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hi all,
I try to add Vala support in Geany in a better way than just use C# filetype & co.
Thanks, we'll likely commit it soon.
- usable tag manager (well, most of the work)
For now, the tag manager seems to work correctly. It is small add-ons over C one, as C# one does.
Cool. (It reminds me that we should add the D keywords also instead of sharing C++).
The main leak is I've not written a custom tag list. What is not perfect:
- Interfaces are shown as "Structs/Typedefs";
- Properties are shown as Members (hack in code because properties
are not shown at all);
- Signals are handled as simple functions. This is not really
annoying, but it may be better to have separate tag list. And Exception types are shown as named enums, but this don't hurt me; should it?
It should be quite easy for us to make these changes for the symbol list.
...
Note that I am not a Vala power-user or a filetype-writing God, and the main reason I would to write a Vala mode for Geany is to learn Vala, then perhaps I made mistakes. If you see so, tell it to me, I'll learn :)
We sometimes make mistakes, and some bugs can only be found after much testing. No one's perfect ;-) Probably it's less buggy than using the C# filetype for vala files (this was just a workaround).
Regards, Nick
Nick Treleaven a écrit :
The main leak is I've not written a custom tag list. What is not perfect:
- Interfaces are shown as "Structs/Typedefs";
- Properties are shown as Members (hack in code because properties
are not shown at all);
- Signals are handled as simple functions. This is not really
annoying, but it may be better to have separate tag list. And Exception types are shown as named enums, but this don't hurt me; should it?
It should be quite easy for us to make these changes for the symbol list.
Cool :) But signals needs hacking in the tagmanager I've not done for now. They are handled as functions because their syntax is close to function declarations. For the properties, just uncomment line 2699 in c.c (of the updated patch joined) and remove the next two.
We sometimes make mistakes, and some bugs can only be found after much testing. No one's perfect ;-) Probably it's less buggy than using the C# filetype for vala files (this was just a workaround).
True for both… but reach perfection is the goal, no? :-P
I join a small update of the patch: * removed commented code used for my tests * added *.vapi to the supported extensions
Regards, Colomban
PS: I see the last commit message and it remember me to ask: what is the indentation in c.c? 'Seems to be an heterogeneous mixing of Tabs&Spaces of 4&8 and tabs of 4… Needs review?
On Wed, 05 Nov 2008 22:44:33 +0100 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Nick Treleaven a écrit :
The main leak is I've not written a custom tag list. What is not perfect:
- Interfaces are shown as "Structs/Typedefs";
- Properties are shown as Members (hack in code because properties
are not shown at all);
- Signals are handled as simple functions. This is not really
annoying, but it may be better to have separate tag list. And Exception types are shown as named enums, but this don't hurt me; should it?
It should be quite easy for us to make these changes for the symbol list.
Cool :)
BTW I should have said updating the symbol list labels is easy, I'm not planning on working on c.c for those things.
But signals needs hacking in the tagmanager I've not done for now. They are handled as functions because their syntax is close to function declarations. For the properties, just uncomment line 2699 in c.c (of the updated patch joined) and remove the next two.
We sometimes make mistakes, and some bugs can only be found after much testing. No one's perfect ;-) Probably it's less buggy than using the C# filetype for vala files (this was just a workaround).
True for both… but reach perfection is the goal, no? :-P
Yes, but I meant that testing is part of the development process for non-trivial software.
I join a small update of the patch:
- removed commented code used for my tests
- added *.vapi to the supported extensions
Thanks.
PS: I see the last commit message and it remember me to ask: what is the indentation in c.c? 'Seems to be an heterogeneous mixing of Tabs&Spaces of 4&8 and tabs of 4… Needs review?
Well, all newly written code should be tabs only, but because this code comes from CTags I think we allow spaces as well. Tabs should always be equivalent to 4 spaces though.
Regards, Nick
Nick Treleaven a écrit :
On Wed, 05 Nov 2008 22:44:33 +0100 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Nick Treleaven a écrit :
The main leak is I've not written a custom tag list. What is not perfect:
- Interfaces are shown as "Structs/Typedefs";
- Properties are shown as Members (hack in code because properties
are not shown at all);
- Signals are handled as simple functions. This is not really
annoying, but it may be better to have separate tag list. And Exception types are shown as named enums, but this don't hurt me; should it?
It should be quite easy for us to make these changes for the symbol list.
Cool :)
BTW I should have said updating the symbol list labels is easy, I'm not planning on working on c.c for those things.
I wasn't thinking you wanted to do that ;) I would just say that the signals are not yet ready to be handled as they are; and that for now properties tags are fields ones. But for this last, the only thing to do is uncomment a line in c.c and remove the current hack (there is a comment). But perhaps having the right items in the right sections in the tag list need more work?
Yes, but I meant that testing is part of the development process for non-trivial software.
Sure, of course you're right. This is even the main reason why I posted my WIP here in hope someone else found bugs ;)
PS: I see the last commit message and it remember me to ask: what is the indentation in c.c? 'Seems to be an heterogeneous mixing of Tabs&Spaces of 4&8 and tabs of 4… Needs review?
Well, all newly written code should be tabs only, but because this code comes from CTags I think we allow spaces as well. Tabs should always be equivalent to 4 spaces though.
OK. I'll perhaps take a look at the indentation if I fond some time.
Regards, Colomban
On Thu, 6 Nov 2008 13:48:15 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
PS: I see the last commit message and it remember me to ask: what is the indentation in c.c? 'Seems to be an heterogeneous mixing of Tabs&Spaces of 4&8 and tabs of 4… Needs review?
Well, all newly written code should be tabs only, but because this code comes from CTags I think we allow spaces as well. Tabs should always
The indentation in c.c and some other files in the tagmanager/ directory are really messed up. But it's easy to fix with Ctrl-U/I :) though not really necessary if not currently working with such a file, IMO.
Regards, Enrico
Hi,
Just an updated version for apply with latest changes from SVN (Matlab filetype broke old patch because of the new parser's number).
Regards, Colomban
On Sat, 08 Nov 2008 19:09:34 +0100 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hi,
Just an updated version for apply with latest changes from SVN (Matlab filetype broke old patch because of the new parser's number).
Thanks, applied. I added a comment for "errordomain" using KEYWORD_ENUM. I'm not sure why "signal" was using KEYWORD_EVENT, I changed it to KEYWORD_SIGNAL, seems to work OK.
I haven't done anything for the symbol list titles after all. The symbol list is now grouped by parent tags.
Regards, Nick
Nick Treleaven a écrit :
Thanks, applied. I added a comment for "errordomain" using KEYWORD_ENUM. I'm not sure why "signal" was using KEYWORD_EVENT, I changed it to KEYWORD_SIGNAL, seems to work OK.
Thanks. I think I used KEYWORD_EVENT when starting to implement Vala filetype and missed to change it later. No reason to keep it ;)
I haven't done anything for the symbol list titles after all. The symbol list is now grouped by parent tags.
Great. (new tag tree is disconcerting at start, but seems cool)
Regards, Colomban
Hi,
I join a patch to improve Vala tagmanager. What's new: * Fixed handling of function attributes (was handled as something like arrays); * Fixed nested types handling (such as 'Gtk.TreeModel' as a function's return type); * Add some missing keywords ('weak', 'ref' and 'out'); * Fixed functions with nullable arguments types, and generally nullable types; * Fixed support of '@' prefix to escape a keyword (for using it as a function name, property or so).
I've not found any problems for now with my patch, but I think it is possible that there's some ones: * Fixing function attributes perhaps have an impact on array support, but seems not. (note that side effects are only possible with Vala itself, not with other c.c's filetypes); * Support of '@' at start of a name is done in isident1() from tagmanager/get.h. I think it have a possible impact to other filetypes, even if I don't know anyone, and haven't see anyone. For example, C# seems to have a syntax like @"a string" and I dunno if my changes have any impact to it since I don't know C# and I haven't found any relevant example.
Comments & feedback are welcome as usual :)
Regards, Colomban
On Sat, 06 Dec 2008 18:23:54 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hey,
thanks a lot for patch, committed.
- Support of '@' at start of a name is done in isident1() from
tagmanager/get.h. I think it have a possible impact to other filetypes, even if I don't know anyone, and haven't see anyone. For example, C# seems to have a syntax like @"a string" and I dunno if my changes have any impact to it since I don't know C# and I haven't found any relevant example.
Well, let's see whether anything gets broken. I don't think so but using the code is the best testing :).
Regards, Enrico