Since I'm working on the second official (official here being a word meaning "to appear in rnfnCodeLite's GoogleCode SVN") rewrite, some redesigning is being done as well. For starters, instead of having the control and all of its classes appear in the rnfn.Control.CodeLite namespace, where the user would have to access rnfn.Controls.CodeLite.rnfnCodeLite(which I consider to be somewhat redundant), rnfnCodeLite is now under the namespace rnfn.Controls and contains the various subclasses, both public and internal, across multiple files as a partial class. I've heard that some dislike partial classes, but this seems to best suit my purposes of having the control be a single 'entity' for the user to access as well as not cluttering up rnfn.Controls.
Part of the focus of the redesign is putting the 'lite' back in rnfnCodeLite, both in the size of the dll as well as the memory footprint. So far, haven't done much in that regards, but I haven't gone far into the rewrite either. I have reduced TextNode down to two members, losing the internal bool linked; member and instead adding two more values to the TextNode.Activity enum that are more descriptive and perform the same function, in effect, as the linked bool did.
A major design change is how I'm handling the syntax highlighting and intellisense portions. Prior to this rewrite, I had this:
internal class Syntax:LinkedList { public class SyntaxNode { internal string text; internal SyntaxStyle style; public SyntaxNode(string text,SyntaxStyle style) { this.text=text; this.style=style; } } public class SyntaxStyle { internal Pen forePen; internal Pen backPen; public SyntaxStyle(Pen forePen,Pen backPen) { this.forePen=forePen; this.backPen=backPen; } } }I had the intent of expanding upon Syntaxstyle to include numerous common syntax highlighting types, as well as setting up something to allow for custom drawing(per benryves). However, this got all borked up when I realized that some of the features I was going to have in Syntaxstyle would work if they were broken up. For example, a dashed bounding box couldn't be drawn around if(this>that) since the 'if' bit, if nothing else, would probably be drawn a different color, and the box would be two seperate boxes if set for both the 'if' and the rest of the string. So, I'm doing away with Syntax* entirely. TextNode will no longer keep track of syntax data, there will be no syntax styles. As far as rnfnCodeLite is concerned, with this implementation, it will not deal with drawing the text at all. Instead, and doing away with Lexer and Library from the pre-rewrite(which I'd merged into Language or something shortly before this rewrite), CodeEngine will be the combination of anything related to the drawing of the text/code and any intellisense features thereof. It will be similiar to System.Windows.Forms.Control, having a PaintLine, or maybe it will just be Paint, event that will be fired when a line needs to be redrawn. rnfnCodeLite will still keep track of what needs to be redrawn and when, though CodeEngine will be able to flag lines as being needed to be redrawn, which will be redrawn if they are viewable. That code is already in place(at least the tracking of lines, not the drawing).
CodeEngine will probably be the bulk of the editor, and I'm still considering on how much customizing should be done. I'll need to have it be able to access as much of the text as it should be allowed to via properties and what not. I'm still not sure on what events it should have at its disposal... Should I include everything, including keyboard/mouse input? If I include the input, should I already handle it, or let CodeEngine handle it? I suppose I could take a page from System.Windows.Forms again and have an Handled property, where if it is false after having been fired, I'll just go ahead and handle it myself. At least I'll do it for the keyboard input. I might leave the mouse input alone, as the only use for that, that I can see, would be for intellisense, which it *should* be using its own controls for that. Hopefully I'll find a nice balance between customization and ease of use, so one isn't overly limited to what they can do, but they aren't required to handle all sorts of 'default' things if they don't want to.
As far as what implementations of CodeEngine(which is abstract, btw) will come with rnfnCodeLite, I know for a fact it will have something akin to DefaultEngine where all the text will be drawn with the ForeColor of the control. As with the pre-rewrite, this will be what the code engine is set to when set to null in rnfnCodeLite. Beyond that, I'm not sure. In the pre-rewrite(getting tired of that silly word), I was planning to have some sort of general syntax keyword engine, where it had the data for a few common languages(C,C++,C#,Java,Python, various flavours of Basic and asm, maybe more). Depending on how much space that'd take up, however(yeah yeah, I know, space shouldn't be a concern), I may end up making the various languages' data available seperately for download, and, quite possibly, the keyword engine itself. I'll only do this if it takes up a significant amount of space, however. Say, over 5-10kb.
Feedback is much appreciated.
