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 firstname.lastname@example.org. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.