2014-02-11 18:10 GMT+08:00 Edward K. Ream <edream...@gmail.com>: > This post attempts to explain, as clearly as possible, the strengths and > weaknesses of @file, @shadow and @auto > > ===== @file: the platinum standard > > @file will always be the best alternative in situations in which it can be > used. The reason is simple: it preserves all outline data (including clone > links) and fully supports all of Leo's features, including section > references. Last, but hardly least, Leo can read and write external files > created with @file more than twice as fast as files created with @shadow and > @auto. > > Otoh, @file inserts sentinels into external files, so it will often not be > possible to use @file in collaborative environments. > > ===== @shadow: often best in collaborative environments > > Like @file, @shadow supports all of Leo's features, including section > references. Unlike @file, @shadow inserts no sentinels in the public > external files. > > @shadow will work very well for **slowly changing** files, files that are > infrequently changed outside Leo. When changes *are* made outside Leo, > @shadow incorporates the changes in the *existing* outline structure. > @shadow can *never* create new nodes: all changes are "shoehorned" into the > existing outline. This may or may not be convenient, depending on the > situation > > ===== @auto: a gateway to @file or @auto > > When reading an @auto file, Leo creates outline structure from the external > file itself. The new @auto code only adds organizer nodes to the imported > structure. Furthermore, significant changes to files structure will prevent > the new @auto code from adding organizer nodes. Otoh, we expect that > significant changes to outline structure will be unlikely if those changes > are made outside Leo. > > The new @auto code could conceivably make @auto useful in more situations, > but @auto still suffers significant problems. It is slow, more error prone > than @file, and does not support section references. @auto will most > typically be useful in situations: > > 1. As a way of studying other people's files. > 2. As the first step in creating @shadow or @file nodes. > > I often combine these by converting @auto trees to @file trees for study. > > Alas, the new @auto code has not fundamentally changed how @auto will > typically be used. Perhaps the most important feature of the new @auto code > is that it allows clone links and (not-yet-implemented) uA's to be added to > @auto trees. > > ===== Summary > > @auto is slower and more error prone than @file, and @auto does not support > section references. As a result, @auto will never replace @file for Leo's > sources. > > The new @auto code does promise some additional benefits, but many people > will likely prefer @shadow in collaborative environments. >
thanx for compared them so detail; but through words, look like @auto just base bad name? flow Zen of Python - simple is better - every Leo action is simple and do only one things is better - so - @guess foucs: As a way of studying other people's files. - @prepare foucs: As the first step in creating @shadow or @file nodes. in fact i gree so much golang's spirit: if one futuare can not significantly improve the development efficiency ingore it! as disussed, the Leo big problem is : CAN NOT EASY EMBDED NORMAL TEAM DEVELOPING FLOW so the @auto is seem not clear and significantly future? > Edward > -- 人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦! KM keep growing environment culture which promoting organization be learnning! 俺: http://zoomquiet.io 许: http://creativecommons.org/licenses/by-sa/2.5/cn/ -- 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.