Hi all,
For my sins, I'm obliged to develop code in R, and a while back I added in a tagmanager parser for R symbols. The parser is not mine, but is GPLed and the copyright message is intact so I don't expect that to pose a problem for the project.
I've attached a patch against geany-svn which appears to build and function. I'd love to see this become part of the official release. It'd help me promote the use of geany within my company and allow me to go back to letting Fedora do all my upgrades! :-)
Jon
Hello
On 2/17/10, Jon Senior jon@restlesslemon.co.uk wrote:
For my sins, I'm obliged to develop code in R, and a while back I added in a tagmanager parser for R symbols.
I am currently using Geany for my R needs, and I was curious whether the patch provides something more than the current syntax highlighting support. If so, wouldn't it be safer to open a patched bug report [1]?
Liviu
[1] http://sourceforge.net/tracker/?func=browse&group_id=153444&atid=787...
The parser is not mine, but is GPLed and the copyright message is intact so I don't expect that to pose a problem for the project.
I've attached a patch against geany-svn which appears to build and function. I'd love to see this become part of the official release. It'd help me promote the use of geany within my company and allow me to go back to letting Fedora do all my upgrades! :-)
Jon
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 19 Feb 2010 08:53:28 +0000 Liviu Andronic landronimirc@gmail.com wrote:
I am currently using Geany for my R needs, and I was curious whether the patch provides something more than the current syntax highlighting support. If so, wouldn't it be safer to open a patched bug report [1]?
I shall do exactly that. I wasn't sure what the protocol here was. As for what it provides, it's full tag parsing, meaning that you get all your functions listed in the left hand pane as per C / Java / etc.
Jon
On 2/19/10, Jon Senior jon@restlesslemon.co.uk wrote:
I shall do exactly that. I wasn't sure what the protocol here was. As for what it provides, it's full tag parsing, meaning that you get all your functions listed in the left hand pane as per C / Java / etc.
Nice. Thanks for bringing up the patch.
I have couple more issues with the current support for R in Geany. It's mostly minor, but it affects readability of the code. The syntax highlighting fails in some cases: - for the line below, "sum" and "length" are both functions but will be highlighted with different colours
sum(mtcars$cyl); length(mtcars$cyl)
- a function similar to the one below will have "trim" and "qt" highlighted differently.
trim.qt <- function(x) sum(x) trim.qt(mtcars$cyl)
- so will an object, say,
get.smth <- iris
- objects don't seem recognised at all.
Are these failures of the current parser implementation, or is this something that one should expect? Thanks Liviu
On Fri, 19 Feb 2010 10:02:22 +0000 Liviu Andronic landronimirc@gmail.com wrote:
Nice. Thanks for bringing up the patch.
No problem... it had been bugging me for a while. It's in the tracker now so hopefully we'll see it in geany-0.19.
I have couple more issues with the current support for R in Geany. It's mostly minor, but it affects readability of the code. The syntax highlighting fails in some cases:
- for the line below, "sum" and "length" are both functions but will
be highlighted with different colours
sum(mtcars$cyl); length(mtcars$cyl)
That's the syntax highlighting. geany is recognising one as a function name and the other as a reserved keyword. Not sure why "sum" is being seen as a keyword though.
- a function similar to the one below will have "trim" and "qt"
highlighted differently.
trim.qt <- function(x) sum(x) trim.qt(mtcars$cyl)
geany doesn't seem to recognise that a . in R can be used as part of a variable / function name.
- so will an object, say,
get.smth <- iris
- objects don't seem recognised at all.
In what sense? I think it doesn't highlight objects that you've created, although I could be wrong. To be honest I only really notice the highlighting for strings and the bracket closing.
Are these failures of the current parser implementation, or is this something that one should expect? Thanks
It's the syntax highlighting, not the tag parser (tags are things like function definitions or global variable definitions). I've not really looked at it enough to see how tuneable it is. It's been a while since I delved into the R template files. Maybe later today.
Jon
On 19 February 2010 21:10, Jon Senior jon@restlesslemon.co.uk wrote:
On Fri, 19 Feb 2010 10:02:22 +0000 Liviu Andronic landronimirc@gmail.com wrote:
Nice. Thanks for bringing up the patch.
No problem... it had been bugging me for a while. It's in the tracker now so hopefully we'll see it in geany-0.19.
I have couple more issues with the current support for R in Geany. It's mostly minor, but it affects readability of the code. The syntax highlighting fails in some cases:
- for the line below, "sum" and "length" are both functions but will
be highlighted with different colours
sum(mtcars$cyl); length(mtcars$cyl)
That's the syntax highlighting. geany is recognising one as a function name and the other as a reserved keyword. Not sure why "sum" is being seen as a keyword though.
Thats because sum is listed as a keyword in Geanys filetypes.r file. Someone who is knowledgeable in R should have a look and check the filetypes.r file and submit a patch.
Theer are also lots of packages listed, probably need checking.
- a function similar to the one below will have "trim" and "qt"
highlighted differently.
trim.qt <- function(x) sum(x) trim.qt(mtcars$cyl)
geany doesn't seem to recognise that a . in R can be used as part of a variable / function name.
A quick look at the lexer in LexR.cxx from the Scintilla project looks like it explicitly excludes '.' from identifiers, maybe the test is backward. Again someone knowledgeable in R (and C++) should check it.
The lexer comes from the Scintilla project and is only used by Geany. Geany usually likes to keep an unmodified Scintilla version, so if you are sure its a bug or if you actually make a patch, please submit it to the Scintilla project www.scintilla.org
- so will an object, say,
get.smth <- iris
- objects don't seem recognised at all.
In what sense? I think it doesn't highlight objects that you've created, although I could be wrong. To be honest I only really notice the highlighting for strings and the bracket closing.
AFAICT identifiers "should" be recognised as such but there is no distinction between uses of the identifiers.
Cheers Lex
Are these failures of the current parser implementation, or is this something that one should expect? Thanks
It's the syntax highlighting, not the tag parser (tags are things like function definitions or global variable definitions). I've not really looked at it enough to see how tuneable it is. It's been a while since I delved into the R template files. Maybe later today.
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 19 Feb 2010 21:25:38 +1100 Lex Trotman elextr@gmail.com wrote:
Thats because sum is listed as a keyword in Geanys filetypes.r file. Someone who is knowledgeable in R should have a look and check the filetypes.r file and submit a patch.
OK. I've got a basic patch for that. I've not gone through the whole packages list, but I've removed everything that's not syntax ("if", "then", "else", etc.) from the primary list. I've had a look at the scintilla code, but I'm not sure about it. It seems to correctly include "." as part of a word, but then later excludes it (If I'm reading the code correctly). I'll try playing with a little later since my efforts thus far haven't changed anything.
I think I need a better understanding of what Scintilla is doing before I can properly debug that one.
Should I send the geany patch to the mailing list or just put it in the tracker? And should I open a new issue in the tracker, or add it to my R-Parser patch that's already there?
Jon
On Fri, 19 Feb 2010 12:14:33 +0100, Jon wrote:
On Fri, 19 Feb 2010 21:25:38 +1100 Lex Trotman elextr@gmail.com wrote:
Thats because sum is listed as a keyword in Geanys filetypes.r file. Someone who is knowledgeable in R should have a look and check the filetypes.r file and submit a patch.
OK. I've got a basic patch for that. I've not gone through the whole packages list, but I've removed everything that's not syntax ("if", "then", "else", etc.) from the primary list. I've had a look at the scintilla code, but I'm not sure about it. It seems to correctly include "." as part of a word, but then later excludes it (If I'm reading the code correctly). I'll try playing with a little later since my efforts thus far haven't changed anything.
I think I need a better understanding of what Scintilla is doing before I can properly debug that one.
Should I send the geany patch to the mailing list or just put it in the tracker? And should I open a new issue in the tracker, or add it to my R-Parser patch that's already there?
What exactly do you mean with 'the geany patch'? I'm going to add your R symbol parser to SVN.
For the syntax highlighting issue, please open a bug report at the Scintilla project as Lex said and attach the patch their if you have one. We'll get the changes into Geany when we update our Scintilla copy or we can also manually backport the change. But, also as Lex said, we'd like to stay as close as possible with Scintilla upstream.
Regards, Enrico
On Sun, 21 Feb 2010 15:13:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
What exactly do you mean with 'the geany patch'? I'm going to add your R symbol parser to SVN.
The "geany patch" patches the filetypes.r file to modify the listed symbols. It cleans up the syntax colouring so that keywords are identified differently from function names (there were actually some overlapping keywords in the file.)
For the syntax highlighting issue, please open a bug report at the Scintilla project as Lex said and attach the patch their if you have one.
If I can track down the issue with Scintilla and "." characters I'll do exactly that.
Thanks.
Jon
On Sun, 21 Feb 2010 15:29:16 +0100, Jon wrote:
On Sun, 21 Feb 2010 15:13:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
What exactly do you mean with 'the geany patch'? I'm going to add your R symbol parser to SVN.
The "geany patch" patches the filetypes.r file to modify the listed symbols. It cleans up the syntax colouring so that keywords are identified differently from function names (there were actually some overlapping keywords in the file.)
Ah, cool. Just send it here.
Btw, I just committed the other patch to add the R tag parser. Thanks.
Regards, Enrico
On Sun, 21 Feb 2010 15:53:48 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Ah, cool. Just send it here.
Attached! This is not truely complete as I haven't "audited" the remaining keywords, but it resolves the issue that Liviu highlighted in his email. I'll try and take a look at Scintilla this week.
Btw, I just committed the other patch to add the R tag parser. Thanks.
Cool. I've got that warm fuzzy feeling of having actually contributed to FOSS as opposed to just promoting it! :-)
Jon
On Sun, 21 Feb 2010 18:32:43 +0100, Jon wrote:
On Sun, 21 Feb 2010 15:53:48 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Ah, cool. Just send it here.
Attached! This is not truely complete as I haven't "audited" the
Committed! :)
Thanks again.
Btw, I just committed the other patch to add the R tag parser. Thanks.
Cool. I've got that warm fuzzy feeling of having actually contributed to FOSS as opposed to just promoting it! :-)
Heh, don't worry. I'd even consider reporting bugs as contribting. Sort of, it depends how the bug report looks like...(something like 'it doesn't work' probably isn't worth to be called contribution :D)
Regards, Enrico
On 2/17/10, Jon Senior jon@restlesslemon.co.uk wrote:
For my sins, I'm obliged to develop code in R, and a while back I added in a tagmanager parser for R symbols. The parser is not mine, but
I just tried the new parser, and it's very helpful. Thanks!
On 2/21/10, Jon Senior jon@restlesslemon.co.uk wrote:
Attached! This is not truely complete as I haven't "audited" the remaining keywords, but it resolves the issue that Liviu highlighted in his email. I'll try and take a look at Scintilla this week.
I also tried the new filetypes.r and it is indeed better. However there are still some issues with the defaults: - for some reason NULL, Inf, NaN, FALSE and the like are not getting the primary keyword formatting. Perhaps because of capitals? (Open filetypes.r in Geany and you will quickly notice it: look for black within the blue line of keywords.) - some package keywords are duplicates of primary keywords, and probably should be removed (Open filetypes.r in Geany and you will quickly notice it: look for blue within the red line of keywords.) - "number" and "string2" share the 0x008000 colour. "string" and "string2" share different colours. Since in R `'' and `"' comments are equivalent and interchangeable, it would makes sense for them to share colours. I also prefer to have "number" colour different from that of "string(2)". I currently use number=0xff901e;0xffffff;false;false # "blah" string string=0x008000;0xffffff;false;false
Would this be better defaults?
Liviu
On Sun, 21 Feb 2010 22:11:58 +0000 Liviu Andronic landronimirc@gmail.com wrote:
I also tried the new filetypes.r and it is indeed better. However there are still some issues with the defaults:
- for some reason NULL, Inf, NaN, FALSE and the like are not getting
the primary keyword formatting. Perhaps because of capitals? (Open filetypes.r in Geany and you will quickly notice it: look for black within the blue line of keywords.)
I did notice that when I was tweaking it. I think the capitals are probably to blame. Is there anyone who can confirm this?
- some package keywords are duplicates of primary keywords, and
probably should be removed (Open filetypes.r in Geany and you will quickly notice it: look for blue within the red line of keywords.)
Got them!
- "number" and "string2" share the 0x008000 colour. "string" and
"string2" share different colours. Since in R `'' and `"' comments are equivalent and interchangeable, it would makes sense for them to share colours. I also prefer to have "number" colour different from that of "string(2)". I currently use number=0xff901e;0xffffff;false;false # "blah" string string=0x008000;0xffffff;false;false
Interestingly in the svn copy of filetypes.r, number=0x007f00. I agree about the strings though and I've modified it to keep them the same. I'll have a play with these changes locally before posting the patch here.
Jon
On Mon, 22 Feb 2010 08:27:43 +0100 Jon Senior jon@restlesslemon.co.uk wrote:
I did notice that when I was tweaking it. I think the capitals are probably to blame. Is there anyone who can confirm this?
OK. A little testing reveals that if the entries in filetypes.r are in lowercase, then capitalised versions of those keywords will be correctly highlighted.
Strangely, this implies that some aspect of the keyword storage is case-insensitive. To be honest, I'm floundering out of my depth here. Could someone point me in the direction of the code that loads the keywords from the filetypes.xxx file. I've found the structures in Scintilla that hold the keywords, but I'm not sure how they're being populated. If I can track the process through from start to finish, I might get a better idea as to what is going on!
Jon
On 22 February 2010 19:24, Jon Senior jon@restlesslemon.co.uk wrote:
On Mon, 22 Feb 2010 08:27:43 +0100 Jon Senior jon@restlesslemon.co.uk wrote:
I did notice that when I was tweaking it. I think the capitals are probably to blame. Is there anyone who can confirm this?
OK. A little testing reveals that if the entries in filetypes.r are in lowercase, then capitalised versions of those keywords will be correctly highlighted.
Strangely, this implies that some aspect of the keyword storage is case-insensitive. To be honest, I'm floundering out of my depth here. Could someone point me in the direction of the code that loads the keywords from the filetypes.xxx file. I've found the structures in Scintilla that hold the keywords, but I'm not sure how they're being populated. If I can track the process through from start to finish, I might get a better idea as to what is going on!
A quick look at LexR.cxx shows that it converts text that matches an identifier to lower case before searching the keyword list, so as far as the Scintilla lexer is concerned keywords are case insensitive, and the keyword list is expected to be lower case.
Cheers Lex
Jon
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 22 Feb 2010 21:49:21 +1100 Lex Trotman elextr@gmail.com wrote:
A quick look at LexR.cxx shows that it converts text that matches an identifier to lower case before searching the keyword list, so as far as the Scintilla lexer is concerned keywords are case insensitive, and the keyword list is expected to be lower case.
Thanks for that. I'll file a bug report against Scintilla.
Jon
On 22 February 2010 22:11, Jon Senior jon@restlesslemon.co.uk wrote:
On Mon, 22 Feb 2010 21:49:21 +1100 Lex Trotman elextr@gmail.com wrote:
A quick look at LexR.cxx shows that it converts text that matches an identifier to lower case before searching the keyword list, so as far as the Scintilla lexer is concerned keywords are case insensitive, and the keyword list is expected to be lower case.
Thanks for that. I'll file a bug report against Scintilla.
I also noticed that the definition used for a word character is ASCII alphanumeric but the R doc (which I checked after the fact :-) says it is locale sensitive.
Cheers Lex
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 22 Feb 2010 22:15:49 +1100 Lex Trotman elextr@gmail.com wrote:
I also noticed that the definition used for a word character is ASCII alphanumeric but the R doc (which I checked after the fact :-) says it is locale sensitive.
Not sure about correcting that one. Might just be a case of removing the "< 0x80" test, but looking at a different lexer that supports Unicode it may not be so simple... or even possible.
I've attached a copy of LexR.cxx that fixes the lowercase conundrum. The same file has been submitted to the Scintilla project, but we'll have to wait and see if it's accepted.
Jon
And here's the updated patch for the filetypes.r file. Adds "T" and "F" and corrects some overlapping definitions. Highlighting only works properly in conjunction with the modified version of LexR.cxx.
Jon
On Mon, 22 Feb 2010 12:48:52 +0100, Jon wrote:
Heya,
And here's the updated patch for the filetypes.r file. Adds "T" and "F" and corrects some overlapping definitions. Highlighting only works properly in conjunction with the modified version of LexR.cxx.
committed, thanks Jon.
Regards, Enrico
On Mon, 22 Feb 2010 23:27:36 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 22 Feb 2010 12:48:52 +0100, Jon wrote:
Heya,
And here's the updated patch for the filetypes.r file. Adds "T" and "F" and corrects some overlapping definitions. Highlighting only works properly in conjunction with the modified version of LexR.cxx.
committed, thanks Jon.
Just got an update to my modification of LexR.cxx. It has been committed to cvs in the Scintilla project, so should be available as vanilla Scintilla for geany.
Jon
On Wed, 24 Feb 2010 09:25:25 +0100, Jon wrote:
On Mon, 22 Feb 2010 23:27:36 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 22 Feb 2010 12:48:52 +0100, Jon wrote:
Heya,
And here's the updated patch for the filetypes.r file. Adds "T" and "F" and corrects some overlapping definitions. Highlighting only works properly in conjunction with the modified version of LexR.cxx.
committed, thanks Jon.
Just got an update to my modification of LexR.cxx. It has been committed to cvs in the Scintilla project, so should be available as vanilla Scintilla for geany.
Committed.
Regards, Enrico
On 2/22/10, Jon Senior jon@restlesslemon.co.uk wrote:
colours. I also prefer to have "number" colour different from that of "string(2)". I currently use number=0xff901e;0xffffff;false;false # "blah" string string=0x008000;0xffffff;false;false
Interestingly in the svn copy of filetypes.r, number=0x007f00.
You are right that nominally the colours are different---#007f00 for number and #008000 for string2---, but visually the two are very much alike. And I feel it's counter-productive to think of strings every time I see a number. I am not sure that #ff901e is a good default for numbers, but it looks better than the current defaults.
Liviu
On Mon, 22 Feb 2010 09:43:59 +0000 Liviu Andronic landronimirc@gmail.com wrote:
You are right that nominally the colours are different---#007f00 for number and #008000 for string2---, but visually the two are very much alike. And I feel it's counter-productive to think of strings every time I see a number. I am not sure that #ff901e is a good default for numbers, but it looks better than the current defaults.
I've actually swapped them in mine, so numbers are green and strings are orange. That's more in keeping with the highlighting in C / C++ / Java files.
I've attached my current filetypes.r file. This is *NOT* for inclusion as I don't yet understand what's happening with the capitalisation, but it does partially resolve the issue. "NULL" will appear correctly highlighted, but so will "null" which is clearly not correct. I'm not yet sure if it's a geany issue or a Scintilla issue so I don't know how long it'll take to resolve.
Jon
On 2/19/10, Jon Senior jon@restlesslemon.co.uk wrote:
scintilla code, but I'm not sure about it. It seems to correctly include "." as part of a word, but then later excludes it (If I'm
I've been investigating filetypes.r to see if it is possible to make Geany more friendly (when <ctrl>+right/left, selecting, double-click selecting, etc.) toward strings containing "." (dot), and I noticed this line: #wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
Changing it to wordchars=._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
doesn't seem to make a difference, although the documentation specifies that "wordchars These characters define word boundaries when making selections and searching using word matching options."
Any ideas on what's going wrong? Liviu
On Mon, 22 Feb 2010 13:25:49 +0000 Liviu Andronic landronimirc@gmail.com wrote:
I've been investigating filetypes.r to see if it is possible to make Geany more friendly (when <ctrl>+right/left, selecting, double-click selecting, etc.) toward strings containing "." (dot), and I noticed this line: #wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
Changing it to wordchars=._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
doesn't seem to make a difference, although the documentation specifies that "wordchars These characters define word boundaries when making selections and searching using word matching options."
Any ideas on what's going wrong?
I might be wrong, but I think that some of the stuff in the filetypes.foo files has now been taken over by Scintilla. Certainly, Scintilla seems to be responsible for comments and I'd suspect that you can change the comment start parameter to whatever you like with no ill effects!
Jon
On 23 February 2010 00:57, Jon Senior jon@restlesslemon.co.uk wrote:
On Mon, 22 Feb 2010 13:25:49 +0000 Liviu Andronic landronimirc@gmail.com wrote:
I've been investigating filetypes.r to see if it is possible to make Geany more friendly (when <ctrl>+right/left, selecting, double-click selecting, etc.) toward strings containing "." (dot), and I noticed this line:
#wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
Changing it to
wordchars=._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
doesn't seem to make a difference, although the documentation specifies that "wordchars These characters define word boundaries when making selections and searching using word matching options."
Any ideas on what's going wrong?
I might be wrong, but I think that some of the stuff in the filetypes.foo files has now been taken over by Scintilla. Certainly, Scintilla seems to be responsible for comments and I'd suspect that you can change the comment start parameter to whatever you like with no ill effects!
It has no effect because the Scintilla R parser ignores the wordchars argument and instead uses its own hard coded definition (which has a bug). Which parts of the filetype definition files are actually used is dependent on the parser for the particular language. Unfortunately I know of no documentation in the Scintilla project (other than the code:-) that defines what capabilities each parser has and what parameters are used.
Cheers Lex
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 2/19/10, Jon Senior jon@restlesslemon.co.uk wrote:
- objects don't seem recognised at all.
In what sense? I think it doesn't highlight objects that you've created, although I could be wrong.
I'm comparing the Geany highlighting with that of JGR. In the latter,
fun1 <- function(x) sum(x) fun1
typing "fun1" or
obj1 <- iris obj1
typing "obj1" will make JGR recognise it as a function/object and immediately render it in blue and italic (current settings here, I think). In Geany nothing similar happens.
To be honest I only really notice the highlighting for strings and the bracket closing.
Unfortunately I notice a bit more than that. :) Liviu
Are these failures of the current parser implementation, or is this something that one should expect? Thanks
It's the syntax highlighting, not the tag parser (tags are things like function definitions or global variable definitions). I've not really looked at it enough to see how tuneable it is. It's been a while since I delved into the R template files. Maybe later today.
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 19 Feb 2010 10:34:59 +0100, Jon wrote:
On Fri, 19 Feb 2010 08:53:28 +0000 Liviu Andronic landronimirc@gmail.com wrote:
I am currently using Geany for my R needs, and I was curious whether the patch provides something more than the current syntax highlighting support. If so, wouldn't it be safer to open a patched bug report [1]?
I shall do exactly that. I wasn't sure what the protocol here was. As
There is no official protocol. Sending patches to the devel mailing list is completely fine (with me) as it makes it easy to discuss the changes. But as usual, this is an asynchronous medium so replies may take a while (especially in my case :D).
Attaching patches to bug reports/feature requests in the tracker is fine as well. So don't worry :).
Regards, Enrico