Leo Write-Only Mode

[k-hen]

Is it possible to configure a non-sentinel file to be write-only?

The file sync is making me very nervous because (and I'm sure I did something wrong) the file didn't import correctly and blew away my changes. Fortunately I had a backup but this just isn't acceptable for me :-/

What I think is happening is that the file can't write or writes partially, then I have to kill Leo for one reason or another, then it's importing that incorrect file and wiping out my changes.

If I can't figure out a way around this, it's a deal breaker for me unfortunately :-(

[Thomas Passin]

Please describe exactly what you are doing.  See if you can come up with a very condensed example (a small file with only a few nodes, for example).  What do you want to achieve, what did you expect, and what actually happened?

Bear in mind the the entire Leo code base is contained in a few Leo outlines, many people every day open those outlines that contain thousands of @file files, and don't have these kind of troubles.  Of course, that's not importing.  But - ask Edward - entire trees of code get imported into Leo all the time, too.

So it's probably just that you have something amiss in your picture of how things work.  Let's help you get that straightened out.  Gotta start simple!

[Félix]

If I may suggest : A quick [Alt+PrintScreen], on any OS, will capture the currently focused program window as a picture.

Under windows, its in your clipboard so you can just CTRL+V  to paste right in here while you type. Like this: 

(In linux its put into your home/picture folder. )

So I would recommend you paste one before, and at each step of the behavior/actions you're trying to illustrate with your textual description. This will allow experienced users to spot instantly some details that explains the behavior you're experiencing while using Leo. 

--

Félix

Edit: typos

[percepti...@gmail.com]

My sincerest apologies if I came off too alarmist with this message,
this is an awesome community and Leo is a truly amazing tool and
ecosystem. Rest assured I'm certain the problems are with *me* and not
the software :-)

I still believe there would be a huge amount of value in a file type
that is write-only and not synchronized with the filesystem. In fact I
want to pick up changes with many small @auto nodes and then clone the
content of those nodes and embed them into *multiple* separate @write
nodes and thus avoid the 'clone wars' (among other things).

I think the @rst directive maybe does this and perhaps the @adoc one
can do that too, but it wouldn't really solve the whole issue since
some of the output files would include additional file formats.

I'll try to put together a simple walk through and use case.


Thanks again for your patience.


Kevin

On Thu, 2020-08-20 at 13:13 -0700, Félix wrote:
> If I may suggest : A quick [Alt+PrintScreen], on any OS, will capture
> the currently focused program window as a picture.
>
> Under windows, its in your clipboard so you can just CTRL+V to paste
> right in here while you type. Like this:
>

> (In linux its put into your home/picture folder. )
>
> So I would recommend you paste one before, and at each step of the

> behavior/actions your trying to illustrate with your textual

> description. This will allow experienced users to spot instantly some
> details that explains the behavior you're experiencing while using
> Leo.
> --
> Félix
>
>
>

> --
> You received this message because you are subscribed to a topic in
> the Google Groups "leo-editor" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/leo-editor/yo1p0tkOCDg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> leo-editor+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/292fb4c0-aea6-48d8-9062-df042d4d2c00o%40googlegroups.com
> .

[k-hen]

I'm feeling pretty stupid right now, I think this is what @asis & @nosent are for and I just missed it - even though I was staring right at it.

I've heard comments to avoid these and they're flagged as not 'recommended' and so was just dismissing them without consideration.

I'm not sure if there are particular reasons *why* they're not recommended but I'll go ahead and give them a shot.

Humbly yours,

Kevin

[Thomas Passin]

It would help if you explained just what you are trying to accomplish and why.

[Edward K. Ream]

On Thu, Aug 20, 2020 at 1:20 PM k-hen <percepti...@gmail.com> wrote:

Is it possible to configure a non-sentinel file to be write-only?

Yes. It's called @nosent.

Edward

[Edward K. Ream]

On Thu, Aug 20, 2020 at 1:20 PM k-hen <percepti...@gmail.com> wrote:

The file sync is making me very nervous because (and I'm sure I did something wrong) the file didn't import correctly and blew away my changes. Fortunately I had a backup but this just isn't acceptable for me :-/

There are many ways around this kind of problem.  For initial imports, I recommend using a recursive import script. The c.recursiveImport method provides the support for the following script:

'''Recursively import all python files in a directory and clean the result.'''
@tabwidth -4 # For a better match.

dir_ = r'<<path to the root directory>>' <----- change as needed
g.cls()
c.recursiveImport(
    add_context=True,  # Override setting only if True/False
    add_file_context=False,  # Override setting only if True/False
    dir_=dir_,
    kind = '@clean', # '@auto', '@clean', '@nosent','@file',
    add_path = True,
    recursive = True,
    safe_at_file = True, # Creates @@clean instead of @clean
    theTypes = ['.py', ] # ['.py', '.rs', '.ts', '.js','.vue',], #etc.
)

This script only adds to your .leo file. It never changes existing nodes.

If you import to @clean nodes, you should definitely use something like git to control the original files. After writing the new @clean nodes, you can use git to revert any unwanted changes. Then you reload Leo, and manually tweak the @clean nodes. Repeat until writing the files does not change anything.

Important: Both @clean and @auto perform strong "perfect import" checks. If for any reason these checks fail, Leo will insert @ignore nodes, to prevent unwanted changes when you change the .leo file.

In short, Leo provides significant protection for your files. However, I recommend using git to provide an additional level of safety.

Edward

[Edward K. Ream]

On Thu, Aug 20, 2020 at 4:50 PM k-hen <percepti...@gmail.com> wrote:

I'm feeling pretty stupid right now, I think this is what @asis & @nosent are for and I just missed it - even though I was staring right at it.

No need for apologies! There is a lot to digest for newbies.

I've heard comments to avoid these and they're flagged as not 'recommended' and so was just dismissing them without consideration.

I'm not sure if there are particular reasons *why* they're not recommended but I'll go ahead and give them a shot.

I don't recommend @nosent or @asis because they are much harder to use than @file, @clean and @auto. Leo's automagic reloading of @clean files is what you want if you can't tolerate Leo's sentinels. If you can tolerate Leo's sentinels, then @file is bullet-proof.

I know from first-hand experience that getting @clean nodes to be as one wants can take significant work when Leo's importers are up to snuff. I've recently beefed up the C (C++) and typescript importers because importing to @clean wasn't as easy as I would have wanted.

Edward

[k-hen]

Thank you for the import script and the responses.

I feel like maybe I'm missing something with @nosent though, why is it much harder to use?

Let's say I have a directory of files that are each templated, i.e. possibly having a header and footer.

These files are checked into git and synchronized using @auto nodes and can both be edited and read _into_ Leo when changes occur, e.g. after git pulling.

Then I can clone the body (inner section) of these nodes and write them out somewhere else using an @nosent file.

Never would I want a change to this output file to be read back _into_ Leo.

This file is local only and would not be checked into git, it could be deleted and would always be overwritten.

As you know, Git prefers small files rather than large ones and this one could be quite massive and treated as a 'large file' and therefore lose certain functionality.

Sure a script could do this too, but it's a poor man's version of using includes.

Another issue I have is that this file is going to be quite _deep_ and html/markdown/asciidoc all have a maximum of 0+5 levels of section depth,

so when *every* level of nodes writes as a section to the file then it breaks the output,

so I need to be able to treat some nodes as sections and some as just body content.

I've also decided that I can write my comments to file comments, so that Leo can write the whole subtree, even if i don't want to publish all of it.

This large output file is only a temporary step because it would be transmuted before distribution and so asciidoc would exclude those comments.

Kevin

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:08 AM k-hen <percepti...@gmail.com> wrote:

I feel like maybe I'm missing something with @nosent though, why is it much harder to use?

Clones are fragile in @auto trees, even when @persistence is enabled.

Also, so-called cross-file clones can be problematic, due to a fairly nasty version of the multiple update problem.

It sounds to me like a script-based solution might be best. You could, say, populate some specially marked nodes (of your own choosing) with content. Examples might be @header and @footer.

Edward

[vitalije]

On Friday, August 21, 2020 at 4:08:35 PM UTC+2, k-hen wrote:

Thank you for the import script and the responses.

I feel like maybe I'm missing something with @nosent though, why is it much harder to use?

Let's say I have a directory of files that are each templated, i.e. possibly having a header and footer.

These files are checked into git and synchronized using @auto nodes and can both be edited and read _into_ Leo when changes occur, e.g. after git pulling.

Then I can clone the body (inner section) of these nodes and write them out somewhere else using an @nosent file.

Never would I want a change to this output file to be read back _into_ Leo.

This file is local only and would not be checked into git, it could be deleted and would always be overwritten.

As you know, Git prefers small files rather than large ones and this one could be quite massive and treated as a 'large file' and therefore lose certain functionality.

Sure a script could do this too, but it's a poor man's version of using includes.

You can try md_docer plug-in or write your own scripts using the code from md_docer as an inspiration.

In almost all my Leo documents now, the first thing I do is to add a node with the headline '@button nsave @key=Ctrl-s'. So, whenever I press Ctrl-s to save my Leo document, script in this node is executed. There is alwayas a 'c.save()' line in this script, so that the document is saved, but then my script writes all nodes that need to be written in some special way. For example, nodes whose headline starts with '@coffee ...', are compiled with the coffee compiler, '@pug' nodes are compiled with the pug compiler, @css nodes are compiled with sass compiler, ... The limit is just your imagination. You can easily write your nodes without sentinels and Leo won't try to read file and synchronize Leo. Actually I don't have coffee, scss, pug and other types of files that are considered to be source files. I have just compiled versions written as a real files.

HTH Vitalije

[k-hen]

Ok, thanks. So 1: there doesn't seem to be an inherent issue with @nosent, it's just that doing so in conjunction with cloned nodes from @auto could be unstable.

Re: the 'multiple update problem', I was thinking this would have to do with multiple read/write nodes which is why i was trying to build a stream with 1 reader and multiple writers.

Is there something else here to be aware of?

I can/will look into scripting though but that seems to really up the level of difficulty, not so much for my benefit, but for others I might want to share this with.

[k-hen]

Thanks Vitalije, I'll have a look at that - thanks!

Pardon the beginner question, but are you defining @coffee, @pug, etc yourself?

Why not @md then instead of md: on the headline?

Either's fine of course, just trying to understand the differences and the best practices.

I'm trying to use asciidoc over markdown because it seems to be a middle ground between rst (too complex) & md (too simple).

Mainly because it has *comments*,  *includes*,  simpler tables, and broader language support beyond Python.

It's extremely similar to markdown and even the markdown headers work (#) so hopefully they'll eventually become more or less compatible someday.

Markdown is of course much more common though and its editor support and ecosystem is quite nice these days.

Kevin

[Edward K. Ream]

On Mon, Aug 24, 2020 at 7:51 AM k-hen <percepti...@gmail.com> wrote:

Re: the 'multiple update problem', I was thinking this would have to do with multiple read/write nodes which is why i was trying to build a stream with 1 reader and multiple writers.

Is there something else here to be aware of?

No.

Edward

[vitalije]

On Monday, August 24, 2020 at 3:15:50 PM UTC+2, k-hen wrote:

Pardon the beginner question, but are you defining @coffee, @pug, etc yourself?

Why not @md then instead of md: on the headline?

Either's fine of course, just trying to understand the differences and the best practices.

 

Yes I am. Why not @md? There is no particular reason at all. A monkey sign is usually signaling some special meaning in Leo outlines, but it is just a convention. If you write your own script you can choose whatever scheme you like. I guess it would be better if instead plain `md:` I used `@md`, but either one has just a simple purpose to mark somehow nodes that I want to be processed.

Vitalije

[k-hen]

Ok, makes sense, thanks.

[Thomas Passin]

Don't forget, viewrendered3 already uses @rst, @md, and @asciidoc.  Please don't make these mean something else.

[k-hen]

Right, good point!, thanks Tom :-)