Joachim,
Thanks very much for taking the time to read and offer comments on the
proposal, and for starting a dialog on this subject! (I'm sorry that it's
not written better so as to be easier to understand.)
I'm not sure I know exactly what you're suggesting, so I have some questions
and comments interspersed below.
On Wednesday 26 March 2008 05:04 am, Joachim Lous wrote:
> I'm not crazy about complex systems being kept in sync
> unless absolutely necessary. Always increases complexity
> and creates a horde of potential error conditions that you
> need to keep in mind for the smallest step, and really can
> do without. Even on the design level it can be hard to think
> clearly about which of the two states are "right" until they
> are in sync.
>
> As long as the 'real' buffer, the folding ranges and their
> states can be sufficient to reconstruct the display
> state, then that full-round-trip model should be used to
> define correct behavior.
Are you suggesting that there should not be two textBufs (folded and unfolded)
but only one?
Or, are you saying that you don't seriously object to both, but want the
standard of correct behavior to be based on one of them (would that be the
unfolded buffer?)? (And maybe then all navigation and similar occur in that
buffer?)
Below, I'm assuming that you're considering the folded textBuf to be an
optimization / cache?
> Now, the implementation of the folding display layer might
> of course choose to use some form of caching to improve
> performance, but that is an optimisation, and comes with
> all the usual caveats:
> - Don't do it until you're sure that what it addresses is indeed
> a significant bottleneck. The cost is not just the added work,
> but also the added complexity and reduced flexibility
> impacting all later work. It better pay of in important ways
> to justify that.
> - It should be completely internal to the component that
> uses it, and have no power to affect its spec: if behavior
> differs from the unoptimized version, there should be no doubt
> that the optimisation is at fault, and forcing a full refresh
> from the background state should always work as a quick-
> fix.
I'm making some assumptions here, but if you are suggesting that we use a
single textBuf approach, I think we're back to the two options I originally
considered, that is:
* Leave folded (hidden) text in the textBuf, and:
* modify the display widget to not display it, and
* modify navigation logic (and similar) to ignore it
* Take folded text out of the textBuf, and store it in some other storage
mechanism (while tracking where it came from / belongs in the textBuf)
Do you see other alternatives? If not, which of those two would you advocate?
regards,
Randy Kramer
> On Sat, Mar 15, 2008 at 5:54 PM, Randy Kramer <[EMAIL PROTECTED]> wrote:
> > I've written a rough draft of a proposal for "back end" changes to Nedit
to
> > support folding. See:
> >
> > http://twiki.org/cgi-bin/view/Wikilearn/NeditFoldingDesignBackEnd
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
