Hi Ed, thanks for your detailed response. I do agree with your points that (at least for now) the desktop isn't dead yet. But delivery model aside, I'm still hopeful that some evolution might happen for Leo to end up being workable in a team environment.
I got a bit of a rude shock a year ago when I took my present development role. At first, I imported one of my job's codebases into a Leo tree, with aim of continuing with Leo as my editor of choice. But I saw that this would be unworkable, since my teammates would crucify me for "polluting" the files with Leo sentinels, whilst any changes made by others would be difficult to reflect in the Leo view without removing then reimporting the file. With Python code, it's not such an issue, since Leo is generally quite good at carving up Python sources into a simple module/class/method hierarchy. The difficulty comes with file types that are hard to carve up automatically AND meaningfully, such as javascript, html templates, css and so on. For write-only applications (ie, single-developer projects), Leo is on numerous fronts the tool of choice. But in scenarios where Leo needs to accommodate changes made by non-Leo users, people who won't accept Leo sentinels, and who reject literate programming, there's a struggle. This is a non-trivial issue, that does not reflect on Leo, but rather reflects on team development culture. I would love nothing more than to be able to edit the company's 80,000+ lines of source in Leo, while still being able to work in with my teammates, and would welcome any suggestions. Cheers David On 19 August 2015 at 03:40, Edward K. Ream <[email protected]> wrote: > On Mon, Aug 17, 2015 at 8:17 PM, David McNab <[email protected]> > wrote: > >> I agree - Leo is probably way more than 100% feature-complete. It's also >> been a tremendous comfort to me and my solo programming efforts over the >> years. >> > > Glad to hear it. > > > However, Leo is still imprisoned in the >> standalone-software-installed-on-desktop paradigm, and thus stuck in a >> rapidly-disappearing era. >> > > Yes, web-based services are increasingly important, but unless I am > greatly mistaken most programmers still use laptop and desktop computers > and Emacs, vim, Eclipse and the like. > > I don't see that changing anytime soon, and if it does change it will > likely be the result of tools that don't yet exist. Furthermore, security > problems are troubling with any web-based tool. > > The biggest problems I've had with Leo to date have been: >> >> - Gaps in backward incompatibility - serious corruption and data loss >> issues when editing years-old Leo files, something which has tripped me up >> many times >> >> The work around is to use the old versions of Leo to recover the data, > then copy and paste to a newer version of Leo. I have no plans to retrofit > any further backward compatibility code. > > > >> Incompatibility with team environments - inability for more than one >> developer to work on files at once >> I can't use Leo on my tablet or smartphone, unless I screenshare in to a >> desktop running it. Unless the tablet is on a LAN near the desktop, and has >> a 10" screen, this is unworkable. >> > > Supporting tablets or smartphones requires support for Python and PyQt on > those platforms. Iirc, Ville created a Leo reader for Android, but I > could be mistaken > >> >> *I would suggest that Leo's future lies in a complete rebuild, cloud from >> the ground up. Firstly, a decent API into a cloud-based Leo engine. >> Secondly, decent GUI clients on Web (Ember.JS? Pyjamas? AngularJS?) and >> Android/iOS.* >> > > What to say about this... > > Perhaps the best analogy for this kind of product is the split of IPython > into the Jupyter project: https://jupyter.org/ > > The IPython/Jupyter project is one of the most successful Python project > in existence. It has received millions of dollars of research funding over > the years, including a large recent grant of over $6 million, iirc. > > There is a huge amount of engineering in this project--far beyond my > ability. In particular, I call your attention to the security model. It's > crucial for this project, and it's crucial that it be absolutely solid. I > am not in a position to undertake any kind of security-related code. > > In theory, one could imaging forking IPython/Jupyter into a Leo-centric > project, but forking other people's projects seldom ends well. And I don't > have any energy for this. > > Alternatively, one could imagine trying to convince the Fernando Perez to > add Leonine feature to Jupyter, but I would not be interested if I were he > :-) There's too little overlap of purposes. > > The cloud-based paradigm, for me, would do away with the concept of a leo >> "document". Instead, it would focus on a 'view', which may contain one or >> more nodes. Nodes would exist outside of views, and be able to reference >> other nodes recursively. >> > > Not a bad idea, but I have no magic wand to make it happen. > > > The APIs could then be supported by widgets in the main client-side >> toolkits, to allow web apps to embed Leo editing widgets with ease. >> >> Files are where it gets tricky. Non-Leo-users absolutely detest the Leo >> sentinels. But updating a node tree to reflect changes in a file outside >> Leo is a programming task beyond merely painful. >> > > And other people's files are what make security so important. > > Weren't you the one who pointed this out years ago? Or maybe it was Paul > Patterson. > > >> However, if Leo is >> >> made to be as team-friendly as Google Docs (where you can even see >> teammates' cursors in different colours moving around the document), there >> will be virtually no need to edit files from outside the Leo environment. >> >> > Again - desktop is dying. Leo *has* to go cloud! >> > > Desktops aren't dead yet, and won't likely fade away until well after I > personally am gone. > > I will consider porting Leo in the cloud when easy to use tools for doing > so exists. I don't believe I will long enough to move Leo to the cloud > with the existing tools. > > Edward > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
