Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
On Sat, Jan 14, 2012 at 9:13 AM, HansBKK hans...@gmail.com wrote: I honestly think the lack of a clear statement on this topic in the docs dangerous for relative newcomers to Leo and threatens its acceptance as a data-safe working environment. The post All about clone conflicts is my response. Imo, the only thing dangerous about Leo is deliberately ignoring Leo's warnings. IMO a better solution would be some type of mechanism in Leo that allowed the user to specify explicitly which branch of the outline should be considered the canonical one. As I said in All about clone conflicts, this is never going to happen. Leo's read code is already too complex. Trying to guess what the user wants will make it much more complex, and therefore less reliable and more difficult to explain. Put it another way, there *already is* a way to specify explicitly which branch of the outline is the canonical branch: it's the last branch in the outline that contains the clone. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
From Terry's related thread herehttps://groups.google.com/forum/#%21topic/leo-editor/4vazxXwWy8E/discussion distinction between source files and output, or built, files. I believe that is in effect what the safe-cloning rules, and the procedures they imply which we've outlined in this thread, and also here, https://groups.google.com/forum/#%21topic/leo-editor/XaDeRQIVSyw/discussionare doing already. @shadow/thin = input and output @nosent/asis = output only Once could say this method is relatively explicit IMO the other two - location in the outline on the one hand, and read order priority of @all vs sections/@others on the other - are less so. The fact that these procedures rely on the user understanding a relatively complex set of rules IMO works against data safety. Solutions based on these can easily become fragile due to human limitations, e.g. memory/brain farts; for myself, it's all too easy to forget *why* I put that branch at the bottom of my outline, and later on move it up higher by mistake. I completely understand and accept that additional mechanisms for preventing data loss due to cross-file cloning aren't likely to appear anytime soon. However in the meantime I still maintain that this is still an important usability issue which requires addressing in a more visible and permanent location. I would be happy to put some more work into summarizing the points outlined in these threads into a next draft, and then another developer could technical-edit it and incorporate it into the official documentation. -- You received this message because you are subscribed to the Google Groups leo-editor group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/F3oFSbYotJQJ. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
On Sat, Jan 14, 2012 at 1:45 AM, HansBKK hans...@gmail.com wrote: I honestly think the lack of a clear statement on this topic in the docs is dangerous for relative newcomers to Leo and threatens its acceptance as a data-safe working environment. Yes, some more words in the docs would be helpful, but the bottom line is that we can't assume that people will read documentation. There is no substitute for being aware of the multiple-update problem. I think it's fair to assume that programmers are aware of that problem. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
On Saturday, January 14, 2012 7:20:23 PM UTC+7, Edward K. Ream wrote: On Sat, Jan 14, 2012 at 1:45 AM, HansBKK han...@gmail.com wrote: I honestly think the lack of a clear statement on this topic in the docs is dangerous for relative newcomers to Leo and threatens its acceptance as a data-safe working environment. Yes, some more words in the docs would be helpful, but the bottom line is that we can't assume that people will read documentation. There is no substitute for being aware of the multiple-update problem. I think it's fair to assume that programmers are aware of that problem. Edward In this other related concurrent thread../d/msg/leo-editor/CyqaY1HS4eY/3rhy_IPW1kMJyou also state: What we are seeing is the boundary between reasonable and unreasonable uses of cross-file clones. That boundary is not sharp: whether cross-file clones work depend on the overall workflow of the people using them. I would argue we should at least attempt to spell out for Leo users (programmers or no) what those boundaries are, even if only by giving some examples of ones that should be OK vs those that are clearly not. This would form the basis for more precise understanding growing over time, and perhaps more elegant ways for Leo to guide the user to avoid problems. IMO a better solution would be some type of mechanism in Leo that allowed the user to specify explicitly which branch of the outline should be considered the canonical one. An idea you floated in one of those historical threads, I think along these lines, was having some sort of @master directive, which I suppose would direct Leo's read logic to save this for last, no matter the position in the outline or use of @all vs section+others. Another approach might be a warning (or just informational) reminder in the log pane whenever Leo detects a new additional potentially-problematic cross-file clone - IOW one that doesn't follow the safe-SOP rules specified in the docs. Both of these may be too difficult/complex to implement, just tossing ideas out there ATM. . . -- You received this message because you are subscribed to the Google Groups leo-editor group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/XaXQe7daZ_IJ. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
On Fri, 13 Jan 2012 14:27:36 -0800 Matt Wilkie map...@gmail.com wrote: I thought one of the major reasons for clones was to be able to boiler plate common content across many files. Examples might include copyright notices, written by _, code functions that get re-used a lot and so on. Is this an incorrect, or at least inadvisable, use of clones? I think it's a use of clones that forces you to deal with rules about what's safe and what's not safe which are easy to forget or get wrong. This is the same point Edward hit on recently: http://groups.google.com/group/leo-editor/msg/12b9531a9b3025bb Most programming languages have import / include mechanisms for referencing common code. Ditto document generation systems like LaTeX, DocBook, and rst. There are numerous templating systems for handling repetition in HTML and similar outputs. Those are safe, DRY compliant ways of addressing these needs. *But* they all require specific knowledge - by appearing to offer a generic solution to these needs which works for multiple output types (code, HTML, rst, etc.) Leo's clones are very appealing. However I don't think (Edward?) that was what they were designed / intended for. Rather, they're intended to provide views / collections / bookmarks of currently interesting parts of files. Personally I think UNLs are a safer way of doing that, but clones do it very nicely, as long as you don't break the rules. That's where I think these issues about what clones do is coming from. Perhaps Leo could offer some kind of generic solution by providing some sort of templating system which could be applied to any text file output. But it would still require a distinction between source files and output, or built, files. Kind of cross-file section references. Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross file clones (was Re: My thoughts which you are free to ignore :-))
On Saturday, January 14, 2012 5:27:36 AM UTC+7, Matt Wilkie wrote: P.S. In your particular situation, I would suggest, if at all possible, that you make complete external files, rather than clones, to be the units of sharing. That way there is only one copy of the data, so if you change that data outside of Leo all clones of (parts of) that data will be in synch the next time you open Leo. Oh. I thought one of the major reasons for clones was to be able to boiler plate common content across many files. Examples might include copyright notices, written by _, code functions that get re-used a lot and so on. Is this an incorrect, or at least inadvisable, use of clones? I honestly think the lack of a clear statement on this topic in the docs is dangerous for relative newcomers to Leo and threatens its acceptance as a data-safe working environment. I would **really** like for us to work together here to create a starting point for documenting this issue, so I've compiled a summary from my past notes as a general starting point Note that all the below statements are based on my limited knowledge and my reading of some rather old threads, those with more knowledge **please** do correct any inaccuracies. Note also these statements should be taken to apply to recent versions of Leo only, and I've ordered them by simplicity/safety/my certainty: It's safe to allow clones to appear in multiple @ file branches as long as you make sure that one of the following is true - you are doing all your editing within Leo - you make sure that any given clone only appears in one @ file that imports (reads) changes made outside Leo - note my SOP to ensure this is to - use a designated master @thin or @shadow file to bring in any external changes - all the other clone instances are @nosent or @asis, therefore export only (and treated as read-only outside Leo) - you take into account the relative priority guidelines outlined by Ed - @all vs (sections+@others) - have the (only one) master location use sections+@others, the other instances must use @all - position in the outline - last @ file read (= lower in the outline) wins - you will get Recovered nodes showing the conflict/differences - in-Leo-only clones (not included in an @ file ) will always lose to imported changes I'm pretty sure there isn't a safe way to clone the @ file node itself to different paths Including a given clone multiple times within a single @ file tree is fine, but it only actually gets written more than once when using sections, not via multiple @others. References: https://groups.google.com/d/msg/leo-editor/j7BOnRqCFcI/tyE_SvNwfHMJ https://groups.google.com/forum/#!topic/leo-editor/Z6KJhGFtCck/discussion Pretty old, not sure how much still applies probably best to *not* revive these zombies but continue the discussion here, using the above summary as a starting point: https://groups.google.com/forum/#!topic/leo-editor/-DFuSJwHP2E/discussion https://groups.google.com/d/msg/leo-editor/wulhmob-Ne4/k_lyAWIQPLQJ -- You received this message because you are subscribed to the Google Groups leo-editor group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/dx5rsOwQ1L8J. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
Why not? Not sure, perhaps I just need to change my working style a bit. I have a lot of information that I keep outside the @file nodes. Documentation for example, which is not directly linked with the code. I see you yourself are sharing information via Leo files, that are not just reference files (the LeoDocs.Leo file for example - although this is probably a file your are mostly editing alone). But one could put all the content into @file nodes, at the disadvantage of having multiple files instead of having everything nicely in one single Leo file. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Tue, Jul 12, 2011 at 5:57 AM, Josef joe...@gmx.net wrote: Why not? Not sure, perhaps I just need to change my working style a bit. I have a lot of information that I keep outside the @file nodes. Documentation for example, which is not directly linked with the code. I see you yourself are sharing information via Leo files, that are not just reference files (the LeoDocs.Leo file for example - although this is probably a file your are mostly editing alone). Yes. The general idea is to keep the .leo file constant, except for infrequent updates. It remains to be seen how easy sharing files like leoNotes.txt would actually be. As you say, I am typically the only one that touches this file. However, bzr should be able to handle updates to this file... But one could put all the content into @file nodes, at the disadvantage of having multiple files instead of having everything nicely in one single Leo file. I think this is the only way in shared environments. You can also use @auto instead of @file, but then you lose the ability to clone nodes persistently. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Thu, Jul 7, 2011 at 12:03 PM, Josef joe...@gmx.net wrote: In my company, the others don't mind the sentinels, but since I use leo as a storage for data which *inherently* needs or benefits from a tree representation, this cannot be conveyed to others via the @file nodes alone, but I must start sharing data with others via Leo files (and the colleagues are excited about Leo). It is not always convenient to do this only with reference files. Why not? Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Jul 6, 11:37 am, Terry Brown terry_n_br...@yahoo.com wrote: On Wed, 6 Jul 2011 10:46:17 -0500 Edward K. Ream edream...@gmail.com wrote: Hmm. The docstring for the bookmarks plugin says that the plugin has been superseded by the newly-improved handling of @url nodes. Is this true? Not entirely. You put that there, by the way :-) Haha. It's gone now at rev 4420. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
There is jinjarender.py plugin that might be interesting. Check list archives Largo84 larg...@gmail.com wrote: Checked out genshi and django, they remind me of something similar when I was considering using a CMS for my web site (they're called template variables there, they serve the same function of substituting repeatable text blocks). Conceptually, they make sense but I wouldn't even know where to get started in using them in Leo, especially for non-html document tasks. Consider a text block that resides in some node with headline, say Fragment Info , in TextFragment.leo file. Suppose I'm working in SomeOtherFile.leo and want to reference that text block such that if Fragment Info is changed *and* SomeOtherFile.leo is updated, it updates every instance of that referenced text block. It seems like it should be a fairly straightforward task. I see that clones are not the way to accomplish this. Is there any capability currently in Leo (or a plugin) that can do this? Rob.. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
You won't have conflicts in the .leo files provided that you use reference .leo files, as we do in the Leo project itself. See the FAQ:http://webpages.charter.net/edreamleo/FAQ.html#leo-in-shared-environm... So, I cannot share my non-reference files - that is a serious limitation. It is these non-reference Leo files, where the interesting stuff is. I need to share these. I want my colleagues to be able to see my notes, and the tree. I also keep some data in Leo files, which I cannot easily move to @file nodes. I also want my colleagues to be able to use my scripts, which are embedded in Leo files. As an interim solution I will lock any (non-reference) Leo files in SVN, thereby prohibiting any parallel work on them, but this is of course not entirely satisfying. P.S.: the bzr repository link in the FAQ link above seems broken. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
I just had a look at leoGuiPluginsRef.leo and it contains a lot more than just @file nodes: @chapters, @settings, commented out buttons etc. so, is the statement: Ref files should contain nothing but @file, @auto and @shadow nodes the whole truth? I also used (successfully) clones in my leo files, where I simply cloned the *whole* @file node. When writing such nodes, I get warnings that the node has not changed (of course, the second write to the cloned file is the same as the first), but otherwise it works - but I was the only one working on the Leo file, and one should never clone part of an @file node. A cloned part of an @file node should only be stored inside a single @file node, and nowhere else, but that is of course not simple to enforce (just imagine, someone puts the same clone inside two different @file nodes). For the same reason, hard links cannot span multiple volumes. I think, the best would be if Leo would not allow clones beneath @file nodes. When starting to share Leo files it will be difficult to explain all these limitations to new users. They should be able to do anything Leo allows them to do, without running into merging problems. Perhaps this could be solved with a merge tool for Leo files? - Josef On Jul 7, 10:07 am, Josef joe...@gmx.net wrote: You won't have conflicts in the .leo files provided that you use reference .leo files, as we do in the Leo project itself. See the FAQ:http://webpages.charter.net/edreamleo/FAQ.html#leo-in-shared-environm... So, I cannot share my non-reference files - that is a serious limitation. It is these non-reference Leo files, where the interesting stuff is. I need to share these. I want my colleagues to be able to see my notes, and the tree. I also keep some data in Leo files, which I cannot easily move to @file nodes. I also want my colleagues to be able to use my scripts, which are embedded in Leo files. As an interim solution I will lock any (non-reference) Leo files in SVN, thereby prohibiting any parallel work on them, but this is of course not entirely satisfying. P.S.: the bzr repository link in the FAQ link above seems broken. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Jul 6, 8:10 am, Edward K. Ream edream...@gmail.com wrote: You won't have conflicts in the .leo files provided that you use reference .leo files, as we do in the Leo project itself. See the FAQ:http://webpages.charter.net/edreamleo/FAQ.html#leo-in-shared-environm... This is perhaps a too-glib response. In some sense Leo's real major failing is that it makes collaboration just a bit harder that it otherwise would be. This effect is masked a bit here because all of Leo's developers use Leo and bzr. The acid test is whether Leo can be used by some, but not all, developers on a significant project. At present, the best that can be done in such situations is to use @auto or (maybe) @shadow for the group's files. This is far from optimal because clones don't survive in @auto. Partly as a result of your question I have been thinking, once again, of re-imagining what Leo is. I'll be saying more about this in another post. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Jul 7, 10:27 am, Edward K. Ream edream...@gmail.com wrote: The acid test is whether Leo can be used by some, but not all, developers on a significant project. At present, the best that can be done in such situations is to use @auto or (maybe) @shadow for the group's files. This is far from optimal because clones don't survive in @auto. One can imagine situations in which the developers that don't use Leo are not hostile to having Leo's sentinels in the group's files. In this case, @file can be used and there are no problems. This case won't always happen, but it might be more common now that Leo's sentinels are so similar to Emacs org mode. However, in contrast to org-mode lines, Leo's sentinels contain the somewhat unsightly gnx's. In any event, not all projects would necessarily tolerate even plain org-mode lines, so the larger issues must, imo, still be confronted. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
One can imagine situations in which the developers that don't use Leo are not hostile to having Leo's sentinels in the group's files. In this case, @file can be used and there are no problems. In my company, the others don't mind the sentinels, but since I use leo as a storage for data which *inherently* needs or benefits from a tree representation, this cannot be conveyed to others via the @file nodes alone, but I must start sharing data with others via Leo files (and the colleagues are excited about Leo). It is not always convenient to do this only with reference files. Unfortunately, that is exactly where the problems start, because I understand from the recent conversation here, that generic Leo files do not work well with automatic (text based) merging. - Josef -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
That worries me. So far I have been the only one working with Leo in my company, but lately others have started to pick up Leo as well. As the main cooperation tool we use SVN, so I check in my Leo files as well. Now either we are all going to work with the same Leo files, which will probably lead to endless conflicts as everybody is then working simultaneously on the same files, or we will end up having multiple different Leo files pointing to the same set of files. I understand that this will work fine as long as we are not using clones, but then we loose one of the best features of Leo! - Josef On Jul 5, 10:44 pm, Edward K. Ream edream...@gmail.com wrote: On Tue, Jul 5, 2011 at 2:47 PM, Largo84 larg...@gmail.com wrote: Sorry if the answer is obvious, it's not to me. Should I avoid cloned nodes in @files that are referenced in different .leo files? Yes, you should avoid such clones, for the reasons you imply. Imo, every piece of data, of whatever kind, should be owned by at most one .leo file. If you break the rule you are going to expose yourself to a delayed (and therefore insidious) form of the multiple update problem. Besides being a technical problem, it could also be called a management problem: just as no human manager would willingly share responsibility for any set of code, no two .leo files should reference the same data. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Wed, Jul 6, 2011 at 3:08 AM, Josef joe...@gmx.net wrote: That worries me. So far I have been the only one working with Leo in my company, but lately others have started to pick up Leo as well. As the main cooperation tool we use SVN, so I check in my Leo files as well. Now either we are all going to work with the same Leo files, which will probably lead to endless conflicts as everybody is then working simultaneously on the same files, or we will end up having multiple different Leo files pointing to the same set of files. You won't have conflicts in the .leo files provided that you use reference .leo files, as we do in the Leo project itself. See the FAQ: http://webpages.charter.net/edreamleo/FAQ.html#leo-in-shared-environments Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Wed, Jul 6, 2011 at 9:16 AM, Terry Brown terry_n_br...@yahoo.com wrote: On Wed, 6 Jul 2011 01:08:02 -0700 (PDT) Josef joe...@gmx.net wrote: I understand that this will work fine as long as we are not using clones, but then we loose one of the best features of Leo! That depends what you use clones for. If you use them for collecting a short list of nodes of current interest from a larger tree, you can get basically the same effect from the bookmarks.py and quickMove.py plugins. It's time for me to start using these plugins myself. It will be interesting to get a feel for a world without clones. It might suggest future directions. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Wed, 6 Jul 2011 10:46:17 -0500 Edward K. Ream edream...@gmail.com wrote: Hmm. The docstring for the bookmarks plugin says that the plugin has been superseded by the newly-improved handling of @url nodes. Is this true? Not entirely. You put that there, by the way :-) Basically all the @bookmarks plugin does is cause all descendants of a node containing '@bookmarks' to behave as if their headline starts with '@url'. Originally @url required @url http://bytes.com/topic/postgresql/answers/422972... make psql echo but now @url can also be @url make psql echo http://bytes.com/topic/postgresql/answers/422972... blog post describing how to make psql echo commands and that was when you considered bookmarks.py superseded, but I still prefer Postgresql tricks @bookmarks make psql echo http://bytes.com/topic/postgresql/answers/422972... blog post describing how to make psql echo commands because I prefer my list of bookmarks without @url all the way down the side, and also quickMove.py generates bookmark links in the format expected by bookmarks.py (i.e. without the @url) Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
That depends what you use clones for. If you use them for collecting a short list of nodes of current interest from a larger tree, you can get basically the same effect from the bookmarks.py and quickMove.py plugins. With those plugins enabled, create a node with a headline containing `@bookmarks`. It doesn't have to be at the start of the headline. That's not at all how I use clones. I use them for keeping persistent data persistent and in sync over multiple views and files. For example, in managing a multi-page web site there are numerous text fragments that need to be duplicated across all pages. Cloning these text fragments makes that task so much easier than manually trying to update every instance, or even try to remember where every instance is. Many of my other document tasks are similar in need for duplicating text fragments and keeping them in sync. Leo is often described as a kind of database, that would be great if I could figure out how to make it be such. That would mean being able to reference the 'master' version of a piece of data and sync to that. Clones sort of do that as long as the reference is 'inside' the same .leo file. How is it possible to reference that data (node) from a different .leo file? Someone mentioned something called a 'UNL'. I can't find any mention of UNLs in the docs glossary. I infer that it is a type of node reference. Where can I get more information about UNLs? Is this a possible answer to my earlier question of referencing a node from a different .leo file? Rob.. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Wed, 6 Jul 2011 19:12:20 -0700 (PDT)
Largo84 larg...@gmail.com wrote:
That depends what you use clones for. If you use them for collecting a
short list of nodes of current interest from a larger tree, you can get
basically the same effect from the bookmarks.py and quickMove.py
plugins. With those plugins enabled, create a node with a headline
containing `@bookmarks`. It doesn't have to be at the start of the
headline.
That's not at all how I use clones. I use them for keeping persistent
data persistent and in sync over multiple views and files. For
example, in managing a multi-page web site there are numerous text
fragments that need to be duplicated across all pages. Cloning these
text fragments makes that task so much easier than manually trying to
update every instance, or even try to remember where every instance
is.
Fair enough, that's an entirely different application. What I was
describing was my alternative to clones in the context of python source
code writing. For what you're doing I usually use a template language
like genshi or django-templates which has some sort of include
mechanism that can pull in often used pieces in multiple places.
Many of my other document tasks are similar in need for duplicating
text fragments and keeping them in sync. Leo is often described as a
kind of database, that would be great if I could figure out how to
make it be such. That would mean being able to reference the 'master'
version of a piece of data and sync to that. Clones sort of do that as
long as the reference is 'inside' the same .leo file. How is it
possible to reference that data (node) from a different .leo file?
Someone mentioned something called a 'UNL'. I can't find any mention
of UNLs in the docs glossary. I infer that it is a type of node
reference. Where can I get more information about UNLs? Is this a
possible answer to my earlier question of referencing a node from a
different .leo file?
UNL = Universal Node Locater, I think.
They're a kind of special URL, such that in places where Leo accepts an
URL like http://example.com/some/page.html it will also accept an UNL
like /path/to/file.leo#headline1--headline2--headline3 it should
shift to headline3 in file.leo, where headline3 is a child of
headline2 is a child of headline1.
Or if that target node's in the current .leo file, simply
headline1--headline2--headline3
Used to be implemented in the UNL.py plugin but moved into the core to
eliminate duplication of URL handling code.
Also note the right hand part of the status line at the bottom of the
Leo gui, that's the UNL for the current node within the current file.
You raise the interesting question, does this code work:
UNL=/home/tbrown/Desktop/Proj/BirdAtlas/db/birddb.leo#'SQL--twp/blk to county
path, UNL = UNL.split(#, 1)
ok,frame = g.openWithFileName(path, c)
new_c = frame.c
found, maxdepth, maxp = g.recursiveUNLSearch(UNL.split('--'), new_c)
g.es(new_c.p.h)
that should open a different .leo file (birddb.leo), and select the
node 'blk to county' under the node 'SQL'. It basically does that, but
birddb.leo becomes the active .leo file at the expense of whatever .leo
file was active when the script started, so there are some issues
there. Not bugs, just not an area anyone's explored much.
There are a couple of other plugins and extensions which provide APIs
from accessing leo data from scripts, but it's not clear to me if you
are looking for a scriptish solution?
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
Fair enough, that's an entirely different application. What I was
describing was my alternative to clones in the context of python source
code writing. For what you're doing I usually use a template language
like genshi or django-templates which has some sort of include
mechanism that can pull in often used pieces in multiple places.
By my definition, templates create a starting point from something but
don't have the ability to stay in sync. They're useful for many tasks,
not these. I'm not familiar w/ either of those tools you mentioned.
UNL = Universal Node Locater, I think.
They're a kind of special URL, such that in places where Leo accepts an
URL like http://example.com/some/page.htmlit will also accept an UNL
like /path/to/file.leo#headline1--headline2--headline3 it should
shift to headline3 in file.leo, where headline3 is a child of
headline2 is a child of headline1.
Or if that target node's in the current .leo file, simply
headline1--headline2--headline3
Used to be implemented in the UNL.py plugin but moved into the core to
eliminate duplication of URL handling code.
Also note the right hand part of the status line at the bottom of the
Leo gui, that's the UNL for the current node within the current file.
You raise the interesting question, does this code work:
UNL=/home/tbrown/Desktop/Proj/BirdAtlas/db/birddb.leo#'SQL--twp/blk to
county
path, UNL = UNL.split(#, 1)
ok,frame = g.openWithFileName(path, c)
new_c = frame.c
found, maxdepth, maxp = g.recursiveUNLSearch(UNL.split('--'), new_c)
g.es(new_c.p.h)
that should open a different .leo file (birddb.leo), and select the
node 'blk to county' under the node 'SQL'. It basically does that, but
birddb.leo becomes the active .leo file at the expense of whatever .leo
file was active when the script started, so there are some issues
there. Not bugs, just not an area anyone's explored much.
There are a couple of other plugins and extensions which provide APIs
from accessing leo data from scripts, but it's not clear to me if you
are looking for a scriptish solution?
Probably not as I have no idea how to write scripts in Leo. Nice to
know about UNLs though, I may have other uses for them. Where are they
documented? You mentioned they were added to Leo's core, that suggests
they're important and potentially useful.
Rob.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
Checked out genshi and django, they remind me of something similar when I was considering using a CMS for my web site (they're called template variables there, they serve the same function of substituting repeatable text blocks). Conceptually, they make sense but I wouldn't even know where to get started in using them in Leo, especially for non-html document tasks. Consider a text block that resides in some node with headline, say Fragment Info , in TextFragment.leo file. Suppose I'm working in SomeOtherFile.leo and want to reference that text block such that if Fragment Info is changed *and* SomeOtherFile.leo is updated, it updates every instance of that referenced text block. It seems like it should be a fairly straightforward task. I see that clones are not the way to accomplish this. Is there any capability currently in Leo (or a plugin) that can do this? Rob.. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Cross-file clones
On Tue, Jul 5, 2011 at 2:47 PM, Largo84 larg...@gmail.com wrote: Sorry if the answer is obvious, it's not to me. Should I avoid cloned nodes in @files that are referenced in different .leo files? Yes, you should avoid such clones, for the reasons you imply. Imo, every piece of data, of whatever kind, should be owned by at most one .leo file. If you break the rule you are going to expose yourself to a delayed (and therefore insidious) form of the multiple update problem. Besides being a technical problem, it could also be called a management problem: just as no human manager would willingly share responsibility for any set of code, no two .leo files should reference the same data. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
