Hmmm, looks like this explains how I lost information in a file I worked on for several hours yesterday. I didn't know that refresh-from-disk was dangerous. I use it in a shared file setting with another person. Considering your workflow use to populate an empty @file node, why is that approach better (or different) from File>Open?
What strategy should I use to keep a file 'in-sync' between multiple users if refresh-from-disk shouldn't be used in that context? Rob.................. On Thursday, September 26, 2013 12:51:56 PM UTC-4, Edward K. Ream wrote: > > Refresh from disk is the feature of Ville's contextmenu plugin that I use > the most. This post proposes a way to use refresh-from-disk safely, or > mostly so. > > Any change discussed here will happen after b1 goes out the door, so there > is plenty of time for discussion. I encourage your comments. > > As discussed here: > https://groups.google.com/forum/#!topic/leo-editor/nIl3ud7Tbig, > refresh-from-disk has severe problems when the refreshed file has been > changed in the Leo outline. But my workflow uses refresh-from-disk only to > load external files into *empty* @file nodes. The typical scenario is:: > > 1. Create an @<file> node (that is, an @file, @auto or @edit node) for an > already existing external file, one that has already been written by Leo. > > 2. Use refresh-from-disk (accessible at present only using right-click) to > populate the @<file> node. > > Happily, Leo already has some infrastructure that remembers which @<file> > nodes Leo has read when loading the .leo file. Leo will warn if we are > about to overwrite a file that *wasn't* read during startup. > > I propose to use this infrastructure to enable refresh-from-disk only for > @<file> nodes that a) are empty and b) were not read at startup. > > This should be safe, although not completely safe. We can imagine a > situation in which the never-read external file nevertheless shares a clone > with the .leo file. In that case, there will still be problems if the > shared node has been altered somewhere in the .leo file. Still this, is a > remote possibility, much less likely than what triggered 1090950. We > have been living with bug 1090950 a long time; we can live with an even > rarer bug for longer yet. > > The potential objection I see is that refresh-from-disk might be useful in > other situation that the proposal seeks to outlaw. Well, so be it. > Refresh from disk on an altered, previously-read outline seems to dangerous > to allow at present. > > BTW, there is always a workaround to problems with refresh-from-disk. > Simply save the .leo file and reload. The save will be safe for never-read > @<file> nodes, provided that you say "no" when asked whether you want to > overwrite the existing file! > > Your comments, please Amigos. > > Edward > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
