Fix copy and paste

[snim2]

Copy and paste currently takes a sequence of selected nodes and converts them to text before pasting. It would be preferable to copy and paste the nodes directly. Care needs to be taken with language boxes.

/cc @ltratt @ptersilie

[ltratt]

This is an interesting UI issue, and it would be good to experiment with it. It's not 100% clear what the right answer is, so we need to keep an open mind.

The easy case is if someone selects plain old text within a language box: at the moment, we copy that as text, and the user can't really spot whether it was copied as a tree or text.

A somewhat easy case is if someone selects all of a language box (but nothing either side of it): it seems intuitively clear that we should copy the tree structure, so that it can be pasted back in and "remember the tree structure". [We can simplify this to "copy the language box terminal" which just so happens to have a tree structure inside it.]

Then we get to some hard cases.

What happens if we select half a language box? At such a point, we can't easily copy a tree, because the user selected a partial tree. One way is to continue doing what we currently do: squish stuff into text and paste things in later as text.

Similarly, imagine if I have something like var = SELECT age FROM table; + 18 where SELECT age FROM table is a language box. If I select only SELECT age FROM table, we're in our "somewhat easy case" from above. If I select var = SELECT age FROM table; + 18, I can copy out a whole sub-tree, and that's pretty easy too. However, if I select ar = SELECT age FROM table; + 1, life becomes a bit harder: I can't copy the whole var and 18 tokens directly.

This suggests to me that perhaps the fully right answer is to allow a) copying partial trees b) copying tokens with partial contents. But I'm not entirely sure this is the fully right answer. And I think even a half-way solution might be a bit better than what we currently have.

[ptersilie]

Agreed. My suggestion would be to always try to copy some (partial) subtree if possible and fall back to copying terminals otherwise.

Another thing we need to remember is that we still should put the copied area as normal text into the clipboard so it can be pasted into other programs. So Eco needs to have an internal clipboard that can copy and paste whole trees and the OS clipboard which contains a textual representation.

[ltratt]

I agree completely that we still have to copy plain text to the Unix clipboard.

Notice one thing I said though: copying terminals isn't completely obvious, because sometimes users select text that is only part of a terminal. What should the type of such a copied terminal be? I have absolutely no idea...

[ptersilie]

The type would be none and then the incremental lexer will take care of finding a type if possible. E.g. half of somevariable would still be an identifier. In most cases this would probably work, e.g. cutting <= into pieces still leaves you with two terminals that both have a type depending on the grammar. In all other cases the inclexer will assign a "none" type which will result in a syntax error.

[ltratt]

OK, that sounds sensible to me.

[ptersilie]

TODO:

• copy node: clones node
• copy partial node: create new node with partial text and None type
• copy multiple nodes: find common parent and clone subtree
• copy language box: clone language box*
• copy partial language box: create new language box with partial nodes*

* when pasting language boxes, only create new language box if target position is in another language, otherwise paste nodes/subtrees only. Problem: Languages that allow languageboxes with the same language as the parent

[snim2]

@ptersilie this one looks like it might be worth keeping?