On Jan 12, 10:09 pm, Sascha <[email protected]> wrote: > 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. > 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. > 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. > 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? > 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. I believe your proposal might create similar dangers. > 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. > 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. > @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. > 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: 1. @shadow creates significant difficulties in a cooperative environment. Your proposal might make things even worse. 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. > In pratice this would mean, there would be no necessity to explain > several complex file handling options, and even better no reason to > explain or even talk about sentinels! Yes, it would be nice, but it doesn't look like it will happen. > Additionally this would mean, that leo would behave like every other > editor to outside files, making the whole node structure handling > transparent. You can get this now with @auto or @shadow, depending on your situation. > I think that this would make leo way more friendly and attractive to new > users. I don't believe these issues will deter new users significantly. New users most likely struggle to understand the Leo world view. I was going to say that Leo's introduction no longer mentions sentinels, but I see that I haven't updated Leo's tutorial from leoDocs.leo. I'll do that today. > So let's see what we get this way. Sorry, but I'm not convinced. Edward
-- 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.
