On Tue, Oct 22, 2013 at 8:35 AM, Zoom.Quiet <zoom.qu...@gmail.com> wrote:
How to support Leo user can work with own organizer nodes in Team? > The Leo community must acknowledge that problems do exist. Having said that, the problems aren't as big as some people say. > > of course, the problem had difference background: > 1. the Team is all Leo user > 2. the Team is only one Leo user > 3. the Team is some Leo user > If everyone uses Leo, there is not much of a problem, because everybody wants can live with sentinels and use @file. Situations 2 and 3 are similar, because those who don't use Leo, no matter how many there are, will complain if Leo users insert sentinels. base doc suggest: > - @nosent and @auto all nonutility for all conditions in team > - because can not support own organizer nodes, Leo is same VS! > The situation is not so bad with @auto. You could use @auto as follows: 1. Import into @auto. 2. Change @auto to @file while you do your work. 3. Change @file to @nosent (say) to save the file. 4. Commit your change. - @shadow is good for the condition 2 > - but real > l > y can not perfect merge others fixed into own organizer nodes! > Again, the situation is not so bad. This is discussed here: http://leoeditor.com/atShadow.html#aha-boundary-cases-don-t-matter Yes, @shadow algorithm can't always guess exactly where a line should go, but the essential fact is that **bad guesses don't matter**. That is, the external file written by the "faulty" @shadow tree will be correct. Furthermore, if you correct the bad guess, the @shadow algorithm will *remember* your correction. In short, you *can* use @shadow in collaborative environments with complete safety, but you may want to move lines from one node to another for *yourself*. - @file also good for the condition 2 > - but for others, @file export so many external comment > - is very surliness, and often broken by people. > Right. @file isn't great for either condition 2 or condition 3. The people who *don't* use Leo won't like the sentinels. > > - for others conditions > - because @shadow can not generate different .shadow file from > different .leo > - so that means Leo users can not with @shadow coordination > No. @shadow should work correctly in all situations. That is, the *public* file will be the same, even though the private files (and thus that @shadow trees in the various .leo files) may be different. > > so? conclusion is Leo just only self usage, can not cooperate with team? > My conclusions are as follows: 1. If all else fails, you can always use @edit for shared files. This won't be fun, but it's equivalent to using Emacs. BTW, neither vim nor Emacs is free from difficulties when using shared files. SCCS conflicts will happen! And of course, for shared files that are changing quickly, you can just use a plain text editor. 2. @auto isn't great, but if you are going to do a lot of editing on a shared file, you can use @auto to import the file, change @auto to @file while you work, and then to @nosent to write the file just before you commit it. 3. @shadow should work properly for shared files, even though the @shadow algorithm will make "bad guesses" and put lines in the wrong nodes. Bad guesses do **not** affect the external file. I call this **the fundamental @shadow theorem**. Bernhard Mulder may understood that @shadow is sound, but he never stated the theorem. When I understood that the theorem was needed, it was quite easy to prove it. @shadow became an official part of Leo only after I saw that @shadow is *completely* sound. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
