My thoughts which you are free to ignore :-)

[Gregory Crosswhite]

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

[Ville M. Vainio]

Don't we have one-click installers already?

> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to
> leo-editor+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/leo-editor?hl=en.

[yadhu nath]

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.

--
YADHUNATH.E.M

[Gregory Crosswhite]

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

[Ville M. Vainio]

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.

[HansBKK]

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.

[Gregory Crosswhite]

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

--
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.

[HansBKK]

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 here), 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.

[HansBKK]

On Thursday, December 29, 2011 8:42:32 AM UTC+7, HansBKK wrote:

  - Or are you installing yet another full Python+GTK+whatever instance that I'll now need to maintain in addition to my existing ones?

Sorry, not GTK, QT of course (recently installing Gimp in portable mode got my wires crossed).

[Edward K. Ream]

On Tue, Dec 27, 2011 at 11:51 PM, Gregory Crosswhite
<gcros...@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

[Gregory Crosswhite]

On Dec 29, 2011, at 11:22 PM, Edward K. Ream wrote:

On Tue, Dec 27, 2011 at 11:51 PM, Gregory Crosswhite
<gcros...@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

[HansBKK]

It sounds like your biggest issues are OSX-related, perhaps even your desire for ease of use features like GUI settings.

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.

Also my understanding is that the way Leo is coded means that a given "recent release" isn't in any way more stable than the nightly snapshot - perhaps I should phrase that - the nightly snapshots are just as stable as the release (99.x% of the time); it may even be true that the posted release doesn't get any extra testing at all other than by new users, and are just posted to comply with the usual convention for those not familiar with Leo.

In fact at this point the release is more of a "legacy" version, as it always will be once a few weeks goes by without it being updated.

[Gregory Crosswhite]

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

[Josef]

> 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

[Gregory Crosswhite]

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

[HansBKK]

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?

[Gregory Crosswhite]

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

[Matt Wilkie]

> 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

[SKempf]

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.

[Edward K. Ream]

On Thu, Jan 5, 2012 at 2:40 PM, SKempf
<severi...@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

[Juraj]

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

[Terry Brown]

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

[HansBKK]

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 here. 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.

[Terry Brown]

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.

Cheers -Terry

[HansBKK]

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.

[Juraj]

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 here<https://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

[Edward K. Ream]

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

[Edward K. Ream]

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

[Edward K. Ream]

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

[Juraj]

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?

[Edward K. Ream]

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

[HansBKK]

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".

[Edward K. Ream]

On Thu, Jan 12, 2012 at 4:17 PM, Edward K. Ream <edre...@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

[Edward K. Ream]

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

[Edward K. Ream]

On Sat, Jan 14, 2012 at 6:35 AM, Edward K. Ream <edre...@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

[Juraj]

On 13. Jan, 13:34 h., "Edward K. Ream" <edream...@gmail.com> wrote:

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

[Edward K. Ream]

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

[Juraj]

But, as I already wrote, I don't use clones now...

[Edward K. Ream]

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

[Juraj]

I want to give credit where it is due - with snapshot-20120112 there
are no such messages anymore.

Juraj

[Josef]

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

[Josef]

> 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

[HansBKK]

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.