Afterthought: It is really not *that* difficult to re-create the leo outline after some files moved, so I don't know if it is worth a lot of effort to attempt this. Still, it would be cool. - Josef
On Friday, February 1, 2019 at 11:12:25 AM UTC+1, Josef wrote: > > Leo is good at staying in sync with file content. No matter which @file > command I use, my colleagues can edit the files, and Leo automatically > synchronizes with the changes. > The story becomes quite different, when we are talking about a directory > structure. The moment someone (myself or others) move some files around, I > only get a notification that the file did not get found - there is no > attempt to find it. Since Leo can deal with many files at once, it seems > natural to expect it should be able to keep track of the location of files > as well. The active_path plugin helps, but I hope for more. > > I realize that this is no trivial task and perhaps even an impossible one, > but in the early days of Leo nobody would have expected solutions like > @clean or @auto either, so why not ask for the impossible and see where we > can get? In the case the files haven't actually changed, but were only > moved, it may be easy to find the file again, either by comparing file size > etc, or by comparing content. Git does this "naturally" by storing all the > chunks by there SHA1 hash - perhaps Leo could do something similar? > > Here are some cases which I think should be addressed: > > 0. Files get changed but not moved -- Leo takes care of this already. > 1. Files get added -- active_path can help here, but I do not always want > to see *all* files in the Leo tree - only the ones I am working on. So, it > would be nice to see files added, which weren't there before, even though > the Leo tree only shows a subset. This should also ignore some files (for > example, anything in .gitignore). > 2. Files get moved outside of Leo, but not changed at the same time. It > would be great if Leo would find these automatically, at least if they are > found anywhere near the files which Leo is involved in. The active_path > plugin helps here, but I do not always want to load all the files into Leo, > only a subset. > 3. Files get deleted. Here I guess the file should get marked (active_path > does this. An icon would be better than the file name mangling, though). > 4. Files get moved and changed at the same time. I guess in many cases it > should still be possible to find the file, though It may be good to let the > user make the final decision what do do with it. I believe Git seems able > to find such files often too. > 5. The Leo file gets moved, and the files stay where they were. This > usually means I moved the Leo file, since I am not sharing my Leo files > with others. > 6. I move around @file nodes in Leo unter an @path node. Currently this > means the file gets copied, but logically I think the file should get > moved, unless I also copied the node. > > As I am writing this, I realize that it may be sufficient (for me) to let > git track the files and just keep Leo's outline in sync with git's idea of > history, since all the files which may be used by others are usually in Git > anyway. > > - Josef > -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
