Bug in the paste-retaining-clones prototype

[Edward K. Ream]

The createOutline function does not take into account changes to cloned nodes that occur between copy-json and paste-rc.  For example:

1. Select @button copy-json.
2. Press the copy-json button.
3. Add a new node as a child of any "common code" node.
4. Press the paste-rc button.
5. The newly-created node no longer exists.

This is another example of clone conflicts.

Presumably createOutline function could check for conflicts. Imo, it should handle conflicts without asking for help from the user.  Alerts just create panic :-)

This is not a gotcha in the prototype code.  Indeed, it should be much easier to handle conflicts in the new code.

Edward

[Edward K. Ream]

On Tuesday, April 24, 2018 at 7:30:18 AM UTC-5, Edward K. Ream wrote:

The createOutline function does not take into account changes to cloned nodes that occur between copy-json and paste-rc. 

In another thread Terry points out that the following will probably fail for some uA's.

def copyOutline(p):
    g.app.gui.replaceClipboardWith(json.dumps(p2list(p)))

def p2list(p):
    return [p.h, p.b, p.gnx, p.v.statusBits, p.v.unknownAttributes, # <---- may cause problems.
             [p2list(p2) for p2 in p.children()]]

Again, not a gotcha. Again, the complications may be more easily handled in the prototype code.

Edward

[vitalije]

On Tuesday, April 24, 2018 at 2:30:18 PM UTC+2, Edward K. Ream wrote:

The createOutline function does not take into account changes to cloned nodes that occur between copy-json and paste-rc.  For example:

I thought it is what user would expect. I would be surprised if for example paste-retaining-clones create no effect (in case single node is copied, then changed body or headline and then paste-retaining-clones will have no effect at all).

It won't be any more difficult to implement such behavior but, I am not sure that it is what user would expect.

Vitalije. 

[Edward K. Ream]

On Tue, Apr 24, 2018 at 8:10 AM, vitalije <vita...@gmail.com> wrote:

The createOutline function does not take into account changes to cloned nodes that occur between copy-json and paste-rc.  For example:

I thought it is what user would expect.

​I'm not sure what the user should expect ;-)

Heh.  You could say that my report is only a prototype.​

 

​The more interesting case is copy in one outline, followed by paste-retaining-clones in another outline.

We don't have to resolve this question now.  However, it affects #863: Serious problems changing branches

As fun as this prototype is, I'm going to turn my attention to #863.  Perhaps some new insight or invention will appear. 

Edward

[vitalije]

​I'm not sure what the user should expect ;-)

 

> I'm not sure what the user should expect ;-)

Most often there is no possible conflict at all, because a node is copied to be pasted somewhere (as a clone) right away. The only case when this dilemma matters is when user changes some part of a copied subtree, before performing paste. Now, we can decide what should happen in this kind of situation and here are some reasons that I can think of why it would be better to give priority to the clipboard content.

1. By definition,content in clipboard is well defined and linked outline. If copy-outline works as expected it places on the clipboard tree of properly linked nodes. If it is pasted as it is, in its entirety, then the resulting tree will be also well linked and correct. If OTOH, we decide to give the priority to the current state of corresponding nodes, then we will be pasting  data from clipboard partially and there is no guarantee that the partial content of clipboard is well linked tree of nodes as one would expect. It opens the door for bugs and potentially inconsistent tree states. 
2. The basic idea of clipboard (as I understand it) is that user takes the snapshot of selected data and place it somewhere for later use. I don't know of any other editor that performs some kind of clipboard manipulation which results in the snapshot being altered after it was copied. Some editors do have commands to add current selection to the content of clipboard, but they do not change the inner content of the previous snapshot. Snapshots that are placed on the clipboard are always considered to be immutable. 

About possible problems in encoding unknownAttributes, I didn't  want to complicate the prototype with it. But here is few more thoughts about it.

First of all, it would be enough to use python pickle module to encode uA dictionary and then to put base64 encoded value in place of uA when copying outline to clipboard, and when pasting to decode this value accordingly. The other possibility is to give up json and use only pickle module to encode/decode clipboard data.

Now, I would much prefer the other solution. There are already some restrictions regarding what types of content users are allowed to put in this dictionaries and I haven't noticed any complains on this forum about those restrictions so far. It seems to me reasonable:

• to let users do their own ecoding/decoding of any exotic data types they might want to use and
  
• to impose even more restriction on the types accepted by uA.
  

That would be my preferable way to deal with this issue. If we agree on this rule, string representation of outline would be more human readable and that is something I've been told that we care about when we discussed sqlite as a file format.

Most of general python data types like sets and tuples can be represented well enough in json. The only necessary thing that user must do is to add one function call before using data retrieved from uA. For dictionary keys which might be tuples in python, one can use repr(tuple) to transform tuple in string and use that string as a key. After retrieving such key it can be turned again into python tuple using ast.literal_eval

Vitalije

[Edward K. Ream]

On Wed, Apr 25, 2018 at 1:02 PM, vitalije <vita...@gmail.com> wrote:

> I'm not sure what the user should expect ;-)

Most often there is no possible conflict at all, because a node is copied to be pasted somewhere (as a clone) right away. The only case when this dilemma matters is when user changes some part of a copied subtree, before performing paste. Now, we can decide what should happen in this kind of situation and here are some reasons that I can think of why it would be better to give priority to the clipboard content.

​Thanks for all these comments.  The original bug has been fixed to my satisfaction.

Please submit an enhancement issue if you would like to continue on this project.  That would be a good place for these kinds of notes.

Edward