On Wednesday 26 March 2008 09:35 pm, I wrote: ---< snipped stuff that doesn't matter in this scenario >---
So far I've made at least a slight attempt to restrict changes to those that might preserve as much as possible of the current NEdit backend. Now I'm wondering if more drastic changes might be appropriate or at least worthy of consideration? In a way, maybe I don't want to say any more than that in this post--just ask if it is appropriate to consider more drastic changes. But, I'm too impatient for that, maybe I'll give you one very half-baked possibility. Considering such more drastic changes doesn't really bother me too much at the moment because: * my original guesstimate for *me* to implement folding was (and still is) on the order of five years (yes, I'd like to do better, but I have a lot to learn) * I have a lot to learn, maybe more than I thought I did--once I learn all that, maybe I won't be quite as concerned about limiting changes to those that make a minimal impact on the existing back end Anyway, here is one (very half-baked) and only partial idea: Switch to a back end storage that (in general) does away with the gapped textBuf (actually, I might leave it, but I'll get back to that later) in favor of an approach that stores the text in multiple strings. (These *might* also have (optional) gaps to maintain editing (text entry) speed.) Those multiple strings/buffers would be: * of varying length * pointed to by various linked lists or similar structures There's more, but I'm thinking about how to describe it... Each string / buffer would contain, at most, text for one folding region--in other words, if another folding region is defined, a new string / buffer is created for it. On the other hand though, depending on the editing sequence, "fragmentation" might occur and the text for a given folding region might be scattered across several strings / buffers. Some of the various linked lists that would (or might) exist include: * one that reflects all the text in the document--in other words, if Nedit wants to display the entire unfolded document, it can "walk" (or better) the linked list, accessing the strings / buffers in that order, feed them to a text display widget, and thus display the entire document * one that reflects the current state of folding in the document--in other words, if Nedit wants to display the document in its "current" folded condition, it can "walk" (or better) this linked list, accessing the strings / buffers in that order, feed them to a text display widget, and thus display the portions of the document that are currently not folded (not hidden) * optionally, if it helps performance, we might have linked lists for each level of the folding hierarchy, to aid in quickly doing things like folding or unfolding all folding regions at a certain level in the hierarchy (remembering that the hierarchy for HTML documents is based on the heading level (preceding) a given folding region) I mentioned it earlier, but we might allow any one (or more) of those strings to have a gap to support faster text entry--or we might always split a string at the point of text entry (at the insertion point) (that doesn't sound real efficient to me, but I'm not ruling it out at this point in time). Also, for search, we'd probably want to create a search string similar to what we do today (iiuc) to expedite searching without having to worry about the position of the gap. I do want to remind myself (and others) about the problem in Kate that I've mentioned with respect to kate's problem to search for text which includes line breaks (\n) and the related problem with lookahead to use, for example, a level 1 heading (H1) to end all "open" folding regions that might exist at a certain point. I would want to make sure that we had some means to deal with this problem. Note that, without knowing too much about what they are, I expect the changes to the text display widget will be more drastic as it will no longer be working from a single textBuf (per tab/document). Anyway, I'm generally asking two questions: * are we willing to consider such more drastic backend changes in order to support folding? * and, if so, what comments do you have on this (half-baked) proposal? Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
