Re: My thoughts which you are free to ignore :-)
Close all nodes, save .leo file, commit only the portions that need to be shared (i.e., don't commit any personal clones of nodes you may have made for your own projects). I do not understand. What is the meaning of the word close in this context? Do you mean to collapse the outline? How to you commit portions? I was talking about the Leo file, so I can only commit the whole Leo file, or nothing. I am not talking about any files that are only linked into Leo via @file or similar - I do not have problems with the VCS concerning normal text files, but as far as I understood, generic Leo files (albeit also text files), cannot be merged safely in general - we had this discussion before. Someone even suggested to merge FOSSIL and Leo as a solution. - 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: My thoughts which you are free to ignore :-)
On Wednesday, January 25, 2012 9:47:52 PM UTC+7, Josef wrote: I do not understand. What is the meaning of the word close in this context? Do you mean to collapse the outline? How to you commit portions? I was talking about the Leo file, so I can only commit the whole Leo file, or nothing. I am not talking about any files that are only linked into Leo via @file or similar - I do not have problems with the VCS concerning normal text files, but as far as I understood, generic Leo files (albeit also text files), cannot be merged safely in general - we had this discussion before. Someone even suggested to merge FOSSIL and Leo as a solution. I believe the person you're addressing is no longer here, and I can't speak for him/her, but at the time I had the same confusion and think I successfully figured out what they were trying to say, so I'll give it a go. Yes, close nodes = collapsing the outline. I believe this is so the before and after snapshots of the .leo file don't get muddled with the state-tracking data. Commit nodes or portions refers to the generated @ files - only commit in your VCS those you are sharing, not the ones you consider private. generic Leo files (albeit also text files), cannot be merged safely in general Safety is a relative thing - this person claimed to not have a problem with doing it - I've seen other say it can be done, but with difficulty. In my limited experience I wasn't able to do so successfully, which is why I added to my SOP making sure all the important data in my .leo files are also output to more-or-less structured plaintext @shadow files, all of which is frequently committed to VCS as well as routine backup archives. Note I am not casting aspersions on Leo's data safety, just working around my dangerously limited understanding of how to use it properly - perhaps now improved, but I'm a belt+suspenders kinda guy. -- 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/-/5zICHtE6KLQJ. 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: My thoughts which you are free to ignore :-)
I want to give credit where it is due - with snapshot-20120112 there are no such messages anymore. Juraj On 16. Jan, 14:37 h., Edward K. Ream edream...@gmail.com wrote: On Mon, Jan 16, 2012 at 7:15 AM, Juraj rin...@gmail.com wrote: But, as I already wrote, I don't use clones now... Could you send me a copy of a .leo file and the external files that give the messages? Thanks. 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: My thoughts which you are free to ignore :-)
I do not quite follow: Close all nodes, save .leo file, commit only the portions that need to be shared (i.e., don't commit any personal clones of nodes you may have made for your own projects). how do you not commit any nodes ...? I either commit a .leo file, or do not commit it - I cannot commit half a file! Also, do you mean to collapse nodes, when you say close nodes? - 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: My thoughts which you are free to ignore :-)
On 13. Jan, 13:34 h., Edward K. Ream edream...@gmail.com wrote: On Thu, Jan 12, 2012 at 4:17 PM, Edward K. Ream edream...@gmail.com wrote: On Thu, Jan 12, 2012 at 3:01 PM, Juraj rin...@gmail.com wrote: To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of sections and occasionally @others. Nothing else, yet I still get some uncached read node changed messages every time I am refreshing shadow nodes from changed external files. Sounds like a bug to me. I'll look into it. Afaik, this is the expected behavior. Indeed, Leo will generate a Revered Nodes nodes containing inner nodes for all such externally-changed nodes, for all @file trees that recreate outlines using sentinels. This includes @file and @shadow, but not @auto (it uses import logic). This is an important feature of Leo. At present, there is no option for disabling it. Are you saying that too many nodes are being reported as changed? If not, why is this behavior not ok with you? The question is, what does this message mean and how should I handle it? I don't know at all, for me it is just some cryptic message that causes me discomfort, like, maybe I am missing something... Can't be whole thing communicated more clearly, please, without need to know Leo innards or having to search bits of information in this mailing list?` Juraj -- 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 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: My thoughts which you are free to ignore :-)
On Mon, Jan 16, 2012 at 6:01 AM, Juraj rin...@gmail.com wrote: The question is, what does this message mean and how should I handle it? As explained in All about clone conflicts, it means that Leo has encountered two or more versions of what should be the same cloned node. This typically happens when you (or your agent, like bzr), changes one copy of a cross-file clone, but not all copies. The Recovered Nodes tree shows you all the data that Leo encountered. It is up to you to pick the proper version and change the cloned node appropriately. Leo will then write *all* copies of the newly-changed clone when you save the .leo file. 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: My thoughts which you are free to ignore :-)
But, as I already wrote, I don't use clones now... On 16. Jan, 13:50 h., Edward K. Ream edream...@gmail.com wrote: On Mon, Jan 16, 2012 at 6:01 AM, Juraj rin...@gmail.com wrote: The question is, what does this message mean and how should I handle it? As explained in All about clone conflicts, it means that Leo has encountered two or more versions of what should be the same cloned node. This typically happens when you (or your agent, like bzr), changes one copy of a cross-file clone, but not all copies. The Recovered Nodes tree shows you all the data that Leo encountered. It is up to you to pick the proper version and change the cloned node appropriately. Leo will then write *all* copies of the newly-changed clone when you save the .leo file. 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: My thoughts which you are free to ignore :-)
On Mon, Jan 16, 2012 at 7:15 AM, Juraj rin...@gmail.com wrote: But, as I already wrote, I don't use clones now... Could you send me a copy of a .leo file and the external files that give the messages? Thanks. 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: My thoughts which you are free to ignore :-)
On Jan 13, 6:34 am, Edward K. Ream edream...@gmail.com wrote: To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of sections and occasionally @others. Nothing else, yet I still get some uncached read node changed messages every time I am refreshing shadow nodes from changed external files. Sounds like a bug to me. I'll look into it. Afaik, this is the expected behavior. Indeed, Leo will generate a Revered Nodes nodes containing inner nodes for all such externally-changed nodes, for all @file trees that recreate outlines using sentinels. This includes @file and @shadow, but not @auto (it uses import logic). This is an important feature of Leo. At present, there is no option for disabling it. On second thought, @shadow should work more like @auto than @file in this regard. In other words, @shadow should not create *recovered* (not revered) nodes. I plan to do this today. 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: My thoughts which you are free to ignore :-)
On Sat, Jan 14, 2012 at 6:35 AM, Edward K. Ream edream...@gmail.com wrote: On second thought, @shadow should work more like @auto than @file in this regard. In other words, @shadow should not create *recovered* (not revered) nodes. I plan to do this today. Oops. On third thought, I think creating recovery nodes for @shadow files *is* the right thing to do. My second thought was confused. Recovery nodes aren't created for all changed nodes, only *cloned* changed nodes. Thus, there is a real potential for conflict and data loss whenever a recovery node exists. It seems unwise to ignore any situation that result in the creation of recovery nodes: all such situations have the potential to alter data due to the multiple update problem. Edward P.S. I would like to emphasize the following fact about cross file clones. They aren't dangerous *if* you only change them within Leo. All the problems arise because people change cloned data outside of Leo. Usually, people will change only *some* of the cloned data. In that case, Leo has the unenviable job of guessing what clone contains the intended data. In general, Leo can not guess accurately, no matter what rules are put into place. Thus, creating recovery nodes is *always* a good thing to do. 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. EKR -- 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: My thoughts which you are free to ignore :-)
On Thu, Jan 12, 2012 at 4:17 PM, Edward K. Ream edream...@gmail.com wrote: On Thu, Jan 12, 2012 at 3:01 PM, Juraj rin...@gmail.com wrote: To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of sections and occasionally @others. Nothing else, yet I still get some uncached read node changed messages every time I am refreshing shadow nodes from changed external files. Sounds like a bug to me. I'll look into it. Afaik, this is the expected behavior. Indeed, Leo will generate a Revered Nodes nodes containing inner nodes for all such externally-changed nodes, for all @file trees that recreate outlines using sentinels. This includes @file and @shadow, but not @auto (it uses import logic). This is an important feature of Leo. At present, there is no option for disabling it. Are you saying that too many nodes are being reported as changed? If not, why is this behavior not ok with you? 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.
Cross file clones (was Re: My thoughts which you are free to ignore :-))
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. EKR 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? -- -matt -- 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 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: My thoughts which you are free to ignore :-)
On Thursday, January 12, 2012 11:06:51 AM UTC+7, Terry wrote: On Wed, 11 Jan 2012 16:37:16 -0800 (PST) HansBKK han...@gmail.com wrote: It may be that shadow nodes need more testing, particularly with languages other than Python. I've used them without any particular issues, but then I decided I preferred @auto. I'm curious as to how the choice of language would impact @shadow functionality. Not sure, these are not areas of the code I'm familiar with, but Leo's automatic sectioning seems slightly less solid with javascript, which can have messy layout, compared to python with its indentation restrictions. And automatic sectioning followed by applying the modifications from the shadow file are involved in shadow loading. Aha I'd completely forgotten that @shadow can do automatic sectioning on import like @auto, I'd only been using them for exporting so far. -- 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/-/0JScoqXEUCAJ. 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: My thoughts which you are free to ignore :-)
On 12. Jan, 01:37 h., HansBKK hans...@gmail.com wrote: On Thursday, January 12, 2012 6:30:35 AM UTC+7, Terry wrote: On Wed, 11 Jan 2012 14:35:57 -0800 (PST) Juraj rin...@gmail.com wrote: Support of other languages or @shadow nodes (to cooperate with people that don't use leo) feels more like experiment. It may be that shadow nodes need more testing, particularly with languages other than Python. I've used them without any particular issues, but then I decided I preferred @auto. Leo does not support JSP automatically, it has only basic syntax highlighter for it, and I doubt it ever will be able to do it correctly, as JSP is very complicated format itself, moreover it is layered on top of HTML. What I do is to put the file into outline manually, and expect Leo to maintain the structure for me when file changes. It does this quite well (when it works, of course). I'm curious as to how the choice of language would impact @shadow functionality. At least for 2 reasons: 1. Leo is sensitive to indentation 2. needs to use right comments with sentinels, so that something else in the file won't confuse it. I believe I had problem with this as well, but could not easily reproduce it so far. I've been using them with plain text-as-text files and haven't come across issues, but also haven't done any systematic testing. I also have the extra security blanket that I make sure any files I'm manipulating with Leo are under version control, as I'm very aware that my limited understanding of Leo is a lot more likely to lead to data loss than any bugs. If the data loss is accompanied by unresponsive interface, missing menus, exceptions and inopenable Leo files... then I doubt it is caused just by my limited understanding... Juraj, when the time comes and you want to do some stress-testing with cloning, have a look at a standard operating procedure I've proposed to be documented herehttps://groups.google.com/d/msg/leo-editor/j7BOnRqCFcI/1jIavoqXxLUJ. Thanks, I'll bookmark that.. Further up in that thread I also point to a different SOP the developer pointed out in the past to try also. I'd appreciate any feedback you might have on these as a method to avoid problems with safely keeping nodes in multiple @files, in case that's one of your needs as well, as that's generally considered dangerous. To this moment I was not aware at all there is such thing as standard operating procedure... and even if it would be right in leo's official docs, good luck to have all new users read and follow it :-) I would also suggest regarding the problem's you've perceived with @shadow, create a new .leo file with a minimal test case to demonstrate any problems and I'm sure prompt attention will be paid to them if you post them here. Yes I did several times already, but some problems I encountered are hard to reproduce and they need hours, if not days to come up with minimal test case. Juraj -- 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: My thoughts which you are free to ignore :-)
On Wed, Jan 11, 2012 at 4:35 PM, Juraj rin...@gmail.com wrote: *EVERY* time I got a bit creative with applying clone nodes and other advanced Leo features to my workflow (managing JSP files using @shadow nodes, sometimes I edit the files in Eclipse as well), I really ran into lost data/leo crashes/unreadable files kind of bugs. Thanks for these comments. The integrity of Leo's data is paramount. Please report any kind of bug that causes lost data. It sounds like you may be suffering from clone conflicts. This will be the source of uncached read node changed conflicts. I know of no problems with these messages: they indicate something unusual or dubious has happened. If you don't like these messages, then perhaps you should dial back your usage of cross-file clones. You raise two completely separate issues, and it's important not to conflate them. The question of Leo's *stability* is completely independent of the bugs you mention. Indeed, I consider Leo to be stable if and only if new (daily) versions do not introduce *new* bugs. I stand by my assertion that Leo is stable in this sense. As for @shadow, I personally do not use it, but some people prefer it to @auto, and it's not going to go away. Again, if you experience data loss with @shadow I want to hear about it. 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: My thoughts which you are free to ignore :-)
On Jan 12, 6:45 am, Edward K. Ream edream...@gmail.com wrote: On Wed, Jan 11, 2012 at 4:35 PM, Juraj rin...@gmail.com wrote: *EVERY* time I got a bit creative with applying clone nodes and other advanced Leo features to my workflow (managing JSP files using @shadow nodes, sometimes I edit the files in Eclipse as well), I really ran into lost data/leo crashes/unreadable files kind of bugs. Thanks for these comments. The integrity of Leo's data is paramount. Please report any kind of bug that causes lost data. Let me amplify my thanks. I have had, for several years now, a growing sense that there could be a new, simpler, more general vision for Leo. There are many behind-the-scenes aspects of Leo that seem too complex. Perhaps chief among them are the various rules for handling conflicting clones, and multiple paths for cloned @file nodes. Your post was only the latest in a series of wake up calls. The previous was Terry's comment that he doesn't use or trust clones. Coming from one of Leo's most important users this was more than a little surprising. I also share your impression that Leo is a niche product at present, although there may be thousands of people who use Leo regularly--it's hard to know. My goal is to discover some way of making Leo easily accessible for many more people. I've had this goal for at least several years. Some major new invention is likely needed. What that new invention might be is murky at present. At present I am focused on fixing all the bugs that would prevent the next official release. In some sense, that's not so important now that *stable* daily builds are available, but bugs have to be fixed, and the sooner the better. After the official release goes out the door I'll give more attention to the big picture. 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: My thoughts which you are free to ignore :-)
On Jan 12, 6:45 am, Edward K. Ream edream...@gmail.com wrote: perhaps you should dial back your usage of cross-file clones. I actually think this advice is the heart of the matter. My guess is that you are using Leo's clones to try to overcome the limitations of languages like html that lack functions. That's understandable, but dangerous. Indeed, neither Leo nor any other program can possibly solve the multiple update problem for arbitrary collections of external files. Expecting Leo to do so is simply unreasonable, as I have said many times before. I have also said many times before that cross-file clones are inherently problematic. If you choose to be creative in this regard, I believe it is up to *you* to demonstrate that your expected work flow will not cause data loss as a result. There is simply no way for Leo to do magic on your behalf. This is a fact of life, not a bug in Leo per se. For example, leoPy.leo uses cross-file clones, but only in a stereotyped manner. Clones appear either in leoPy.leo itself, or in @file leoProjects.txt. This works because: 1. leoProjects.txt contains @all and 2. leoProjects.txt appears before all other @file nodes in leoPy.leo. This combination ensures that changed code in an external file will overwrite the clones in leoProjects.txt. Is this a perfect and robust scheme? No it is not. But it works fairly well and is about the best that can be expected. HTH. Edward 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. EKR -- 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: My thoughts which you are free to ignore :-)
Hi Edward, I am very thankful, too, that we can have this discussion and I really plan to dig deeper into Leo code once I'll be able, to be more helpful. On Jan 12, 4:47 pm, Edward K. Ream edream...@gmail.com wrote: On Jan 12, 6:45 am, Edward K. Ream edream...@gmail.com wrote: perhaps you should dial back your usage of cross-file clones. To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of sections and occassionally @others. Nothing else, yet I still get some uncached read node changed messages every time I am refreshing shadow nodes from changed external files. You are saying this is not OK? I actually think this advice is the heart of the matter. My guess is that you are using Leo's clones to try to overcome the limitations of languages like html that lack functions. That's understandable, but dangerous. Indeed, neither Leo nor any other program can possibly solve the multiple update problem for arbitrary collections of external files. Expecting Leo to do so is simply unreasonable, as I have said many times before. I have also said many times before that cross-file clones are inherently problematic. If you choose to be creative in this regard, I believe it is up to *you* to demonstrate that your expected work flow will not cause data loss as a result. There is simply no way for Leo to do magic on your behalf. This is a fact of life, not a bug in Leo per se. For example, leoPy.leo uses cross-file clones, but only in a stereotyped manner. Clones appear either in leoPy.leo itself, or in @file leoProjects.txt. This works because: 1. leoProjects.txt contains @all and 2. leoProjects.txt appears before all other @file nodes in leoPy.leo. This combination ensures that changed code in an external file will overwrite the clones in leoProjects.txt. Is this a perfect and robust scheme? No it is not. But it works fairly well and is about the best that can be expected. HTH. Edward 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. EKR -- 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: My thoughts which you are free to ignore :-)
On Thu, Jan 12, 2012 at 3:01 PM, Juraj rin...@gmail.com wrote: To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of sections and occassionally @others. Nothing else, yet I still get some uncached read node changed messages every time I am refreshing shadow nodes from changed external files. Sounds like a bug to me. I'll look into it. 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: My thoughts which you are free to ignore :-)
On Thursday, January 12, 2012 7:29:51 PM UTC+7, Juraj wrote: On 12. Jan, 01:37 h., HansBKK han...@gmail.com wrote: I've been using them with plain text-as-text files and haven't come across issues, but also haven't done any systematic testing. I also have the extra security blanket that I make sure any files I'm manipulating with Leo are under version control, as I'm very aware that my limited understanding of Leo is a lot more likely to lead to data loss than any bugs. If the data loss is accompanied by unresponsive interface, missing menus, exceptions and inopenable Leo files... then I doubt it is caused just by my limited understanding... Juraj, I was **only** referring to my limited understanding and my own lack of experience, not implying anything about yours. Further up in that thread I also point to a different SOP the developer pointed out in the past to try also. I'd appreciate any feedback you might have on these as a method to avoid problems with safely keeping nodes in multiple @files, in case that's one of your needs as well, as that's generally considered dangerous. To this moment I was not aware at all there is such thing as standard operating procedure... and even if it would be right in leo's official docs, good luck to have all new users read and follow it :-) I've been trying to create SOP documentation **for myself**, and soliciting feedback from others so that could possibly be included in future documentation. Bottom line if you really want to be safe from clone conflict data loss is don't allow a clone to be included in more than one @ file or any type. I think this should be well-documented (are clone conflicts even mentioned ATM?), and it sounds like we both think should actually be enforced by default - Leo can't protect users from all scenarios, but IMO should do so for known ones. Apparently the recent changes have to do with something along those lines? I have found what I believe to be a safe way (personal SOP)to accomplish safe multiple @file clones, which is don't allow a clone to be included in more than one @ file that imports, e.g. one @shadow; all others should be e.g. @nosent. Edwards' posting outlines an SOP that he follows which is based on the relative priority given to @all vs @others, and ordering in the tree. However all of these areas of using Leo are clearly fraught with danger and best considered experiment at your own risk. -- 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/-/fMVcRsiQV9MJ. 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: My thoughts which you are free to ignore :-)
On Jan 4, 12:07 am, Matt Wilkie map...@gmail.com wrote: 2. I am not aware of any painful bugs that would afflict newbies right out of the box. Excepting on MacOS, which is not truly supported, and perhaps never will be. I have started using leo seriously maybe just 2 months ago, and *EVERY* time I got a bit creative with applying clone nodes and other advanced Leo features to my workflow (managing JSP files using @shadow nodes, sometimes I edit the files in Eclipse as well), I really ran into lost data/leo crashes/unreadable files kind of bugs. I was able to report few cases here, but I have no doubts there are many more problems. If Leo would not be so helpful, I would abandon it. Instead I have learned my ways around and have postponed any testing of clone nodes after I finish current work project. Overall, I have got feeling that Leo enthusiasts are using it mostly for their own little Python development or creating documentation. Support of other languages or @shadow nodes (to cooperate with people that don't use leo) feels more like experiment. For example, Leo *never* asked me about conflict when saving or reading @shadow file. At most it just spits out useless uncached read node changed messages. I always have to remember myself whether I have changed file on disk so that I need to reread it, and vice versa. It feels like a rant, sorry. But I have to disagree with whole Leo *is* stable, 99% of the time or more premise. Maybe it is, if you 99% of the time don't disgress from your workflow or don't have to deal much with changing external files... Juraj -- 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: My thoughts which you are free to ignore :-)
On Wed, 11 Jan 2012 14:35:57 -0800 (PST) Juraj rin...@gmail.com wrote: Support of other languages or @shadow nodes (to cooperate with people that don't use leo) feels more like experiment. It may be that shadow nodes need more testing, particularly with languages other than Python. I've used them without any particular issues, but then I decided I preferred @auto. 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: My thoughts which you are free to ignore :-)
On Thursday, January 12, 2012 6:30:35 AM UTC+7, Terry wrote: On Wed, 11 Jan 2012 14:35:57 -0800 (PST) Juraj rin...@gmail.com wrote: Support of other languages or @shadow nodes (to cooperate with people that don't use leo) feels more like experiment. It may be that shadow nodes need more testing, particularly with languages other than Python. I've used them without any particular issues, but then I decided I preferred @auto. I'm curious as to how the choice of language would impact @shadow functionality. I've been using them with plain text-as-text files and haven't come across issues, but also haven't done any systematic testing. I also have the extra security blanket that I make sure any files I'm manipulating with Leo are under version control, as I'm very aware that my limited understanding of Leo is a lot more likely to lead to data loss than any bugs. Juraj, when the time comes and you want to do some stress-testing with cloning, have a look at a standard operating procedure I've proposed to be documented herehttps://groups.google.com/d/msg/leo-editor/j7BOnRqCFcI/1jIavoqXxLUJ. Further up in that thread I also point to a different SOP the developer pointed out in the past to try also. I'd appreciate any feedback you might have on these as a method to avoid problems with safely keeping nodes in multiple @files, in case that's one of your needs as well, as that's generally considered dangerous. I would also suggest regarding the problem's you've perceived with @shadow, create a new .leo file with a minimal test case to demonstrate any problems and I'm sure prompt attention will be paid to them if you post them here. -- 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/-/CwIYW3sMlfUJ. 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: My thoughts which you are free to ignore :-)
On Wed, 11 Jan 2012 16:37:16 -0800 (PST) HansBKK hans...@gmail.com wrote: It may be that shadow nodes need more testing, particularly with languages other than Python. I've used them without any particular issues, but then I decided I preferred @auto. I'm curious as to how the choice of language would impact @shadow functionality. Not sure, these are not areas of the code I'm familiar with, but Leo's automatic sectioning seems slightly less solid with javascript, which can have messy layout, compared to python with its indentation restrictions. And automatic sectioning followed by applying the modifications from the shadow file are involved in shadow loading. 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: My thoughts which you are free to ignore :-)
On Thu, Jan 5, 2012 at 2:40 PM, SKempf severin.ke...@sportplanedesign.com wrote: I would like to hear anyone's thoughts on upgrading from 4.8 or if there might be a better way that we could approach these issues. The biggest issue I know about is break in compatibility between @file formats. Starting with Leo 4.5, Leo can not read files written by Leo 3.x. If you try, you will get this error message:: can not read 3.x derived file file name you may upgrade these file using Leo 4.0 through 4.4.x You are safe if you can read all your external files with Leo 4.8. Other than that, I would suggest using one of the recent nightly builds. There are no *new* bugs in those builds, and substantially fewer old bugs. Having said that, there is always the chance that you will find serious upgrade issues. I will be happy to fix any that appear. Such bugs will have the highest (critical) priority. 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: My thoughts which you are free to ignore :-)
We have been using leo for several years now. Although we are not primarily programmers, we have quite a bit of experience using python to help solve the problems on which we are working. We use leo kind of like someone might use MathCad or some similar product -- as opposed to using it to develop and maintain a set of tools, which presumably you would be maintaining your upkeep of leo and your leo files as well. Installation has never been too big of an issue for us. However, another aspect of getting people to use a tool the way we are, is the aspect stability and maintainability of the product. Perhaps one might consider how hard is it for me to upgrade? and what does upgrading mean to my existing files?. We are now in a situation where we have many leo files, some are two or more years old and some are new; they used different features some that might be deprecated and some that work just fine -- well, certainly everything works with the version we are currently running which is quite old (11/2010). We're not sure if we should attempt 4.9 final or some delayed build that might have an issue that was fixed but we don't know about it. One way we have started to deal with the issue, is to use less functionality within leo and put as much information in separate files rather than in leo itself. The consequence of this is not using leo for what it *could* be used for, but also increases the annoyance of the line noise as mentioned in this post. There is also a consequence of not wanting our whole team to use it for fear of the overhead to maintain differences and issues. I would like to hear anyone's thoughts on upgrading from 4.8 or if there might be a better way that we could approach these issues. -- 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: My thoughts which you are free to ignore :-)
2. I am not aware of any painful bugs that would afflict newbies right out of the box. Excepting on MacOS, which is not truly supported, and perhaps never will be. Very unfortunate. OSX isn't supported because no one wants to support it, rather because there isn't anyone here knows *how* to. There was a thread a few months ago from someone who found, for them, a better than usual method for installing and running Leo on a mac. If memory serves it used something called Homebrew. That aside, the central point of this thread that reducing the friction in getting Leo installed and running on new system is a good idea remains salient. -- -matt -- 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: My thoughts which you are free to ignore :-)
It sounds like your biggest issues are OSX-related well, I have trouble introducing Leo in my company, because we do have some OSX users here (next to Debian/Ubuntu and Windows). Ironically I chose Leo originally because it being based on Python promised cross- platform functionality. This concerns only some Leo applications though: generally I see Leo as a personal tool, e.g. where the shared files are the files Leo is dealing with (e.g. @file etc), not the the Leo files themselves. Collaboration with Leo files does not seem a good idea as long as generic Leo files cannot be merged automatically. - 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: My thoughts which you are free to ignore :-)
On Jan 3, 2012, at 3:30 AM, Josef wrote: well, I have trouble introducing Leo in my company, because we do have some OSX users here (next to Debian/Ubuntu and Windows). Indeed, this is exactly the kind of barrier to adoption that can occur when a major platform is not seriously supported. Collaboration with Leo files does not seem a good idea as long as generic Leo files cannot be merged automatically. I am not sure what you mean by this. It is true that you don't want to merge an outline when you have a number of open nodes and some cloned nodes for personal purposes, but if you close all the nodes then it is easy to commit just the parts of the outline relating to e.g. new/removed files, etc. I also don't see any fundamental problem with merging the sentinels in the @files. Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
On Tuesday, January 3, 2012 6:23:20 AM UTC+7, gcrosswhite wrote: generic Leo files cannot be merged automatically. I am not sure what you mean by this. It is true that you don't want to merge an outline when you have a number of open nodes and some cloned nodes for personal purposes, but if you close all the nodes then it is easy to commit just the parts of the outline relating to e.g. new/removed files, etc. I understood him to mean that while it is straightforward to share the @ file output files, it is difficult to share outline information contained in the .leo files themselves, as the XML doesn't lend itself to merging. I'm interested in your suggestions for working around this issue, however I'm not following what you mean by: merge an outline committing (parts of) outlines - do you mean data stored in sentinels or in .leo files? to open or close nodes ? Perhaps it would help if you could describe your workflow's operations in terms of actual commands, steps using Leo commands or menu items? -- 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/-/jUHbe6qtRc4J. 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: My thoughts which you are free to ignore :-)
On Jan 3, 2012, at 11:36 AM, HansBKK wrote: I understood him to mean that while it is straightforward to share the @ file output files, it is difficult to share outline information contained in the .leo files themselves, as the XML doesn't lend itself to merging. Since the XML produced by Leo in practice places a tag for each node on a separate line in the .leo file, merging it is no different from merging any other text file. The only thing that sometimes can cause an issue is when a node starts or stops being the parent of a subtree, in which case the closing portion of the node tag is moved between being on the same line as the opening portion of the node tag and being on a separate line after all the subnodes. Usually this is not a big deal, but in the relatively rare case where you are merging non-trivial changes you need to pay a little extra attention to make sure that the closing tags have all ended up in the correct places. Of course, this relies on the fact that Leo outputs its XML description of the outline in a particular way. This is why in the past when changes to the .leo format have been proposed I have suggested that it is important to also pin down exactly how whitespace in the XML file will be handled so that .leo files can play nicely together with revision control systems. I'm interested in your suggestions for working around this issue, however I'm not following what you mean by: merge an outline committing (parts of) outlines - do you mean data stored in sentinels or in .leo files? to open or close nodes ? I mean that there is no problem in sharing *either* @file nodes or .leo files in a revision control system, as long as you close all of your nodes before saving the .leo file so that all of the markup having to do with which particular nodes you had open is stripped from the .leo file before you commit your changes. Perhaps it would help if you could describe your workflow's operations in terms of actual commands, steps using Leo commands or menu items? Close all nodes, save .leo file, commit only the portions that need to be shared (i.e., don't commit any personal clones of nodes you may have made for your own projects). Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
On Dec 29, 2011, at 11:22 PM, Edward K. Ream wrote: On Tue, Dec 27, 2011 at 11:51 PM, Gregory Crosswhite gcrosswh...@gmail.com wrote: if Leo is really interested in users then it should first try at the very least to produce a product that is easy to install and that doesn't have so many painful bugs out of the box. Two very separate issues. 1. I agree that it would be better to have Leo install more simply, with a better one-click installer. However, I don't know how to do that. It's as simple as that. On OSX one typically produces bundles that include all of the dependencies needed by an application, which in this case would include Leo, Qt, and PyQt, and also probably Python just to be safe even though technically OSX includes Python. A little Google searching turned up http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html For Windows a little Google searching turned up http://www.py2exe.org/ which looks like it does a similar thing. Leo's new daily build page actually goes a long way towards making the latest builds available to users. This is a big step forward, imo. It is not quite clear to me why this is a big step forward since I would imagine that the typical user would want the latest stable version, but my perspective is clearly different from that of most here so there is no reason to expect that my notions should apply. :-) 2. I am not aware of any painful bugs that would afflict newbies right out of the box. Excepting on MacOS, which is not truly supported, and perhaps never will be. Very unfortunate. Yes, Leo does have its share of bugs, but these should not prevent newcomers from forming a reasonable impression of Leo. Unless they are running on OSX. Personally, although I have been using Leo for years, I would switch away in a heartbeat if there were another project that had the same essential feature of representing text files as outlines but which had an implementation that was more stable, easier to install, and easier to configure. Leo is the only project that is likely ever to have Leo's features. That would be tragic, because it would mean that no fully supported software with Leo's features will ever exist on OSX. And Leo *is* stable, 99% of the time or more. Again, unless one is running it on OSX... but if your point is that on other platforms it is incredibly stable and so my experience is unrepresentative then that is certainly fair enough. [Leo] needs to place a much greater emphasis on improving and polishing basic usability issues than it has so far seemed inclined to do. I take usability issues seriously because I use Leo every day. Yes, but in a sense that is a problem because as a power user your sense of what makes Leo usable is not at all what a newbie would consider usable. :-) For example, having many of the settings available in a GUI would make Leo a lot easier to use, but this project doesn't like GUIs for that kind of thing because of its focus on scripting; it used to have a dialog box to perform some configuration, but it got rid of that a long time ago. (Just to be perfectly clear, I am not saying that this is a wrong decision for the Leo project to make, it's just that in my opinion this will make it harder to attract more users who might have otherwise been drawn to the features that Leo has to offer.) There are many usability-related bugs on the list, and I'll get to them asap. If you have specific complaints, please file bug reports. I will continue to file bug reports for problems that I run into in the hope that they will be fixed, though unfortunately the response I have occasionally gotten has been That simply will not work on OSX., such as the bug I filed some time ago that copying and pasting from node headlines doesn't work properly and occasionally causes Leo to crash. Unfortunately there is not much I can do about most of the things that I care about because the Leo community clearly has a different vision of what Leo should be about, where it should be headed, and what platforms it should support, etc., than I, and because of this there doesn't seem to be much point in me investing a lot of energy into it. When I started using Leo ~ 8-10 years or so ago the focus of Leo was primarily to produce a good outlining text editor, but since then the focus seems to have morphed into an outline scripting toolkit for power users; if Leo had been more like what it is now back when I was first looking into it there is a very good chance that I would never have bothered with it --- but then again, clearly I am not the kind of user that Leo is after now so perhaps it would have been for the best. :-) Anyway, thank you Edward for the reply. :-) Cheers, Greg -- 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
Re: My thoughts which you are free to ignore :-)
On Dec 31, 2011, at 8:28 AM, HansBKK wrote: It sounds like your biggest issues are OSX-related, *perhaps even your desire for ease of use features like GUI settings.* [emphasis mine] Umm, no, that is just some kind of absurd stereotype. There is nothing about being an OSX user that makes me less inclined to wrestle with unnecessary complexity to get something done. You might also note that you *are* talking to someone who has spent a longer time being a Gentoo and FreeBSD user than an OSX user. For at least the last 8 years I have been running either Gentoo or FreeBSD on my desktop machines, it's just that 6 years ago when I decided to switch my home platform to being a laptop I decided to try out OSX in part Linux/FreeBSD had spotty support for Laptop hardware. I still run Gentoo linux on my work platforms, and in fact I just installed it a couple of weeks ago on a new machine. And I realize it's not a good answer, but note that I use virtual machines for a few legacy apps that don't run on my current platform, and in fact some are set up to auto-launch so they're always-available. Takes a decent amount of RAM (cheap these days) and a little up-front work to get going, but after that it's just like launching another app. I would certainly hope that the Leo community doesn't consider Leo to be a legacy application... And if it really did come to needing to run Leo inside a virtual machine, I would just bite the bullet, recognize that Leo is simply not useful as a tool anymore, and stop using it entirely. Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
On Tue, Dec 27, 2011 at 11:51 PM, Gregory Crosswhite gcrosswh...@gmail.com wrote: if Leo is really interested in users then it should first try at the very least to produce a product that is easy to install and that doesn't have so many painful bugs out of the box. Two very separate issues. 1. I agree that it would be better to have Leo install more simply, with a better one-click installer. However, I don't know how to do that. It's as simple as that. Leo's new daily build page actually goes a long way towards making the latest builds available to users. This is a big step forward, imo. 2. I am not aware of any painful bugs that would afflict newbies right out of the box. Excepting on MacOS, which is not truly supported, and perhaps never will be. Yes, Leo does have its share of bugs, but these should not prevent newcomers from forming a reasonable impression of Leo. Personally, although I have been using Leo for years, I would switch away in a heartbeat if there were another project that had the same essential feature of representing text files as outlines but which had an implementation that was more stable, easier to install, and easier to configure. Leo is the only project that is likely ever to have Leo's features. And Leo *is* stable, 99% of the time or more. [Leo] needs to place a much greater emphasis on improving and polishing basic usability issues than it has so far seemed inclined to do. I take usability issues seriously because I use Leo every day. There are many usability-related bugs on the list, and I'll get to them asap. If you have specific complaints, please file bug reports. 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: My thoughts which you are free to ignore :-)
Don't we have one-click installers already? On Wed, Dec 28, 2011 at 6:51 AM, Gregory Crosswhite gcrosswh...@gmail.com wrote: First, please let me just say that the following are just my thoughts to introduce a different perspective on the Leo project and you all are free to ignore or dismiss them if you wish. :-) An impression I have gotten from my occasional lurking on this list is that people like to talk about the things that they can do to attract new users, with the conversation often evolving into the best way we can show people all of the possibilities offered by the Leo outline toolkit. Personally, I think that if Leo is really interested in users then it should first try at the very least to produce a product that is easy to install and that doesn't have so many painful bugs out of the box. It also wouldn't hurt if basic configuration tasks, such as setting the fonts, had a simple dialog box (like there used to be) rather than making the user dig around a separate settings outline for them. I understand that the whole point of Leo to most of the people on this list is to provide a powerful Python-powered toolkit for viewing and manipulating data using outlines which means that the user should be encouraged to figure these kinds of things out for themselves, but this has seemed to come at the cost of producing a product that is easy to use for people who just want the most basic features. Personally, although I have been using Leo for years, I would switch away in a heartbeat if there were another project that had the same essential feature of representing text files as outlines but which had an implementation that was more stable, easier to install, and easier to configure. Having one-stop installers would be a particularly nice feature for me because it would give me much greater confidence that other people looking my code would actually be using Leo to view it and hence would getting the birds' eye view I had created for them via. the outline, rather than deciding that going through a multi-step process to install a tool they'd never heard of is more trouble than it is worth and then getting annoyed that my code has so much line noise in it. Now don't get me wrong, if the community is happy having Leo be a relatively niche tool that provides a lot of power for a relatively small community of power users then there is nothing wrong with that, since plenty of tools have thrived well enough by taking that route. :-) However, if it really is a serious goal of the community for Leo to become a widely used tool, then it needs to place a much greater emphasis on improving and polishing basic usability issues than it has so far seemed inclined to do. Again, though, this is just my own perspective, and I have no expectation that my opinion deserves to be weighted more than slightly since I have contributed relatively little to the project compared to many people here. :-) Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
sir now i am using leo geo ofiice for beach surveys. i want to convert the data reads the instrument into data file format how can i done it using the software. On 28 December 2011 14:19, Ville M. Vainio vivai...@gmail.com wrote: Don't we have one-click installers already? On Wed, Dec 28, 2011 at 6:51 AM, Gregory Crosswhite gcrosswh...@gmail.com wrote: First, please let me just say that the following are just my thoughts to introduce a different perspective on the Leo project and you all are free to ignore or dismiss them if you wish. :-) An impression I have gotten from my occasional lurking on this list is that people like to talk about the things that they can do to attract new users, with the conversation often evolving into the best way we can show people all of the possibilities offered by the Leo outline toolkit. Personally, I think that if Leo is really interested in users then it should first try at the very least to produce a product that is easy to install and that doesn't have so many painful bugs out of the box. It also wouldn't hurt if basic configuration tasks, such as setting the fonts, had a simple dialog box (like there used to be) rather than making the user dig around a separate settings outline for them. I understand that the whole point of Leo to most of the people on this list is to provide a powerful Python-powered toolkit for viewing and manipulating data using outlines which means that the user should be encouraged to figure these kinds of things out for themselves, but this has seemed to come at the cost of producing a product that is easy to use for people who just want the most basic features. Personally, although I have been using Leo for years, I would switch away in a heartbeat if there were another project that had the same essential feature of representing text files as outlines but which had an implementation that was more stable, easier to install, and easier to configure. Having one-stop installers would be a particularly nice feature for me because it would give me much greater confidence that other people looking my code would actually be using Leo to view it and hence would getting the birds' eye view I had created for them via. the outline, rather than deciding that going through a multi-step process to install a tool they'd never heard of is more trouble than it is worth and then getting annoyed that my code has so much line noise in it. Now don't get me wrong, if the community is happy having Leo be a relatively niche tool that provides a lot of power for a relatively small community of power users then there is nothing wrong with that, since plenty of tools have thrived well enough by taking that route. :-) However, if it really is a serious goal of the community for Leo to become a widely used tool, then it needs to place a much greater emphasis on improving and polishing basic usability issues than it has so far seemed inclined to do. Again, though, this is just my own perspective, and I have no expectation that my opinion deserves to be weighted more than slightly since I have contributed relatively little to the project compared to many people here. :-) Cheers, Greg -- 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. -- YADHUNATH.E.M -- 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: My thoughts which you are free to ignore :-)
On Dec 28, 2011, at 6:49 PM, Ville M. Vainio wrote: Don't we have one-click installers already? Only for Debian, assuming it works (I haven't tried it myself). There is no such installer for OSX. The installer for Windows is not a one-stop installer because requires you to have already installed Python, Qt, and PyQt, without mentioning this explicitly anywhere on the Downloads page. Furthermore, while the installer won't let you install Leo until you can tell it where Python is, it won't complain it all if you don't have PyQt installed. However, if you don't have PyQt installed, then from a user perspective nothing happens when he or she double-clicks on the Leo icon --- technically a message is printed in this case, but merely clicking on the icon does not bring up a console so the user does not see it. Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
OSX is a special case, I don't think we need to support it perfectly - it seems to be a weird world of its own. Debian packages work with Ubuntu and Debian. For windows, maybe we could create a better installer that ships with PyQt libs out of the box. On Wed, Dec 28, 2011 at 11:47 AM, Gregory Crosswhite gcrosswh...@gmail.com wrote: On Dec 28, 2011, at 6:49 PM, Ville M. Vainio wrote: Don't we have one-click installers already? Only for Debian, assuming it works (I haven't tried it myself). There is no such installer for OSX. The installer for Windows is not a one-stop installer because requires you to have already installed Python, Qt, and PyQt, without mentioning this explicitly anywhere on the Downloads page. Furthermore, while the installer won't let you install Leo until you can tell it where Python is, it won't complain it all if you don't have PyQt installed. However, if you don't have PyQt installed, then from a user perspective nothing happens when he or she double-clicks on the Leo icon --- technically a message is printed in this case, but merely clicking on the icon does not bring up a console so the user does not see it. Cheers, Greg -- 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: My thoughts which you are free to ignore :-)
A lot of attention is paid to usability in Leo, but I can't imagine it's ever been intended for normal end users. If anyone claims it is, then they haven't had much experience with real normal end users. I have been the techiest person at every job I've ever had over many decades, which totals thousands of people, and I'm the village idiot around here. And say you make it super-easy to install, (which currently happens to be the easiest thing about Leo 8-) then once Betty secretary got it up and running, what is she going to do with it? Having a reasonably high barrier to entry at installation time ensures that even if someone isn't a programmer, at least they are able to follow instructions, and figure things out to fill in the gaps. Note this is pretty much par for the course for most of the powerful tools in the FOSS world - say you want to set up Apache with PHP and MySQL to run a wiki, and then figure out how to get it to authenticate and authorize user groups from an existing LDAP server. Not too many end-user friendly tools in that space - which is also much more of a close-ended system than the infinite flexibility Leo offers. . . Now it probably wouldn't take **that** much work to package a fork of Leo to work as a decent note-taking outlining tool, or a filesystem meta-manager, or a to-do tracker/project management system, but only one of those use cases at a time. Then all the features that aren't directly relevant to that particular use would need to be hidden if not actually removed. And somehow I don't think that is what the current developers want to spend their time doing, not to mention who would handle the much larger volume of support questions that would come from such users? IMO Leo is intended primarily as a tool for Python programmers - and I'm sure non-Python programmers could also get up to speed pretty quickly. For the rest of us, it's a pretty steep learning curve - well worth the climb (I'm sure) but not like say getting to know Photoshop. But of course I shouldn't be speaking for the developers, all the above is sheer speculation on my part. -- 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/-/AWNi6PGWnM8J. 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: My thoughts which you are free to ignore :-)
I agree that non-technical users are not the audience for Leo. However, if someone is just looking to check out a tool to see if it is worth adopting, then no matter how technical that someone is there is only so much trouble that he or she is willing to bother with before writing it off and spending his or her time doing things that he or she cares about more. There have been many times I've seen a tool on the internet that I thought *might* make my life easier, but then decided wasn't worth it after the installation turned out to be too much trouble, even though I in principle could probably have gotten it working if I had spent an arbitrary amount of time figuring out everything that was going wrong. The point of minimizing the barrier to installing a tool is not to make it accessible to the lowest common denominator, it is to maximize the chance that a potential user will go to the trouble of checking it out. Cheers, Greg On Dec 28, 2011, at 9:41 PM, HansBKK wrote: A lot of attention is paid to usability in Leo, but I can't imagine it's ever been intended for normal end users. If anyone claims it is, then they haven't had much experience with real normal end users. I have been the techiest person at every job I've ever had over many decades, which totals thousands of people, and I'm the village idiot around here. And say you make it super-easy to install, (which currently happens to be the easiest thing about Leo 8-) then once Betty secretary got it up and running, what is she going to do with it? Having a reasonably high barrier to entry at installation time ensures that even if someone isn't a programmer, at least they are able to follow instructions, and figure things out to fill in the gaps. Note this is pretty much par for the course for most of the powerful tools in the FOSS world - say you want to set up Apache with PHP and MySQL to run a wiki, and then figure out how to get it to authenticate and authorize user groups from an existing LDAP server. Not too many end-user friendly tools in that space - which is also much more of a close-ended system than the infinite flexibility Leo offers. . . Now it probably wouldn't take **that** much work to package a fork of Leo to work as a decent note-taking outlining tool, or a filesystem meta-manager, or a to-do tracker/project management system, but only one of those use cases at a time. Then all the features that aren't directly relevant to that particular use would need to be hidden if not actually removed. And somehow I don't think that is what the current developers want to spend their time doing, not to mention who would handle the much larger volume of support questions that would come from such users? IMO Leo is intended primarily as a tool for Python programmers - and I'm sure non-Python programmers could also get up to speed pretty quickly. For the rest of us, it's a pretty steep learning curve - well worth the climb (I'm sure) but not like say getting to know Photoshop. But of course I shouldn't be speaking for the developers, all the above is sheer speculation on my part. -- 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/-/AWNi6PGWnM8J. 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: My thoughts which you are free to ignore :-)
I actually completely agree with you, but enjoy playing devil's advocate. However I do think it remains true that if a given user has much trouble (say more than a hour's fiddling) getting Leo up and running from the current instructions, then they are unlikely to benefit from using Leo. Except of course as a learning exercise, in which case they benefited from the installation process in the same way. And that process itself is IMO just not that hard - I had never looked at any tool related to Python, much less installed it before, and I just followed the instructions and baddabing baddaboom I've got Leo running, maybe 40 minutes altogether. Getting it to run portably, as my environment requires, took a bit more fiddling (anyone interested I just posted a howto herehttps://groups.google.com/d/msg/leo-editor/HBhBnAyVG3E/UXHC1jq50iYJ), but I'm not counting that. If there were all-in-one windows installer, I for one would definitely have chosen not to use it, because I don't trust such routines: - Just the non-admin-user on W7 is a mess to deal with. - Are you trusting the %path% active at the time of installation? - Or (god forbid) relying on strings written by other arbitrary install routines to the registry? - What if I already have multiple instances/versions of Python installed? - Or are you installing yet another full Python+GTK+whatever instance that I'll now need to maintain in addition to my existing ones? Again I'm not speaking for the developers, but I suspect most of them would rather not spend their time on improving this specific area of the package as opposed to the other aspects they're currently working on (or the other aspects of their lives 8-). And of course the usual FOSS answer applies here - if you think such a packaged setup routine is important to the project, and you have the skills, feel free to code it up and submit it for consideration to be incorporated into the program. Or submit a wishlist to the bug tracker and if not now, perhaps in future it will act as a reminder to inspire someone with the skills who would like to encourage non-technical users to try Leo out. -- 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/-/_dhXS5AxqkwJ. 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.
