> > >>> 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 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
