On Thursday 26 February 2009 12:56 pm, Edward K. Ream wrote: QQQ Oh, I wish there were a way to make .leo files into "project" files that would eliminate sentinels completely. But 15 years of wishing hasn't produced a way that could possibly work. QQQ
Standing in the shower yesterday after a workout I saw that this dream might finally be within reach. Indeed, a few easy improvements to @shadow could create the last piece of the puzzle. Let us assume that all bugs in @shadow can be removed, so that @shadow will work as reliably as @thin and @file. I believe this is a reasonable assumption. Absent reliability concerns, the present objection to using @shadow for *all* files is that @shadow requires private files. For some people, these files are just as objectionable as sentinels. The Aha is simple: to make @shadow work, we don't need private *files*, we need private *data*. We could put all the data in a **Leo file database**. Keys would be the path to the *public* external files, values would be the *contents* of what used to be the corresponding *private* files. For the purposes of the Aha, it doesn't matter where the Leo file db resides. The options include in .leo files, in .leo.db files, in per- user databases, or a single per-machine db. This Aha appears to open the door to a far simpler world: 1. @shadow would need no additional files except the Leo file db itself, which is harmless. 2. Sentinels would still exist, but they would be completely out of sight. There would be no need to optimize them, and **diffs to sentinels would no longer matter**. Thus, sentinels could contain **whatever information is needed**, including non-essential information like expansion state or marks. There would be no need for the so-called "hidden machinery" that presently resides in <v> elements for @thin nodes. So, unless I am missing something crucial, it should now be possible to replace all @<file> directives with a single directive, say @file. This would be the **unified @file world**. The benefits to Leo's users would be enormous, especially for newbies. No need to describe 9 ways of doing what any ordinary editor can do naturally. No need to describe sentinels: they would be hidden machinery completely out of sight. The benefits to Leo itself would also be significant. No need to support all kinds of read/write code and corresponding Leo commands. Edward P.S. Important: I can't say for sure that this Aha will survive further scrutiny. I may be forgetting something crucial. But just now the unified @file world looks feasible. 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 -~----------~----~----~----~------~----~------~--~---
