Of rnfnCodeLite and Grammars, Part 2

Published August 19, 2009
Advertisement
Mirrored Here

What? Part 2 already? ZOMG! SRS BIZNIZ TIEM!
Anywho...

Righty-o. So in my previous post, I went over the rough draft of the rnfnBNF language. And now I'm supposed to go over "Intellisense, Scope, and AutoFormatting ideas/problems I have, as well as any changes I come up with and/or from feedback." Well there hasn't been any feedback at the time of this writing, so that bit is out the window. And I haven't come up with any changes overnight in my sleep. So this leaves us with my ideas/problems regarding IntelliSense, Scope, and AutoFormatting.

Scope


Scope is a bit problematic, at least I think it might be. I'm presuming/hoping scope only ever works in levels, with the innermost/lowest level being the one with the most access. If I presume this, then I can just deal with having _startScope() and _endScope(). This, at least, allows for a kind of "general" scope. I'm still thinking as to whether or not there is any benefit/disadvantage to having the scopes be named, for IntelliSense purposes.

IntelliSense


My ideas for handling IntelliSense still have a few holes. The first of which is handling scope, etc. Which is to say, while I may know every function in class FooBar of namespace Foo.Bar, I don't want the IntelliSense listing them as Foo.Bar.FooBar.classname in the suggestion modal. Rather, I need some form of scope division, which'll probably just be taken care of by assigning a scope seperator(s). Also, for something like using System.Windows.Forms, I need something in place to handle this "prefix" bit, though I suppose in conjunction with the scope seperator(s), I could have _addScopePrefix("System.Windows.Forms"). Of course, I need some manner of getting the unknown bit into it. That is to say, if the rule were using="using ", namespace, terminating-symbol;, for example, I'd need to get namespace in _addScopePrefix(...) somehow. At the moment, I'm debating between yet another function, such as _setParse(variable:rnfnBNF grammar), or something like variable:rnfnBNF grammar. So the difference would be between using="using ",_setParse(_namespace,namespace) _addScopePrefix(_namespace),terminating-symbol; and using="using ",_namespace:namespace _addScopePrefix(_namespace),terminating-symbol;. Personally, I'm liking the latter example at the moment.

Another problem with IntelliSense is building a "base" to work off of. For example, having the IntelliSense data for the .NET platform in a usable format for multiple languages. Or maybe I'll just let the program using the control provide this information. That'd probably be easiest/best. I still have to consider whether I want to allow for multi-language intellisense. >_>

AutoFormatting


Off the top of my head, the things that'd fall in this category mostly involve the placement of tabs, spaces, and/or newlines, the first two usually in regards to the level of scope that they take place. Something like _Scope()*'\t' would insert N tabs where N is the scope(or indention) level. As for actually making it part of AutoFormatting, and not just part of the rule definition, probably have something along the lines of _AutoFormat(rnfnBNF grammar), which would insert the rnfnBNF grammar if, and only if, AutoFormatting is turned on. Might throw in _AutoFormat(option=value:rnfnBNF grammar) to handle AutoFormatting options. Of course, I've have to come up with a safe way to generate a result for the rnfnBNF grammar, in case someone gets all funky with ORs and Optionals. I'll likely just take the first (left-most) of the ORs, disclude the optionals, etc.

Will there be a Part 3? Who knows...
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement