expected behavior for removing spaces before lines outputed by an indented '@others'

[Félix]

In a simple outline with an @clean node containing an indented @others such as this: 

Let's say there's a couple lines of text in the 'inside node' body pane. The external file will have those lines indented with as much space as there are before the @others in the parent node.

What is the expected behavior when I remove the indentation of the line produced by the @others in the external file, and save it as such to be picked-up by Leo and have it refresh that outline from file? will the @others be unindented? or will the @others stay at its position, and the inside node content be empty and with it's now unindented line appear below the @others?

In any case, none of this happens. So i'm wondering what's going on? (was it always this way? or is this a new intended/unintended behavior?)

Félix

[Thomas Passin]

My expectation is that all lines in the @others subtree will be additionally indented by the indentation of the "@others" string.  That's how I have always used it.  I just tried it out in a little outline similar to yours, and that's what I saw in the external file.  So if the @others line is not indented, the @others subtree lines are not either.

[Félix]

Thank, but the unexpected behavior I tried to verify is when removing the indentation in the external file itself externally  (with a file editor of your choice) and then saving it, to have Leo refresh it from file by answering 'yes' to the dialog that appears when you do so.

[Thomas Passin]

Oh, I see.  If it's an external file with sentinels it could be tricky because you'd have to unindent the correct block the right amount, sentinels and all.  I just succeeded  with an @file tree, but it would be easy to mess it up.  I converted the file to an @clean file and when I unindented the line in the external file that was in the @others subtree (I mean using an external editor), the "@others" line in the Leo outline did not get unindented as one would expect.

Tricky!

[Félix]

Yes. This inquiry only concerns @clean, not @file. 

When being refreshed from file after unindenting a line coming from an indented @others node, I would have expected the first line encountered (being unindented past the indentation of it's originator @other node), to be considered the first line to be after the @other node content. (as it cannot be from the original indented @other node, therefore it should be seen as a new content for after the @other directive. (along with all it's following lines in that node's output).

A 'ctrl+s' following that refreshing does not trigger it being re-written, as leo seems to consider this not being a 'dirty' state... so that behavior does not have an explicit apparent drawback.. but it's still there! hehe...

And so i'm wondering if it's the intended behavior..., and so I thought I'd ask people in this forum about their thoughts on that matter :)

Félix

[Edward K. Ream]

On Fri, Jun 23, 2023 at 1:39 PM Félix <felix...@gmail.com> wrote:

In a simple outline with an @clean node containing an indented @others such as this: 

Let's say there's a couple lines of text in the 'inside node' body pane. The external file will have those lines indented with as much space as there are before the @others in the parent node.

What is the expected behavior when I remove the indentation of the line produced by the @others in the external file, and save it as such to be picked-up by Leo and have it refresh that outline from file?

Imo, there  is no "intention" involved. You'll get what the @clean update algorithm gives you. That algorithm isn't going to change.

Edward

[Edward K. Ream]

On Saturday, June 24, 2023 at 5:54:02 AM UTC-5 Edward K. Ream wrote:

>> What is the expected behavior when I remove the indentation of the line produced by the @others in the external file, and save it as such to be picked-up by Leo and have it refresh that outline from file?

>Imo, there  is no "intention" involved. You'll get what the @clean update algorithm gives you. That algorithm isn't going to change.

Many years ago, when Bernhard Mulder first proposed @shadow, I hesitated to adopt his proposal because I didn't realize that it didn't matter if the update algorithm made slight "mistakes". That is, there is no way, in principle, for the update algorithm to assign a line to the "proper" node if that line could be assigned either to the end of one node or the beginning of the following node. At last I understood that:

1. Writing the @shadow tree would create the same result either way.

2. The user could put the line in the "proper" node if they liked.

    Thereafter Leo would always put the line where it belongs.

Similar remarks apply to @clean. The user can always adjust nodes, including @others directives, as they like.  In short, edge cases involving @others don't matter.

Edward

[Félix]

Very good. 

yes indeed, I dont want to modify the algorithm, and I also see advantages to the current behavior.  (which i didn't take time to mention in the posts above)

  But in essence, as I was making sure leojs was behaving properly, i thought i'd ask if this is working as expected in Leo as per the Bernhard Mulder algorithm. (because i'm getting the same behavior in leojs - meaning i translated properly , hehe ) and that the algorithm was not mistakenly/accidentally changed in the last few years - thus, that this is the intended, original behavior of the Bernhard Mulder algorithm.

Thanks for your explanations, hope i cleared the confusion that I may have started by not being explicit enough in my original inquiry from my above posts.

Félix

[Edward K. Ream]

On Sat, Jun 24, 2023 at 12:44 PM Félix <felix...@gmail.com> wrote:

 I was making sure leojs was behaving properly,

 

No problem.

One more thing. Your example is somewhat contrived because indented @others statements are bad style unless they occur in a context where indentation is expected.

Good style:

class MyClass

    @others

if QtGui:

    << define QtGui classes >>

Bad style:

line 1

line 2

    @others

line 3

line 4

HTH.

Edward