Is It Time For A Leo Project File Format?

[tbp1...@gmail.com]

As I have been working on sending a Leo outline to a remote computer, I've realized that sending the outline doesn't send any external files or resources.  Resources might be css style files, images, or other files that are used by an outline.  This is also a problem when you want to simply copy a Leo outline to another computer.  For example, when I copy my workbook.leo outline to a new Linux VM, it won't include a lot of @file external files I have used for testing and learning purposes.

If you wanted to work on some program you were developing as a set of external files,  you would be out of luck unless you could also zip up the file structure and recreate it on the remote machine.

Programs like Word and LibreOffice files are really zip files that contain many project-related files, including images, icons, font descriptors, and of course, a representation of the text itself.  It occurs to me that it would be useful to have a project file like that for Leo outlines.

I don't know how feasible it would be to find all possible external resources.  For example, in a @rst node there might be a reference to an image file, or similarly in a VR3 node (which might use its own private @image directive to point to it).  But at least it should be easy enough to locate all external files.

In reconstructing external files when the project file is opened, there could be a problem with creating the file paths, especially if some of them were absolute.  Sometimes they cannot be converted to relative paths, or if they were, the program files might not work because their imports would be wrong after path conversion.

An example of a challenging path conversion might be this:  The main @file is on Windows, on the D: drive.  But it uses another file on the C: drive.  Now I want to move the whole project to a Linux machine.  How should these paths be converted?

Perhaps only certain projects could be made to work.  Perhaps others would need to be restructured. A lot of thought will be needed to work out the details.  But I think it would be worthwhile.  Other people must have faced this situation, haven't they?

[Edward K. Ream]

On Tue, Mar 15, 2022 at 12:35 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

The short answer to the question is no :-)

Imo, .leo files are better than typical project files: all data are in one place (the .leo file), most data are visible, and all data, including uA's, are accessible to scripts and plugins.

The problems you mention are real, but the solution is not some new file format.

Edward

[tbp1...@gmail.com]

I should perhaps written "additional" so as not to imply replacing the existing .leo files.

[Edward K. Ream]

On Wed, Mar 16, 2022 at 6:47 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

I should perhaps written "additional" so as not to imply replacing the existing .leo files.

I would not be in favor of project files, period.

Edward

[Edward K. Ream]

But plugins can do anything they like. I would encourage you to think "plugins", not "file format".

Edward

[Offray Vladimir Luna Cárdenas]

I usually keep my Leo files and its imported/exported files in Fossil repository[1] (kind of a GitHub in a box, with less impedance), all with relative links to the repository root where project files are located. Fossil's author propose SQLite as a file format [2][2a] and I think that single, self contained files with a powerful, light and portable SQLite database behind  Fossil repositories are the best incarnation so far of a project "format" I have been able to work with so far (despite most of the people knowing mostly/only Git). I have used Fossil extensively in my documentation projects since 2011, including Leo files talking with other files in the same repository.

[1] https://fossil-scm.org/
[2] https://sqlite.org/appfileformat.html
[2a] https://www.youtube.com/watch?v=8y_ABXwYtuc

So I second the idea of *not* needing a project format when Fossil is there, as it is one of the best ways to package project resources and their history in a single file, publishing such projects/resources and enabling collaboration. A recent example of such combination can be found at [3][3a][3b].

[3] https://mutabit.com/repos.fossil/malleable-systems/doc/trunk/wiki/en/malleable-systems-wiki--23fm1.md.html
[3a] https://mutabit.com/repos.fossil/malleable-systems/timeline
[3b] https://mutabit.com/repos.fossil/malleable-systems

Cheers,

Offray

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/1e45209e-4617-4160-98b1-6cbc63923cf3n%40googlegroups.com.

[tbp1...@gmail.com]

I have used Mercurial on my computer for some time.  But it just grew and I now have a lot of Leo projects scattered all over.  Some of them have absolute @paths, and some of those aren't valid anymore because they came from a different computer with a somewhat different organization (obviously these may have been inactive for some time!).  Reading @Offray's post has gotten me thinking about this subject.  For the time being, I don't see a reason to prefer Fossil over Mercurial (for my purposes), and I'm more familiar with Mercurial.

One thing I'm not so clear about:  Fossil is said to have just a "single" file.  Of course, there will be a working directory involved, too.  So far as I can can tell, the Hg record of changes is in a single .hg directory, but the working directory is needed to actually have the files.  So collecting the whole works in a single file would basically mean zipping up the working directory with its .hg repo.

I don't know about Fossil, but Hg treats XML files as binary files and doesn't to text diffs on them. I'm not sure if that can be changed or not.

I will be thinking for some time about organization and workflow, before I decide how to proceed.

[tbp1...@gmail.com]

It's been a long time since I tried it, and my current install of Hg doesn't seem to be having any trouble with a .leo file.  That's good! 

[Christophe Vermeulen]

I don't consider myself as a leo specialist, but I firmly believe that you should support Edward and Offray positions. If you would _Ever_ neet to embed .leo and external files together in something more powerful than a zip file, go for the SQLite app format, and don't DON'T reinvent a new incompatible one.

[tbp1...@gmail.com]

I agree with this too.  Probably a zip file, but anyway, something very standard.  The thing to work out would be what should be in the package.