On Wednesday 26 March 2008 05:55 pm, Joachim Lous wrote: > 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.
No problem, and point taken. > And as you point out, I didn't really suggest any > solutions. But I am looking for feedback, and will take this into consideration. > I have probably been a bit brash, and I apologise. No need for an apology--we're just talking here! ;-) > 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. I'm looking for an easy way to accomplish folding. I thought / hoped moving the hidden text out of the textBuf might be a step in that direction, but I'm not all that familiar with the code by any means. And, thus, not likely to implement anything anytime soon. I'd just like to provoke some thinking about it, or maybe even provoke somebody to code it. ;-) > 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. If, in the end, it becomes up to me to code, I will try to develop what I (we?) think is the best approach before I start coding. It's just too painful for me to redo stuff. > 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. Appreciated! regards, Randy Kramer > 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
