I'm not really ready to get back into the folding effort fully, I still have quite a few other higher priority things to keep me busy. Still, I have had some thoughts about it again, and wanted to restart some discussion on the list.
I've thought of another approach to backend storage to support folding, and I started to work my way through some examples of different folding actions (folding a section, folding again (at a higher level) to create a nested fold, editing some unfolded areas, unfolding the top level fold to leave the previous lower level fold folded, etc.) to see if, at least in general, the approach I'm considering could conceptually work. (Aside: You may remember that (one of?) my earlier idea(s) was to create an additional textBuf, one to contain the full text of the document, and a second to contain the document in a (the "current") folded state.) I realized that I was making assumptions about the way nedit works rather than really understanding how it works--if I'm too far off in those assumptions, the working through of those examples will be of little or no value. So, I'd like to start (yet another) folding discussion on the mail list. The way I'd like to start is by asking some questions to confirm or clarify the assumptions I'm making. After resolving things on the mail list, I'll document them on a web page, probably on my WikiLearn site. I'll basically try to limit my questions to one (or one topic) per email. Here's the first: (I made this assumption after reading one or a few comments in nedit's source code. I couldn't confirm it by reading the code for various reasons, including that I'm not very good at reading C.) My understanding is that for the various nedit search operations, nedit doesn't perform the search in the textBuf (iir the name correctly), but instead it creates a string consisting of all the text in the document and then searches in that. Can any one confirm that? Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
