Not paying more attention to Bernhard's mod_shadow plugin is probably the biggest mistake I have ever made with Leo. I rejected the idea far too quickly: any minor problems with it can easily be solved.
First, let me summarize what the mod_shadow (shadow) plugin does: 1. The shadow plugin writes "shadowed" derived files in two forms: a "public" form without sentinels, and a "private", form with sentinels. The shadow plugin writes private files to a leo-shadow folder. At present, a script button converts a non-shadowed file to a shadowed file. We could make the process of shadowing files more automatic. For example, @shadow-thin and @shadow-file might create shadowed private files in @thin or @file formats respectively. 2. Typically, only the *public* files get committed to a repository. This makes Leo available even in shops where Leo sentinels are considered odious. I am astounded that I haven't paid more attention to this plugin. 3. Suppose that a public file (without sentinels) changes as the result of a bzr merge. When Leo reads the changed *public* file, the shadow plugin can *deduce* what changes were made by comparing the changed public file and the (still unchanged) private file. This idea is a stroke of genius. Furthermore, the implementation is relatively straightforward. The shadow plugin does the following: A. Removes sentinels from the private file, thereby recreating the original *public* file. B. Uses Python's difflib.Differ class to compute line-by-line diffs between the original and changed public files. C. Uses the line-oriented diffs to update the *private* file. D. Uses the updated private file (containing sentinels) to load the derived file. My concerns were with step C. There is a boundary problem. Suppose a changed line appears on the boundary of adjacent nodes A and B. Should the line be inserted at the end of node A, or at the start of node B? At the time, I suppose I wanted absolute answers the this question. But that is extremely foolish, for several reasons: 1. The shadow plugin could warn that there is an ambiguity, and let the user decide. The easy way to do this is to guess the answer, then clone the ambiguous nodes so they can be presented to the user to change if need be. 2. Furthermore, indentation often (usually?) makes clear in which node to insert the new line. If A and B have the same starting indentation and the inserted line has a larger indentation, we should prefer to put the node at the end of A rather than the start of B. Other heuristics could be used too. But the main point is, **the ambiguity isn't serious** as long as the user is informed and can easily override incorrect guesses in step C. Conclusions I am convinced that the shadow plugin can be made to work extremely well. When it does, Leo sentinels will no longer a barrier to adopting Leo. Thus, almost any amount of work is justified in making the shadow plugin work as smoothly as possible. This work has the highest priority until it is completed. Edward P.S. I must merge the redraw2 and forth branches before beginning real work on the shadow branch. As I'll discuss in another thread, the redraw2 branch should be complete in a day or so. EKR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
