Okay, I will file this tomorrow. Distilling more coherently my findings
from this post.
On Tuesday, April 26, 2016 at 8:13:32 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, Apr 26, 2016 at 7:00 PM, john lunzer > wrote:
>
>> Additionally, renaming a non-@ parent node will recursively set all
>> @ c
On Tue, Apr 26, 2016 at 7:00 PM, john lunzer wrote:
> Additionally, renaming a non-@ parent node will recursively set all
> @ child nodes to dirty.
>
Whatever the merits of this, messing with the recursive methods is too big
a change for 5.3. I think this merits bug report. Feel free to file i
Additionally, renaming a non-@ parent node will recursively set all
@ child nodes to dirty. In my use of chapters this happens often. I
will rename a chapter, or turn a node into a chapter and then all @
nodes under that (new) chapter will have to be saved because they've been
set dirty. This s
Sorry, see my previous follow up post for correct details.
On Tuesday, April 26, 2016 at 12:53:39 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, Apr 26, 2016 at 10:17 AM, john lunzer > wrote:
>
>> Perhaps I should have been more specific. Marking is triggering a
>> recursive dirty setting regardles
On Tue, Apr 26, 2016 at 10:17 AM, john lunzer wrote:
> Perhaps I should have been more specific. Marking is triggering a
> recursive dirty setting regardless of node type.
>
Not in my tests. Can you give an example?
EKR
--
You received this message because you are subscribed to the Google G
It appears this is not fully true.
Marking a non @ parent node only sets @ child nodes recursively
to dirty, non @ nodes are recursively left clean. So If the non
@ nodes are left alone, why not also leave the @ nodes alone? I
am trying to understand the inconsistency.
On Tuesday, April 26, 20
Perhaps I should have been more specific. Marking is triggering a recursive
dirty setting regardless of node type. There is no reason marking a non
@ parent node should set all child nodes (@ or not) dirty. In
this case the parent has no bearing on the content or position of the child
nodes so
On Mon, Apr 25, 2016 at 4:33 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:
> On Mon, 25 Apr 2016 13:16:08 -0700 (PDT)
> john lunzer wrote:
>
> > I think "dirty" is the right word, basically Leo thinks the file was
> > altered. Not only does it do this for the current node
On Mon, Apr 25, 2016 at 7:27 PM, john lunzer wrote:
>
"mark finds" should probably set the nodes to dirty (for the sake of
consistency)
I'll look into it.
>
There is no reason marking a parent node should set all the children dirty.
Yes, there is.
p.setAllAncestorAtFileNodesDirty is
My analysis of the situation is that this behavior is inconsistent. When
you choose "mark finds" when using the find command any marked nodes are
not set to dirty. I understand that the .leo file changed and that one
might want those markings saved. That does not cause issue or trouble.
I see
On Mon, 25 Apr 2016 13:16:08 -0700 (PDT)
john lunzer wrote:
> I think "dirty" is the right word, basically Leo thinks the file was
> altered. Not only does it do this for the current node but it will
> also do it recursively for all child nodes.
Not sure if that's considered a bug or not. in
I think "dirty" is the right word, basically Leo thinks the file was
altered. Not only does it do this for the current node but it will also do
it recursively for all child nodes.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe fr
12 matches
Mail list logo
