This sounds ok to me - there's something wrong in the current code that could perhaps be hunted down, but I know I already fixed one reproducible bug in this area so it's obviously a hairy area. So the below approach seems like the most robust.
I'd just add that the use case I have mostly is "yes to all". I.e. they're not really open elsewhere. Hmmm, I guess there's nothing to add to the below to deal with that - the warnings / dialog should say "this / these outlines *appear* to be open elsewhere" - in my case it arises from killing Leo accidentally in virtual machines, VNC connections, dropped X11 forwarding etc. Cheers -Terry On Sat, 20 Jun 2015 16:01:07 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote: > #199 <https://github.com/leo-editor/leo-editor/issues/199> is > presently the most serious bug in Leo. Sometimes, but not always, > cancelling the load of an already-opened .leo file will hard crash > Leo (Python). > > This post is an Engineering Notebook post. It's most notes to myself > and Terry. Feel free to ignore. > > I am studying a core dump on Ubuntu. It's been fun learning about > apport-retrace > <http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html>, > but not *that *much fun. Terry's analysis of the problem is good > enough for me. It's time to solve the problem with design, not mere > code. > > > > *The original problem*Leo should indeed warn users when they attempt > to open an already-open file, call it *f.leo*. Saving either copy of > f.leo could destroy data previously saved in the *other* copy of > f.leo. > > The problem is not actually very serious, because Leo *already *warns > if f.leo has been changed outside of the presently executing copy of > Leo. For example, suppose two invocations of Leo exists. Let's call > them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, > Leo B will issue a warning that f.leo has been changed outside of B. > > Still, I think it is best to warn the user if f.leo is already open. > > The mechanism for checking for already-open files is fine. Leo makes > entries in the global db file when opening a file and deletes entries > in the db when closing the file. This can lead to spurious "already > open" messages if Leo is killed rather than being closed normally. > The db will contain an entry for a .leo file that is not, in fact, > open. Happily, this has never been a big deal. Furthermore, the > following scheme handles this case even more smoothly than before. > > *Proposal: always open files, even if already open* > > Leo will no longer issue *per-file* requests for guidance. Instead, > Leo will open all possibly-already-open files, putting warnings about > them in the log. Finally, Leo will raise a *single *warning dialog. > This dialog will list the files that might already be open, and > suggest that the user close duplicate files in whatever copy of Leo > is more convenient. > > This scheme solves several problems: > > 1. Leo always loads files. This instantly eliminates the possibility > of hard crashes. > > 2. It's faster than the existing scheme. The user only has to > dismiss the summary dialog. > > 3. The user will never have to choose *right now *what action to > take. Such choices are *always *odious and stressful. Instead, the > user can choose to close the duplicate f.leo file in either A or B. > In most cases, it's safe to leave *both* copies open, as long as both > don't change. To repeat, Leo will issue a warning if that happens. > > 4. Closing a duplicate file, in either A or B, automatically clears > the db entry for that file. There is no need to ask the user whether > to reset the db! > > The only complication will be knowing exactly when/where to issue the > warning dialog. The details will be different depending on whether > Leo is loading multiple files at startup, or loading a single file > later. But this is only a coding detail. > > *Summary* > > A single dialog that warns about possibly-already-open files is the > simplest thing that could possibly work: > > - It's easy to code. > - It will stamp out hard crashes. > - It's simpler, faster, more flexible and less stressful for the user. > > Unless there are strong objections to this scheme, I plan to put it > into effect immediately. > > Your comments, please, Amigos. > > Edward > <http://manpages.ubuntu.com/apport-retrace> > -- 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/d/optout.
