I don't understand what Leo-Editor is doing in this case. I don't know Edward K. Ream's intentions in this case. Undoubtedly the following will fluctuate between accurate observation, correct surmise, and plain wrong guesses. I hope someone can enlighten me.
The external files I'm concerned with are @file files. Some or all of the problems I've seen may apply to other kinds of external files: @nosent, @edit, @auto, etc. EKR recommended cloning the nodes of current interest and moving them to the bottom of the outline. So I tried it, and liked it--until I happened to use a plain text editor to change an external file. Then I spent many hours trying to get these changes into the .leo file. Even though the modification time on the external file was long after the modification time of the .leo file, Leo-Editor silently ignored the changes. Eventually, I guessed that the problem was in the cache. So I invoked Leo-Editor with --no-cache. This didn't help. I used the command clear-cache. This didn't help. I used a file browser to delete the Leo-Editor cache. This didn't help. So I began seriously investigating and guessing. The old data wasn't in the cache. The new data was in the external file. Where could Leo-Editor get the old data? The .leo file, of course. When a cloned node resides in both an external file and outside the external file, all the data in the subtree rooted by the cloned node may be subject to being saved in the external file and in the .leo file. My first guess was that all of the data in the subtree should always be saved in both the external file and in the .leo file, but I've seen a case where only 2 nodes out of 19 were saved in the .leo file. What is the programmer's intention? Based on observations, I guessed that when the external file modification time is earlier than the .leo modification time, Leo-Editor silently ignores the changes in the external file. But this isn't strictly true, because in one of my tests, the .leo modification time was 30 seconds later than the external file modification time and Leo-Editor noticed the changes in the external file and generated a "Recovered Nodes" subtree. What is the programmer's intention? Based on my current imperfect understanding, I believe that the file modification times should not be used at all. They lead to wrong conclusions much too often because the .leo file can too easily be changed in a node that has nothing to do with the external file in question, making its modification time later than the external file. It would be a better bet that when the external file differs from the .leo file, the external file contains what the user wants. It would be best not to bet at all. Just present the two versions to the operator and make him choose. I guessed that the cache "should" have nothing to do with the problem of data that is in both the external file and the .leo file. The simplest thing that could possibly work would be comparing the two versions and complaining when they don't match. But in one of my experiments, I made the modification time on the external file longer, and longer, and finally 3.5 minutes after the .leo modification time--and the changes in the external file were still silently ignored. Finally without changing the modification times of the external file or the .leo file, I invoked Leo-Editor with --no-cache and this time Leo-Editor noticed the changes, brought them into the .leo file and generated a "Recovered Nodes" subtree. Is this the programmer's intention or bug? I did all of my testing under Xubuntu 12.04. I used Leo-Editor Rev 6200 for most of my testing, and I confirmed a few of my tests using Rev 6389. -- 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.
