Add copy and paste to tabs in the CDI display #231
Conversation
bobjacobsen
changed the title
| // First, find the prefix we're going to change | ||
| List<String> list = java.util.Arrays.asList(newContentLines); | ||
| String prefix = Utilities.longestLeadingSubstring(list); | ||
| // That prefix should end with "(1)." |
There was a problem hiding this comment.
This is probably not the case when the group has only one entry -- we will get the entire key of that first entry.
There was a problem hiding this comment.
Not sure of that. Is this non-replicated group in the RR-CirKits Tower LCC the kind of thing you were thinking about? It works OK.
<segment space="251">
<name>NODE ID</name>
<group>
<name>Your name and description for this node</name>
<string size="63">
<name>Node Name</name>
</string>
<string size="64" offset="1">
<name>Node Description</name>
</string>
</group>
</segment>
There was a problem hiding this comment.
Never mind, that's CDI clause above isn't in a tab. Working on this more...
There was a problem hiding this comment.
This is resolved by the use of rep.key below.
There was a problem hiding this comment.
The counterexample I meant is when there is only one field within the repeated group:
<group replication="4"><name>something</name> <repname>foo</repname>
<int size=2><name>hello</name></int>
</group>
as here the longest prefix will be the entire first key, i.e. something.entry(1).hello
It gets even nastier when we have a single nested group below a replicated group.
<group replication="4"><name>something</name> <repname>foo</repname>
<group><name>else</name>
<int size=2><name>hello</name></int>
<string size=20><name>world</name></int>
</group>
</group>
because here the copy-paste items are going to be like
something.entry(1).else.hello
something.entry(1).else.world
I don't have a very good suggestion on how to fix this. Ideal would be if we could know what the rep.key is on the other side, when it was copied. Barring that we could do something with counting the number of dotted components. We are looking for the following property:
- what we cut off must be a common prefix (=> prefix of the longest common prefix)
- The thing we cut off ends with ")."
- when we take the remaining lines after the cut-off, the average number of dots per line is the same as the average number of dots in the previousContentLines, when we take off rep.key as prefix from each line.
It's probably OK to not block this PR on resolving this problem, but fix it in a followup. It already does work for the most common cases (copying inputs and outputs).
There was a problem hiding this comment.
Maybe the simplest fix is to cut back prefix to end with ")."
|
I'm working on updating the CDI processing to handle the Can we get this PR merged please? |
| @@ -1209,12 +1212,15 @@ protected void performGroupReplPaste(int index, ConfigRepresentation.GroupRep re | |||
| List<String> list = java.util.Arrays.asList(newContentLines); | |||
| String prefix = Utilities.longestLeadingSubstring(list); | |||
| // That prefix should end with "(1)." | |||
| System.out.println("Prefix: \""+prefix+"\""); | |||
There was a problem hiding this comment.
consider switching debug printouts to log statements (or deleting them) so that we don't clutter stdout.
There was a problem hiding this comment.
I've removed those.
| // First, find the prefix we're going to change | ||
| List<String> list = java.util.Arrays.asList(newContentLines); | ||
| String prefix = Utilities.longestLeadingSubstring(list); | ||
| // That prefix should end with "(1)." |
There was a problem hiding this comment.
The counterexample I meant is when there is only one field within the repeated group:
<group replication="4"><name>something</name> <repname>foo</repname>
<int size=2><name>hello</name></int>
</group>
as here the longest prefix will be the entire first key, i.e. something.entry(1).hello
It gets even nastier when we have a single nested group below a replicated group.
<group replication="4"><name>something</name> <repname>foo</repname>
<group><name>else</name>
<int size=2><name>hello</name></int>
<string size=20><name>world</name></int>
</group>
</group>
because here the copy-paste items are going to be like
something.entry(1).else.hello
something.entry(1).else.world
I don't have a very good suggestion on how to fix this. Ideal would be if we could know what the rep.key is on the other side, when it was copied. Barring that we could do something with counting the number of dotted components. We are looking for the following property:
- what we cut off must be a common prefix (=> prefix of the longest common prefix)
- The thing we cut off ends with ")."
- when we take the remaining lines after the cut-off, the average number of dots per line is the same as the average number of dots in the previousContentLines, when we take off rep.key as prefix from each line.
It's probably OK to not block this PR on resolving this problem, but fix it in a followup. It already does work for the most common cases (copying inputs and outputs).
| // First, find the prefix we're going to change | ||
| List<String> list = java.util.Arrays.asList(newContentLines); | ||
| String prefix = Utilities.longestLeadingSubstring(list); | ||
| // That prefix should end with "(1)." |
There was a problem hiding this comment.
Maybe the simplest fix is to cut back prefix to end with ")."
This adds a contextual menu (right click, ctrl click) to tabs in the CDI display that contains "Copy" and "Paste" options. Copy and paste works both within one window and across windows. You can only paste into a tab of the same type from which you copied. The data stored in the clipboard is in the format of the usual backup files.