For various reasons, some of them personal, I'm anxious to move on to the next step in folding even though the folding criteria are not fully resolved or described in one complete document.
So, I'm going to suggest that we start moving forward--if anyone strenuously objects, we can back off. I guess I'd then be concerned that it is unlikely that we'll get anything done in this year's GSoC (well, except maybe the folding mark gutter). On the other hand, it is not real likely that we'll even be approved as a mentoring organization anyway. (But, I guess there is a real outside chance that a student would choose to do a project for NEdit, but be mentored by some other organization.) Next, if we start moving forward, what is the next thing to discuss? The thing that I've been looking forward to discussing is, as I'll characterize it, the back-end storage to support folding. In general terms, what changes must be made to the gapped-buffer (which, iiuc, is created and handled primarily in textBuf.c/h) to support folding, or maybe to the text (display) widget and any storage associated with it? From a very ignorant perspective, I'm going to start with two very general possibilities: * we can leave hidden text in the gapped buffer, somehow mark it as hidden, and navigate around it * we can take hidden text out of the gapped buffer (move it to some other storage structure), and then it is sort of automatically hidden and we don't have to navigate around it (There are many oversimplifications in the above, many, I'm sure, that I don't even recognize.) There are also some other possibilities that may be feasible, but I don't have the knowledge at this point to evaluate: * in an off-list discussion with some developers a few years ago (the "key" developer in those discussions seems to no longer be around), the thought was that lines could be hidden by (iiuc), leaving the text in the gapped buffer but omitting the start of those lines form the lineStarts array (in either textBuf.c or textDisp.c). (Aside: Some grepping I did a few weeks ago makes me suspect that there might be two different lineStarts arrays in the nedit code.) * *if* it would be the case that there is a separate text storage structure associated with a text display widget (i.e., distinct from the gapped buffer, which I'm assuming, so far, is sort of the "base" storage structure for an open file), there could be a possibility to leave all text (folded and unfolded) in the gapped buffer, but move only unfolded text to the storage associated with the display widget. (My unknowledgable and limited exploration of the nedit code so far makes me believe that is not the case, iiuc, storage for the text display widget is a different structure, but the text itself is in a portion of that structure that simply points to the gapped buffer.) On a slightly different topic (but still related to nedit internals), that same (missing) developer planned to use rangesets to mark the folding ranges. At the time, I (and maybe others??) was a little concerned, knowing that ranges in a rangeset will "coalesce" if they meet, about supporting hierarchical folding. Thinking back on that more recently, I think that concern was misplaced, as the key would be to have a different rangeset for each level in the hierarchy, and thus, ranges should neither meet nor overlap. So, ranges would not be out of the question for denoting folding rantes, or at least not because of concern over hierarchical folding. Anyway, comments, criticisms, suggestions...? Can/should we try to move forward, or should me (or someone else) try to take all the comments expressed on the folding criteria and try to create a complete and agreed upon document before proceeding? (If I do it, I really should try to put it off for about two months with the personal matters that I really must deal with first.) Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
