Sorry for the late answer, but I did not have enough time recently to immediately answer. On the upside I found the thread about unified nodes, and read it. Additionally while thinking about your arguments I had a new idea, that might give a totally new perspective on file nodes and sentinels. The details are at the end of this post in the appropriate context.
> > The basic idea resulted from a post here some time ago. Someone asked, > > wether it would be possible to pull the privat @shadow files into > > the .leo file. > > Many thanks for these interesting ideas. I have played around with > many such ideas in the past, but never this one. > > I don't believe any unification is possible. If it were, it would be > a truly amazing development. I regard such a development as highly > unlikely. > > The basic stumbling block is that duplicating data creates > complications. Such complications, at what would be the heart of Leo, > will always be bad engineering. It won't "just work". Ever. >From a theoretical point of view this is a rather good argument, but from my experience I see no way to make use of clones in leo in any professional environment unless I use @shadow. So either I missed some ways of utilizing leo in a cooperative environment or @shadow nodes will become the defacto standard for using leo in such situations anyway. On the other hand external changes are probably way less complex in non cooperative envs, thus are there any common real use cases where @thin can be used to avoid such complications? > > As far as I know, the fact that the private files are separated from the > > leo files is probably owed to its origin as a plugin. > > Separating private and public files has significant advantages. For > starters, it keeps the .leo file both small and "clean". By clean, I > mean that .leo files are essential project files the should *not* > contain significant file-related data. Well from this point of view @file seems to be a bit deprecated, but it is still the standard way to import any file. Of course keeping leo files thin seems a good idea, but this target could also be achieved by shifting some data (f.e. private files) to another file. This idea was also part of the unified node aha and seems to have been abandoned together with it, despite this I think it is a very useful idea for itself alone, because it would probably solve the below issues. > > While it might not be obvious, this separation causes some significant > > inconveniences if not problems: > > > 1. If you check out a new branch from a vcs, you have to manually, > > recursively copy all private files (in addition to the leo file). > > This problem won't be solved by putting file data in .leo files. The > fundamental problems with vcs arises from the duplication of data, not > the particular way the data are duplicated. I admit that having duplicated data is essentially ugly, but having no reliable way to solve the above problem, is a much worse problem. Besides I have no real problem with vcs, the point is, there is no feasible way to locate and copy the private files, the fact that private files duplicate data from vcs is not the problem I am addressing here. > > 2. Private files are not used directly, thus there is a high tendency to > > forget about them and then eventually remove them unintentionally. > > The same problem arises if the data are stored in a (private) .leo > file. Suppose you throw away a branch. Did you remember to keep your > private .leo file? Essentially it is much easier to remember one (or two) files than to remember all files I might have shadowed during the last years. Even worse I can create files anywhere in a file system from within one leo file, thus there is nearly no way to figure which file belongs to which .leo. So unless I can do full backups of my file system (which is not possible at my job and often not feasible in other cases) the only reliable way to locate all external files (and specifically private files) is via a script from within leo. On the other hand, I am usually much more aware of my leo files (because I use them directly) and even better, I can keep them out of my svn subtree, if I want. Furthermore I just realize from the above description, that it is probably dangerous to shadow the same file from two or more .leo files, because all leo files would use one "common" private file. Although this is probably a strange scenario, it would be no problem, if every leo file uses its own location for storing private files. > > 3. If you want to move a leo file, essentially you have to locate all > > private files and move them accordingly. > > 4. Generally there is no automatic way to locate and backup all private > > files. > > The worst mistake I ever made was creating the notion of "backup" .leo > files. > Bad copies of data are actively dangerous. This is really a great aphorism! >I believe your > proposal might create similar dangers. Well my proposal might incur some dangers, but clustering all private files in one file (or leo itself) does not hint at backup at all. Still it would enable me to make better backups, because at the moment there exists no solution at all and having no possibility to do backups is the worst case scenario. Furthermore it cannot really prevent users from trying to make backups (f.e. I have created a script for this purpose) it just increases the probability of bad backups. > > On the other hand, I see no real significant disadvantage in pulling > > private files into .leo aside of an increase in the .leo file size. > > I disagree. .leo files should remain project files. > > > @file nodes then behave essentially like @shadow, with the exception, > > that they yield sentinels. > > Let's get clear about terminology. The *old* @file nodes were > actively dangerous in cooperative environments. The *new* @file nodes > are the same as @thin nodes. In this kind of discussion, I prefer to > use the term @thin node. Looks like I have not looked at sentinels in detail for a long time, sorry if I mixed something up. > > On the other hand non leo users will probably not like sentinels at all, > > thus for those non-users surely @shadow is the best, if not the only > > solution. > > @auto is another option, arguably better in (some) cooperative > environments. Well @auto essentially yields, what IDEs usually call classviews. If I cannot create my personal views of data, I essentially loose the one feature that sets leo apart from every other editor or IDE. > > @thin nodes (if I remember correctly) were actually intended to make > > sentinels more vcs compatible and less annoying to human readers. > > Not really. The essence of @thin nodes is that put *all* essential > information in the external file. There is *no* duplication of > information, so nothing can possibly get out of sync. �...@thin nodes > were so named because they made the .leo file "thin". Actually, @file > nodes had simpler sentinels, but that was hardly a virtue. > > > @nosent are basically @shadow nodes, that are write only, so no > > signficant advantage either. > > Yes and no. True, @shadow nodes allow the outline to be updated when > the public file is updated externally. But @shadow nodes are twice as > slow to read and write. It's surprising that this should still be an > issue, but it is. I admit that opening my current main leo file takes a very long time due to more than 300 shadowed files. But I consider this a price I have to pay, falling back to @thin might help, but is this really an option in most of such cases? At least I would guess that projects of this size tend to be of cooperative nature, thus everything other then @shadow will often be impossible (due to sentinels) or result in loss of the most important feature. > > So with respect to making leo a mainstream editor, at least for me this > > raises the question, whether leo would be better of, if we remove @file, > > @thin, @nosent and instead rename @shadow to @file. > > That was the dream I had several weeks ago. The conclusions then > were: The unified file thread I found dates back to febr 2009, hope that was the right one. > 1. @shadow creates significant difficulties in a cooperative > environment. Your proposal might make things even worse. As stated above I have read this thread now. Interestingly in this thread you grouped file nodes into two categories: - collaborative - non-collaborative The point is, that you consider @shadow as non-collaborative, due to it's fundamental inability to provide enough information for reliable updates from external changes. While this is obviously true and a useful distinction, it stands in contrast to what I consider the common use-case for @shadow. To be more precise the most important usecase for @shadow are cooperative environments, in which not everybody uses leo. And even worse, due to the hen or egg problem ( one cannot use @thin unless leo is the standard editor, but @thin prevents it becoming the standard), I would guess that this is and probably will remain by far the most common cooperative usecase for leo. Your conclusion in the unified file node thread was: "@shadow is *not* a collaborative @<file> type, so it can not be made the basis of any unified @file scheme" I think this argument is misleading, since @shadow can be used (and is probably the only choice in most cases) in collaborative envs. The "only" drawback is, that in case of rearranged textblocks manual recovery is necessary (which is not yet supported in anyway as far as I know?) even if the change was caused by another leo user. On the other hand the thing that would be really useful for leo user collaboration, is some way to exchange (i.e. import and export) views (collections of nodes including clones and internal nodes). So maybe the central target for collaboration should be, to provide annotation files (providing views) together with (possibly changed) normal external files. This could provide a very promising workflow for collaboration usecases. If I want to connect to a leo based workflow, there is no need for some sort of skeleton .leo file. Instead I could just grab one or more exported views (either from some sort of repository or freshly exported from colleagues) and import them into my empty .leo file (this way I could even incrementally expand my view of the complete project, by incrementally adding more an more views). In this case the imported views would trigger two things: 1. One or more view nodes (probably containing lots of (cloned) subnodes) will be added to the current .leo. 2. Missing files will be automatically imported. The second point will also provide the possibility, to give every view node an ID that will be valid across .leo files! If such a connection is setup once, it should be easy to propagate changes (f.e. of content or position) regarding such nodes from one .leo to any other one which has been connected once via such an imported view. Essentially this propagation data could probably look very similar to private files and might be just a simplified case of exported view information. Thus leo users could exchange leo relevant additional informations separate from the actual data files, thus allowing those to be sentinel free. Furthermore for many cases it is probably no problem, to store some additional files in vcs, thereby enabling automatic view exchanges. All in all this would provide a sentinel free work flow even for a heterogenous non-leo / leo-users collaboration. Ofcourse the non-leo users could still break leo views, but this issue is essentially unsolveable. The critical part of such an approach is probably handling collisions when importing views. F.e. given a node (connected via a common import) with content l1 l2 l3 l4 I might decide to extract a new node consisting of l1 and l2. Simultaneously a colleague might have the idea to reorganize this node as: l1 -------- l2 l3 --------- l4 Importing such a view will yield a collision, due to overlapping views, and such a collision can only be resolved by the user. Of course such a situation is also a problem if @thin files are exchanged directly instead of views, so I have no Idea what currently will happen in such a scenario. All in all this change of perspective turns the current situation upside down, i.e. instead of requiring every user to cope with sentinels and figure the optimal file type, just to ensure that a few groups of lucky leo only users can collaborate, we could ban sentinels completely and just require, that those leo users who do collaborate export additional infos for this purpose. > 2. Leo's sentinels *do not* prevent Leo from being a mainstream > editor. There are plenty of ways to use Leo that do not depend on > sentinels. Well is their any way to use clones in a cooperative environment without using @shadow ? Or if one cannot use clones, what does set leo apart from other editors or IDEs? For my taste clones and views are not just "convenience", instead they simplify complex problems, by allowing to trim down the visible information to the minimum necessary. Essentially this allows to push the invisible border of problems that are to complex to handle (or maybe just to expensive to handle due to their complexity) significantly ahead. Personally I consider complexity to be the central problem of current and future IT development and especially of programming, thus everything that significantly simplifies handling complex problems on a general level is waymore then convenience. And ofcourse Leo's clone concept is an important advancement in that sense. Thus disabling or reducing the scope of clones, is a dramatic and unreplaceable loss, i.e. if sentinels are impossible nothing can compete against shadow files. So while it is totally irrelevant for me whether file nodes will be unified or not, I'd really really like to have the option to pull all private files into one data file!! Additionally I consider some way to exchange views to be a real killer feature and a feature ,I have long been looking for, even though this will probably be of no practical use for me, since I have no other leo users, I could exchange views with. Ofcourse I cannot completely guarantee that a sensible view export is algorithmically possible, but at least it does not look so at the moment. Furthermore the shadow mechanism has still several problems that should probably be addressed. At the moment the following problems spring to my mind. 1. reading of @shadow nodes often leads to decloned nodes, altough nothing significant happened in the src files. 2. minor changes (f.e. adding a missing ; ) are sometimes ignored upon saves and there seems to be no direct way to force a write in such cases. 3. there is no easy way to bulk import a set of files to @shadow. 4. non-perfect imports are generally problematic, f.e. bulk imports can lead to lots of @ignores and in context of vcs the whitespace changes can lead to many pseudo changes. 5. After shadowing I sometimes see underindented lines appearing, that cannot be easily fixed. This is even more irritating since I thought that it is problematic to impossible to generate underindented lines from within leo. regards Sascha -- 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.
