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.
