Edward, On Sun, Dec 15, 2019 at 5:42 PM Edward K. Ream <[email protected]> wrote:
> On Sun, Dec 15, 2019 at 7:59 AM Brian Theado <[email protected]> > wrote: > [...] > That behavior doesn't seem to be the most user friendly. Better that than >> having the bug where changes are lost, but I wonder if there is a way to >> have both without it being too complicated? >> > > This is actually a completely different issue :-) #1451 involves making > sure that all external files are written, which devolves into making sure > that all @<file> nodes are marked dirty when they need to be. > It is a different issue, but one being created as "collateral damage" by the dirty changes you are making for #1451. Or am I misunderstanding? I mean the scenario I described where the user gets unnecessarily prompted about saving changes it not present prior to #1451 changes. > The behavior you mention involves making sure that the user is given the > opportunity to save external files (and the outline itself) when they try > to close the outline. Leo's behavior is standard in this regard, with the > proviso that change may "cancel" so that no change is actually made. It > would be possible to do a trial write to see if there were any change, but > that's a nit, and it would substantially complicate the code. Imo, it's > not worth doing. > I agree having code which does a trial write is not worthwhile. However, having code which did perfect dirty bookkeeping could be worthwhile if it were easy enough to do and be sure enough it won't cause any data loss. > > Just thinking out loud, but maybe it would work to have a dirty counters >> for the nodes. After a save, all the dirty counters are reset to zero. Undo >> operations decrement the dirty counter for affected nodes and redo >> operations increment the counter. Any time a given node's counter is at >> zero, the dirty bit is cleared and any time the counter is non-zero, the >> bit is lit. >> > > There have been proposals for per-node undo, and this is similar. After > congratulating myself on eliminating evil undo-related state, I am in no > mood to add any new caching. The total advantage of such a scheme, in the > entire projected history of the universe, does not begin to compare with > the pain that any bug in such a scheme would cause. > The way I describe it implies two separate pieces of data (dirty counter and dirty bit) and I think that's what you mean when you say "new caching"? I don't think perfect bookkeeping of dirty bits necessarily requires the use of caching, but I can appreciate that implementing such perfect bookkeeping might be quite difficult in a complicated code base and not worth the trouble. I just wanted to raise the issue to make sure the trade offs were clear. The user is getting a good bargain: losing a little by getting unnecessarily prompted for saving files which are unchanged, but gaining a lot by making sure all external files are written. Brian -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAO5X8Czs_X%2Bo8-xA477_%2BoV-WX6pkjQuCWUo4QTMWu_nTcYhTw%40mail.gmail.com.
