This prompted me to brush up on @xxx filename nodes, I found the nice chart here: http://leoeditor.com/directives.html
I like to use Leo on existing codebases and I don't want sentinels. The chart would benefit from another column: "Allows edits outside Leo" or "Suitable for existing files" IE: indicating whether rclick "Refresh from disk" is available @auto and @edit are the only ones with this available. On Tue, Feb 3, 2015 at 3:41 PM, Edward K. Ream <[email protected]> wrote: > I discussed this idea briefly in another thread, but it deserves its own > thread. Here are slight edited excerpts from the initial post: > > QQQ > The idea is to run an outline-compare script when the tree in an an @nosent > tree does not exactly match the corresponding external file. This would work > like @shadow with the following differences: > > 1. No duplicate hidden file is written when writing the @nosent node. > 2. [Maybe] The user is always made aware of the differences. > 3. The user is in complete charge of how to resolve ambiguous updates: > changes that fall at the end of one node or the beginning of the next. > 4. [Maybe] The diff algorithm (in your script) will be simpler than the diff > algorithm in the @shadow code. > > Crucially, this scheme preserves both node identities (gnx's) and clone > links because both are stored in @nosent trees in the .leo file. > QQQ > > There are subtle implementation issues involved, but I'm going to ignore > them here. Instead, let's consider that nature of the diff gui panel that > shows the differences between an @nosent tree and the corresponding external > file. > > If all diffs between the @nosent tree and the corresponding external file > can be unambiguously assigned to unique outline nodes, then there is no > absolute need to show the diff gui panel. This "silent" operation is what > @shadow does now. @shadow can get away with this because it *arbitrarily* > assigns text to nodes in ambiguous cases. > > Instead, we might want to make a virtue of (occasional) necessity by > *always* showing the "incoming" changes. By analogy with git, we could even > let the user choose to reject certain changes. > > Naturally, I would like to use as much gui-based diff code as possible, and > there is plenty of code to choose from, starting with meld and other > python-based diffs. However, there is an important complicating factor: > namely assigning code that "straddles" two different nodes. > > Assigning code to one node or the other (or to both nodes!) is a judgment > call. It would take language-specific AI to do a reasonable job. That's not > going to happen. Instead, the user should choose a **dividing line** in > incoming text. Text above the line would go to the preceding node; text > below the line would go to the following node. > > Choosing a dividing line is an entirely new operation, and would require > significant new gui code. Furthermore, the user should be given the > opportunity to reject code above or below the dividing line, while retaining > the other code. > > ===== Summary > > @nosent already offers significantly more than Emacs org mode or VimOutline > mode, but allowing the user to allocate (or reject) incoming changes would > make @nosent a full replacement for @shadow. > > An interface similar to SourceTree's git diff pane would be ideal. However, > the gui must allow the user to set a dividing line in cases where incoming > text might fall at the end of one node, the start of the next node, or > straddle both nodes. This dividing line will significantly complicate the > gui interface. No matter: the user *must* be given the opportunity to > allocate code among nodes. > > As an alternative, we could use something like Leo's existing outline-based > diff reporting mechanism. This would be simpler than a full gui pane, but > imo a git-like diff would be more intuitive. > > Enhanced @nosent operation would be a huge step forward in any environment > in which not everyone uses Leo, that is, almost everywhere :-) The new > @nosent would be more natural than @shadow. If this project is successful, > @shadow might be deprecated or eventually even abandoned. > > As always, your comments are welcome. > > 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 [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. -- 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.
