I suppose every project that uses Leo to organize and edit source files has 
this problem. In some of my (still unpublished) projects I used Leo and 
wanted that every co-worker also uses Leo at least to browse source code. I 
used to prefer files without sentinels so I have mostly used `@clean` for 
external files. Very often my Leo files contain scripts for publishing some 
files to server using (s)ftp or other kinds of communication protocols. 
Naturally I don't want to type password every time so passwords and 
usernames are hard-coded in scripts. To prevent myself pushing some of this 
private data (like passwords and usernames), I have configured my private 
Leo file to be ignored by versioning system. For synchronizing public Leo 
document, I have written script that uses leoBridge to open both public and 
private Leo file and copy all at-clean files from private to public outline 
and then save public file. This solves my problem partially. If script is 
allowed to copy any @clean file found in my private outline to public one, 
then the script is responsible for deciding where to put newly added file. 
Simplest is to put it as last top-level node. However, if I want to have 
files organized in some intelligent way, I must either make my script 
smarter and more specialized for given project or to edit manually public 
outline. Both of this scenarios are less than optimal. 

If we want Leo to be more often used as preferable IDE for other projects, 
I believe one of the crucial problems we have to properly solve is this 
one. How to enable easy collaboration of developers that use Leo and those 
who still don't. Having `@clean` files that can be automatically refreshed 
is a big plus, but I am afraid it isn't enough.

We devs have no business telling people how to organize their outlines! 


I can agree with you on this, but unless someone with the experience of 
using Leo as IDE, shows to non-Leo-experienced developer an easy, not 
stressful way to incorporate Leo in his project and how to gently introduce 
it to his collaborators, I doubt that Leo will gain much more popularity.

I really want to use Leo and to set it as preferred IDE for my project(s), 
and I still have troubles in organizing workflow in a way that guarantee 
all project parts being in sync. How on earth, am I am going to convince 
anyone else that using Leo for project IDE is/(will be) beneficial?

As I stated earlier, this proposal can be implemented as a plugin. I think 
I am going to write this plugin at least for my own projects.

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to