I can certainly envision a useful use case that would allow me to select individual or multiple aliases as a shortcut means to copy the actual notes to another tbx document. Better still, the same for multiple selected aliases. Even better, copy a combination of selected notes and the notes corresponding to selected aliases to another tbx document.
1 Like
Yes: this is a good idea that had not occurred to me. It was raised a month or so back in a different thread.
2 Likes
I can see, for instance, that making an agent to find all notes of interest and pasting a list of all the child aliases into a new TBX (as new notes).
I assume the idea floated above is for a mixed selection of original and alias notes, the latter generated to make it easier to ājustā get the right selection to paste (the aliases becoming originals in the target TBX).
However, in concentrating on the task we are ājustā doing some assumptions/questions arise over things that might not pan out as intuited:
- if both original and aliases of the original are in the selection, are all items pasted?
- [edit] this didnāt really make sense.
- if a pasted alias matches a note in the target TBX, does it alias that note or make a new note (not with a duplicate $Name (possibly not our intent)?
- if pasting an agent and its child aliases what happens? Clearly, the agent may not match notes as before so would prune its aliases. Plus if pasted aliases become originals, originals cannot reside inside an agent container. Perhaps the co-pasted aliases get added as originals as siblings of the pasted agent?
These are a few of the issues on my jotter from testing current behaviour after the topic got raised on the original thread. They will all need testing/documenting for this possible new feature if taken forward.
I would only copy the original and ignore any corresponding aliases.
Iām not sure what you mean here ā what is a new original in this context?
Just to clarify, I would not paste any alias, only the original. As for matching in the target tbx, it depends on what the definition of match (sameness) means in this context. If you mean that a note already exists in the target with the same name, I think you would have to copy it. That is, the value of $Name should not be sufficient to determine a match as it is entirely possible that there can be two or more notes in a tbx that have the same name but whose difference is determined by their paths in the outline. Even if two such notes have identical attributes (except for attributes that can never be the same, such as id and date created), but have different positions (i.e., contexts) in the hierarchy of notes, then they are different. This does raise a vexing question of how to determine sameness of two notes that match share the same parent.
Obviously the Agent cannot itself be copied, but the elements of its result set could be, and would be copied as I have described before. But, that does raise the question of the location they are copied to in the target tbx. I argue that a container that corresponds to the Agent should be created in the target, and then the original notes corresponding to the alias be copied into that container. The container corresponds to the state of the Agent at the time of the copy. If the Agent is copied a second time, then a new container in the target is created and the originals are pasted as before. This container would be a peer to any non-alias originals that are part of the same copy operation. You could argue that all this will result in duplicates and is wasteful, but that would be a problem for the user to resolve.
A more sophisticated ā and useful ā solution would be to create aliases to any previously created original that were the result of a previous copy of the same agent. This, however, would need to account for the identity of the Agent and the identity of the tbx document that contained the agent (so as to preclude a collision of Agent copies). But this would best be left to workout after basic copying designed and implemented.
1 Like
Thanks for the clarifications/thoughts. Iād note my āquestionsā were not so much one personās use but what any user might do. Beta testingāand documenting featuresāinvariably throw up some unforeseen issues. Sometimes, these are logical but unwanted outcomes to be fixed, but occasionally accidental āmis-useā shows new and useful ways a feature might work.
Note: Iāve deleted my #2 bullet up-thread for, as you rightly point out it makes no sense as written and the context was actually unambiguous.
Yes, but only if we assume the original and alias are always siblings. However, some people copy whole sections (branches) of a TBX. The alias might legitimately be in a different container, and quite reasonably want (intuit!) that the aliases would also transfer and (intuit) the aliases would be re-created as aliases of the newly-made original. So what we intend is not necessarily unambiguous in the round and only building for one possible outcome may end up in an over-fitted solution that only suit a few users.
So the underlying question might be re-stated as: what is the intention when pasting an alias? The example just above shows that there is no single unambiguous assumption. In some contexts, you do want to paste originals and aliases of those originals (albeit aliases of the originalsā incarnation in the new documentā¦
In a way, weāve been here before when pasting notes using prototypesā where the ārulesā of what happens seem counter-intuitive at first encounter until we realise all the implicit (incorrect) assumptions in out intuited sense of the outcome.
Agents can be copied at present, and work logically in terms of function in the target TBX. See this simple test:
The reason I mentioned agents is a predictable case where the user inuits (wrongly, as at v10.1.2) that pasting the agent will create a container note [sic], not an agent, and holding new originals based on the child aliases of the source agent.
Iām reminded that still not fully documented are nuances between copy/pasting a selected expanded vs unexpanded container. Little differences can have unexpected consequences for those not expecting such nuance.
A hidden factor at play is that Tinderbox has no notion of merge (sync?) fro notes. So if note X is is both TBX documents A and B, there can be a desire to make the version in B the same as in A. For $Text and multi-value attributes this implies a need to (review and possibly) merge values. IOW, our intent is less simple than in the mindās eye. Our natural tendency is to reach for the ājustā¦ā qualification and to forget we often donāt actually do what state we will do (be it through error or misunderstanding to the context).
Indeed this plays into:
Whether we like it or not, if Tinderbox is asked to match on $Name, in the event of a dupe it always (re-)matches to the first match by outline order, be it in the same container or elsewhere in the document. The same holds for $Path, but there a duplicate can only occur for siblings of the same $Name. All inconsequential until is not the outcome we want in a given scenario of our own work.
This gets to the issue of merging content, something that Tinderbox, thus far, has not entertainedāfor perfectly good reasons. It is a single user desktop app. whilst it has always allowed multiple discrete TBXs there has never been a design expectation of synching/merging content. so, think it helpful to work forward from the status quo not back from desired output that isnāt first contextualised by the status quo. FWIW, Iād like the idea of merging notes cross-TBX but I suspect the ROI might be interesting. Is it enough that a few users might really want this? IOW is it a need for the community as whole or a convenience for some?
Another factor, these days, is scale. We used to have documents with 10s of notes, now it can be 0,000s of notes. The issuesāboth good and badācan vary depending on the scale of content in play.
Iām only digging into this as resolving the ambiguities here is useful beyond the immediate context. The advent of functions, libraries, has re-kindled the desire of some users to replicate whole structures between TBXs, in an app not originally built with that express intent. Thus there are a lot of unexpected issues to workaround or resolve.
ā . See Copying or Moving notes within Tinderbox, section on āPrototypes between documentsā.
1 Like
I completely agree with this. Clearly this problem is more subtle and complex that I originally considered.
1 Like
@mwra @rtalexander As someone who has given this issue a lot of thought over the past couple of months, Iād like to suggest that simple, consistent logic is what works best in dealing with notes copied and pasted between Tinderbox documents. Here are the behaviors that should apply for the various cases:
- Item being copied is an original note: This should effectively ācloneā the note from the source document into the destination document where it is pasted. Ideally, everything aside from positional attributes and some read-only system attributes like $ID should be identical for the pasted note. For the most part, this appears to be current Tinderbox behavior. As an aside, it would also be nice if lists like ā$DisplayedAttributesā would maintain the same list order in the pasted version as found in the original.
- Item being copied is an alias: While there could be several interpretations of what might be done, the only consistent action that makes sense is to paste a clone of the original note from the source document at the paste location in the destination document. This would behave exactly as for #1 above, but for the aliasās original. If the alias corresponds to a container, then follow the behavior in #4 below.
- Item being copied is an agent: The pasted result should be a copy of the original agent, but without any of the collected descendants of that agent from the source document. Once pasted, the agent query would then collect aliases of notes in the destination document. This appears to be the current behavior.
- Item being copied is a container comprising a document branch: In this case, the rules from above should be applied to each source item found in the copied container. However, aliases that are contained in an agent should be ignored, and only a clone of the agent should be pasted. Any aliases that are free-standing (i.e., not contained within an agent) should be pasted as a clone of the original note. Iterate on this logic for each subordinate container including for the case where the original note for an alias is in turn a container. As an aside, the paste behavior should be consistent to whatever outline depth is associated with the original copied container.
- Multiple items are selected for copy and paste: This should behave as though the multi-selection was encapsulated in an implicit container, and the paste operations should follow the behavior outlined under #4 above.
Should users want to modify the behaviors outlined above, then the new $OnPaste rule could be used to define a custom behavior.
Also, if there is a need to copy a set of aliases and have them pasted as clones of the corresponding original notes, then the aliases should either be multi-selected, or placed into a container that would not be an agent. Alternatively, an agent could be used to collect a set of notes as aliases, but then action code running in the source document could replicate the collected agents as new child aliases within a designated container which could then be copied and pasted into another document.
The primary motivation for being able to copy aliases as though they were the original notes is that this avoids situations where notes in the source document have to be duplicated in order to facilitate copy and paste operations to other documents. Duplicates can lead to confusion as to which is the latest or most correct version, whereas aliases avoid the necessity for duplication. In the case where action code, prototypes, templates, etc. are being copied to other documents, use of aliases is highly preferred as a means for selecting the items to be copied.
2 Likes
A use case related to ā but different from ā copying an original note to a target document via an alias would be to instead paste an alias-like entity (a hyperalias, if you will) into the target document. This hyperalias would provide an anchor (note) in the target that links back to the original note found in the source document. The objective here is, instead of copying an original note, establishing a hypergraph between the two documents via traversal to the original note via the hyperalias in the target.
1 Like
In my original post I failed to express the use case behind copying original notes corresponding to an agentās descendants is one of utility, allowing an agent to be used as a query mechanism for selecting notes. Doing this by hand could be laborious if the notes to be copied are not conveniently located to one another. Plus the difficulty of selecting notes according to complex criteria would easily be handled by the agent. In this use case the objective is not to move a copy of the agent into the target, just the notes that match the agentās query.
1 Like
In my replies to some of @echuckās comments I am not concerned with the syncing or merging of information, but instead of creating connections that will allow new knowledge to emerge. The knowledge of a graph of Tinderbox documents would be greater than the sum of the knowledge contained in the individual documents (at least it has the potential to be; YMMV).
1 Like
This makes sense. Making the agent and then selecting copying its contents is OK for 4 aliased matches, less so for 40 or 400. That said I donāt think there is a modifier key to expand a selection to all siblings (in that container, i.e. with a common parent, even in a root). I donāt think there is an OS shortcut for thisā . But if Tinderbox were to have one, then it would allow the existing agent copy/paste to behaviour to work yet still leave agents as a usual way to assemble a list of aliases to copy/paste (as a list, rather than via their container).
That would allow both desired behaviours to work for minimal extra effort when exporting agent-created aliases.
ā . ā + Shift + Down arrow would work in Finder but not Tinderbox as this hoists the outline focus on the selected ite,
This is interesting. The tinderbox:// pseudo-protocol (see) allows inter-TBX links, but we see very little discussion of their use. Do you cross-link TBXs a lot? If so it would be interesting to hear more (perhaps putting that in a separate topic/thread).
1 Like
BTW, one what Iāve gone about this is using attributes and action code to store the original notes position in a hierarchy, i.e., container structure. This structure can then be reproduced using action code. It is not that hard to do, but does take some consideration to get right.
1 Like
I agree that this would be a useful enhancement. I have actually teeād up some notes of my own on this as an alternative approach to moving Tinderbox items from one document to others. The key advantage of this approach is that it would allow automatic syncing of an original source note in one document to multiple other documents that āinheritā the original.
That said, my purpose in laying out desired behaviors for copying aliases was to suggest what I suspect would be minor enhancements to what we already have. Some incremental improvments would allow us to step forward without having to wait for more substantial evolution of Tinderbox.
I should also mention that my focus of concern is how to move action code, prototypes, templates, highlighters, taggers, and even user attributes and link types between documents in a rational manner. Relying on duplicates quickly runs into issues of inconsistency, and hence a need to have items defined by a single source item.
1 Like
My sense is that if one wants to use an agent to collect a bunch of notes in one document that can be copied and pasted into another document en masse, then selecting all of the collected aliases is pretty easy and they could then be copied and pasted into another document with the original source for each alias pasted. I believe this is consistent with @mwraās comments.
If an agent is subsequently pasted into the same destination document, then it should find the pasted alias originals. True, this might require multiple steps to achieve a desired result, but it would be doable whereas right now, we canāt do much with pasted aliases.
Also, I agree with @satikusala that some fairly trivial automation could be used to collect aliases from one or more agents to prepare for a copy and paste operation. Furthermore, an $OnPaste rule could be used to further automate a process to achieve a desired result.
Since these sorts of operations should be fairly obvious to current Tinderbox users, then this approach is worth supporting, assuming that this is not a big development burden.
What I appreciated from your first post was the recognition that the ability to paste an alias into another document is a useful capability that actually needs to work in a predictable way. It might not be the ābe all, end all,ā but it allows forward movement.
2 Likes