On Fri, Feb 27, 2009 at 12:26 PM, Ville M. Vainio <[email protected]>wrote:
> > On Fri, Feb 27, 2009 at 7:39 PM, Edward K. Ream <[email protected]> > wrote: > > > Each node would be preceded by a single hint: > > > > #...@node:<gnx>: <headline> > > > > That's *all*. In particular, **indentation of the hint determines > outline > > structure.** > > Aren't you descringing a cleanup of @thin node sentinels here, instead > of adding sentinels to @auto nodes? Yes and no. I spread confusion yesterday in several ways. The problem with the hints proposal is in the details, it in the whole project. Indeed, @auto is what you get when you import the external file and *forbid changes* to the file when writing it back. Thus, even hints are forbidden, and we must live with what I called the "significant problems" in @auto. OTOH, "cleaning up" sentinels in @thin nodes doesn't have appeal. @thin nodes are what you get when external files may contain sentinels. In that case, the form of sentinels is a minor side issue. The present @thin sentinels are close to optimal. Indeed, naive attempts to eliminate various sentinels *will* fail. The take-away message from yesterday is that the task at hand is to fix bugs :-) The problem with both @shadow and @auto is that rearranging nodes can > result in different order in the final file (which annoys > collaborators). Perhaps the default save functions should just warn > about this and abort, requiring the user to explicitly run > save-at-shadow-nodes to really flush the changes to disk? Command to > restore the "correct" node order (w/ the cost of destroying outline > structure) should be provided as well. > > This may seem like safety exaggeration, but it's essential that leo is > deemed "safe", so partial buy-in is possible. > > I have an issue with rearrangement of @thin nodes as well. Sometimes, > when you look at bzr history of leo, you will note *huge* diffs, as > if half of the file changed. This should be minimized to make things > like "bzr annotate" count. Also one of the reasons I don't like things > like sort-siblings to be so easy to execute ;-) Yes, these problem are real. But the solution is to do diffs at the Leo level, not the line-by-line level. There is nothing wrong with Leo operations that cause massive low-level diffs. We simply need to describe the diffs in terms of Leo operations. This might be surprisingly easy. Leo's compare-leo-files shows how easy it is to detect inserted, deleted, moved and changed nodes. Converting this to a stand-alone diff, applicable either to .leo files or files derived from .leo files, should be straightforward. Edward P.S. Naturally, I was disappointed in the failure of the unified @file scheme. For several hours yesterday I considered some wild schemes. For instance, could we eliminate external files completely? Possible in Python, perhaps, by messing with Python imports :-) And similar creative-born-of-desperation schemes...But there truly seems to be no way around the fact that external files *must* contain all the information needed to recreate the corresponding outline. If sentinels are allowed, we get @thin; if not, @auto. 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 -~----------~----~----~----~------~----~------~--~---
