• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Of rnfnCodeLite and Grammars, Part 2

Sign in to follow this  


Mirrored Here

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

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 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.


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. >_>


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...
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement