Hi, for starters this is not a newbie question. I have been using leo for more than 6 years (starting with my diploma thesis using python and latex and now as a C++ developer) and I think that I know about most differences of file nodes. Despite (or because) of this I recently got the impression that the currently available options are unnecessarily complex, and could be drastically simplified. 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. I think the answer was roughly, that there appears to be no critical problem. This question was a little off topic there, but I started thinking about it. 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. While it might not be obvious, this separation causes some signifiant 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). One could circumvent this by adding the private files also to the repository, but this is not always feasible. 2. Private files are not used directly, thus there is a high tendency to forget about them and then eventually remove them unintentionally. F.e. if a local vcs checkout is to messed up, it is not to uncommon, to remove all files and dirs and do a new clean checkout. This way I rendered a signficant part of a huge .leo file useless. 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. 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. Furthermore if we imagine that we have those private files integrated, this casts a totally new view on the question given in the title! So let's see what differences would we have: @file nodes then behave essentially like @shadow, with the exception, that they yield sentinels. So, when can we draw an advantage from this? If the derived files are edited directly one has better control where new lines might turn up in leo. But for whom is this really relevant? Leo users will usually (and in fact are encouraged to) edit via leo, and can probably live with minor @shadow glitches most of the time, if direct editing is required. 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. @thin nodes (if I remember correctly) were actually intended to make sentinels more vcs compatible and less annoying to human readers. But ofcourse without sentinels both issues become obsolete, thus the main difference to @shadow is probably, that the file contents are not duplicated in .leo. But is this really a significant advantage in common usage scenarios ? @nosent are basically @shadow nodes, that are write only, so no signficant advantage either. 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. 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!!! Additionally this would mean, that leo would behave like every other editor to outside files, making the whole node structure handling transparent. I think that this would make leo way more friendly and attractive to new users. Effectively we could still provide @file, @thin, @nosent functionality, buried somewhere in the deepest corner of the documentation, together with the warning, that if one want's to use these, one has to pay a price (i.e. sentinels...). Ofcourse as Joel would put it, the abstraction, that leo can transparently maintain associations between custom informations and blocks of text in a file exposed to arbitrary changes, will leak. I.e. pulling in changed files, will sometimes result in broken or imperfect associations. But I think it is easy to illustrate in the docs, that this cannot always work. Probably easier, then expaining sentinels and all its interactions with file nodes. So let's see what we get this way. Leo allows us to connect arbitrary informations to blocks of text, in the simplest case this can be implicit structural information (f.e. views) but we might also add arbitray text information. This information is stored without changing the original input, but despite of this the connection can survive nearly arbitrary (and arbitrary many) changes, as long as individual changes are "small" enough (f.e. this is quite common in vcs based development). So now think about this, how would you add such functionality to another editor? - Bookmark a line nr => will break if lines are added externally - Hash a text block (or just start or end) => will break if hashed text gets changed. Essentially this poses a very difficult (and not always solvable) problem. So far most IDEs cope with this by providing variuous mechanisms (f.e. bookmarks, automatic marker extraction, class based views, complex goto mechanisms) which all provide partial solutions with specific disadvantages. But effectively no single solution can compete with leo's capabilities in this respect. And of course leo can do all this with one universal approach!! Even better I think leos approach (@shadow + clone) probably provides the best possible solution (or at least algorithmic concept). Thus previously leo only provided this cool concept of clones, but required a significant toll for this feature, which is (and probably always will be) a show stopper in many if not most teamwork scenarios. When the @shadow plugin first appeared, I immediately jumped on it, because it allowed me to use leo at work. Simply put @shadow provides the glue logic to resolve the toll issue. Thus what remains to be done, is to make this the default solution and make this solution as transparent as it can be. Ofcourse coming from the current situation and taking the immanent problems of @shadow mechanics into account, this approach might appear rather radical. But basically we can estimate it's real impact based on a few core questions: 1. Who does use @file or @thin in a team together with non-leo users. 2. Who does use @file or @thin and regularly performs significant changes outside of leo. 3. Who does use @file or @thin in another way that does not interact well with @shadow. 4. Who does avoid @shadow only due to some minor implementation / usage glitches. The last point targets the inconveniences resulting from private files as well as other solvable problems / bugs. F.e. it seems to be easy to inadvertently break clones in context with non-perfect imports (which by itself also cause significant inconveniences). All together I would expect that only very few users do use leo as described in 1-3, but maybe this is just to much based on my personal way of using leo. Still I think at least superficially simplifying or unifyino file nodes, would make leo more user friendly. Thus to finally conclude this post, I think private files should be pulled into .leo. Additionally, unless I have completely missed an important usage scenario for non-shadow files, we should target at making @shadow the default. But for now I have the impression, that @shadow is not reliable enough to make it immediately the default. regards Sascha P.s. Breaking clones is not a minor issue! In fact using vcs I can easily recover from inadvertent file changes, but I know NO easy to relink broken clones at all. Given that creating complex views can consume very much time, breaking clones is a very serious issue! Thui @shadow mechanics should be as robust as possible with respect to clones. P.p.s. @first (and probably others as well) becomes useless in a unified @file world.
-- 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.
