Exciting stuff. On Sun, Jul 6, 2008 at 11:30 AM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > > 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.
Sort of like the freedesktop thumbnails standard. http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/index.html http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/thumbsave.html When an image file is opened (by compliant apps), a file is created in the ~/.thumbnails tree. This convention of using 'companion' files has been proven to be very effective. > > 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: Note that Bazaar was built from the get-go with the intention of being embedded in applications - from http://bazaar-vcs.org ============================================================= Embeddable. A key design feature of Bazaar is support from the ground up for pluggable storage formats. One size does not fit all, particularly when new application delivery platforms - like the OLPC, iPod and Amazon's S3 - have different characteristics to traditional filesystems. If you want intelligent version control embedded into your application or content management system, Bazaar has the architecture you need. ============================================================= You might want to consider using the bzr code to handle versioning. If this code was available to Leo, incorporating additional version based capability would be easier. > > 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 -~----------~----~----~----~------~----~------~--~---
