Use @clean. While not automatic, it preserves structure in your .leo
file instead of using sentinels. That solves half of the problem.
But I agree, many filetypes are simply not able to be automatically
imported with any real sense of meaning.
-->Jake
On 8/18/2015 3:59 PM, David McNab wrote:
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]
<mailto:[email protected]>> wrote:
On Mon, Aug 17, 2015 at 8:17 PM, David McNab
<[email protected] <mailto:[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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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.
