I must admit I haven't read the proposal all that thoroughly or thought through all the details. I just reacted a bit to seeing 'two buffers in sync' in the first sentences. And as you point out, I didn't really suggest any solutions. I have probably been a bit brash, and I apologise.
My input was meant more as general advice: I just wanted to emphasise that if you have two things to keep in sync, there is always a cost in the form of code complexity compared to having just one definitive state (and code complexity is not a one-time expense, it just keeps on costing). If you don't need it, don't do it. If you do need it, see if it is possible to design the information flow as straightforward as possible, i.e. make sure one side is the 'truth', and the other one just a slave and a 'private' implementation detail irrelvant to the rest of the sytem. The trivial (but possibly too slow) implementation of that is to do everything with only one dataset and do all the transformations continuously as part of rendering. But of course, sometimes you do need more devious techniques. On the question of whether a second buffer is really appropriate in this case, I must confess I don't know the code well enough to say for sure. Possibly. Just don't assume from the start that it is. If it is possible to get adequate performance from doing it all on the fly, I think it would be a much cleaner and easier-to-maintain solution. Seeing how higlighting does perform quite well on-the-fly (as long as the patterns are fairly simple, just as a pre-calculated table of collapsed/collapsible regions would be), and the task of displaying collapsed regions at first glance seems to be on about the same level of complexity, I think a single-buffer solution should at least be investigated for feasability. I may of course be entirely wrong in my guesses. And in general, since I'm not volunteering to actually do any of the heavy lifting, feel free to just ignore my half-baked input. It is just meant to air some issues to consider. I know all too well that things are always different from first appearences when you have to do the nitty gritty design work. -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
