Clone (display item in multiple places)


This is basically the only feature I’m looking for in a notetaking / task management tool.

I take notes in meetings and brainstorming, and in-line write down things to followup with people on using @ and priority levels using #. I need to be able to aggregate all the items for @Dave or all the #urgent tasks into a single view that I can check off when they’re completed without following them back to the original note every time.


I recommend against deleting all clones when one is deleted.

I think it would be better if the delete action works the same way for every node, clone or not: remove the selected node from its parent without affecting the rest of the tree. If the deleted node happens to have clones, the clones would remain where they are and would not be affected (but they remain clones of each other). If the user really wishes to delete every clone of a specific node, then in my opinion that should be a separate command. This preserves the current functionality of the delete command and prevents surprises for the user.

What I’ve described above is the way many similar apps treat clones, e.g. Freemind, Leo, NoteLynx, and others. They treat cloned nodes much like symbolic links in file systems, or pointers in a programming language.

Here’s an example use case where deleting clones would be counterintuitive:

For story writing, it’s useful to have a master list containing one’s major characters, each containing details about their description, storylines, and so forth. For each scene, it’s helpful to list each character that appears in that scene. It would be great if those were clones of the main list of characters so that one can have all those details at hand while writing the scene.

  • Major characters
    • John
    • Mary
    • Pat
  • Scenes
    • Scene One
      • Pat
      • John
    • Scene Two
      • Mary
      • John
      • Pat

Now let’s say I decide that I don’t want John in Scene One after all. The most natural action is to delete John from the “Scene One” node, expecting that the references to John in “Major Characters” and “Scene Two” would stay safely right where they are. It would be surprising and frustrating if the tool also removed John from Major Characters and Scene Two!

I hope this is helpful. Thanks for taking the time to listen to your users.


Thanks for the input, Mark! Is it possible to create a bookmarked search for e.g. “@Dave” and then use that later?


Thanks Craig, very helpful!

I guess in your storywriting case, there’s still the concept of the “original” copy. If the original copy under “Major characters” were deleted, should the clones be deleted too?

P.S. Internal links would work pretty well for this case in my opinion.


I do bookmark that; the problem is the things I want to talk to Dave about (to run with that example) are across ~10 different documents (different meeting notes, to-do lists categorized by different projects).

When I meet with Dave, I want to be able to pull up the @Dave bookmark and edit the items there - add a note answering a question, mark an item as completed, etc. It’s a big pain point to have to click on the item, add a note in the document itself, and then go back to the bookmark for each item that I’m chatting with Dave about.


Thanks for the explanation!

I think this fits your description more than the clone feature though:


I wonder if what would work for many (but never all I am sure) people is for links to other Dynalist items to be expandable and editable in place. Deleting the item outright would then just delete the link. This would be great when compiling a list of topics for say a meeting which are links to items scattered around other lists, and would permit expanding/collapsing the items easily whilst discussing them.


One possibility I see is to allow “expanding” the details for internal links.


Yes, that’s exactly what I was thinking.


Thanks for your note. I can see why it looks there’s an “original” vs. “cloned” distinction in the story characters example, because there’s a sort-of “official” list of major characters and then the “other” lists in the scenes. However, my thought is that there would be no “original” node vs. “cloned” nodes from the user’s point of view, but rather they are all simply references to the same node.

To illustrate nodes that don’t have an original vs. cloned relationship, imagine the following shopping list:

  • Auto Store
    • Oil
    • Batteries
    • Wipers
  • Grocery Store
    • Milk
    • Bread
    • Batteries
  • Home Store
    • Batteries
    • Hammer
    • Nails

Let’s say I’m planning to run errands. I thought of buying batteries while writing up the auto store list, and added them there. Later I decided to make “clones” of the battery item in the Grocery and Home store lists, since I might find batteries at any of those places.

If I find batteries at any of the stores, and check off any one of the Batteries nodes, I would expect that all three Batteries nodes would become checked off, since they’re clones. Or if I realized I needed AA Batteries I could change the name of one of them and they would all change. That’s the power of cloning.

However, let’s say I get to the Auto store and they don’t have any batteries. I would naturally want to delete the Batteries item from the Auto store list since they aren’t there. My expectation would be that Batteries would be removed from the Auto store but they would remain on the Grocery and Home store lists.

Essentially, I don’t think the user should have to try to remember which list they added Batteries to first, fearing that if they delete the “original” it will disappear everywhere but if they delete a “clone” it only disappears in that spot. In my opinion the best user experience is if deletion works exactly the same way on every node, irrespective of whether it’s a regular node, a clone of some other node, or the “original” node from which clones were made.

Agreed, links are great! I do sometimes use links in this way.

The reason I wish I had clones in addition to links is that the two serve somewhat different purposes:

Links are separate nodes from the one they link to, so I can check them off independently, use whatever link text I want, make changes to the links without affecting the target node, and generally use them as “jump-off points” to other areas in the outline. This is great when I want to refer to another node in-line, or provide a table of contents to other nodes, or otherwise refer to information elsewhere in the outline.

Clones are essentially the same node in different places, so if I check off one, they all get checked off; if I change the node text in one, they all change; if I change its children, the children of the clones also change. This is great when I want to keep details of a node handy while working in a different context, or work on two nodes next to each other that would otherwise be far apart in the outline, or otherwise embed information from elsewhere in the outline and work with it locally.

The difference is most noticeable when the nodes are far apart in the outline. To illustrate this difference, let’s go back to the storyline example for a moment:

  • Major Characters
    • John
    • Mary
    • Pat
  • …imagine lots of other nodes here…
  • Scenes
    • …lots of other scenes…
    • Scene 22
      • Characters
        • Mary
        • John
      • Plot…

Let’s say I’m zoomed into the Scene 22 node so that I can focus on just that scene. I’m working along, in the zone, and then I realize that I can’t remember the name of John’s sister, one of the child nodes of John under Major Characters.

If John is a link to the node under Major Characters, then I must: click on the link; jump out of Scene 22; expand John’s node; look up his sister’s name; click Back to return to Scene 22; find the node I was working on; and then get back to work – hopefully still remembering the name. It requires a context switch, a bunch of clicking, and enough friction that it makes me reluctant to click on the link unless I really need to.

On the other hand, if John is a clone of the node in Major Characters, then I simply: expand his node right here in this scene to show his family, and get back to work. No context switch, no friction. Even better, John’s family info stays on the screen visible to me, in my current zoomed-in context, as I work. Best of all, if I learn something new about John I can edit his info right here in this context, knowing that the clone up in Major Characters will get updated too.

I hope this makes sense, and isn’t too long-winded. I really appreciate your dedication to understanding our suggestions, no matter how complicated they get. :slight_smile:


What @Craig_Oliver describes is exactly the behavior that I strongly support.

It boils down to having the same node in different places where
a) I can expand the item instead of having to follow a link, and
b) being able to edit every occurrence (obviously).

About a): the collapse/expansion of bullets is maybe the strongest feature of Dynalist that helps me keeping my notes in a neat and clear organisation. This is why I strongly prefer expanding a bullet (clone) instead of following its link and having to adjust to a new “context”. (Especially if I want to copy text.)

I prefer treating all clones equally without any “original” node. This feels more elegant and you don’t have to worry about deleting all clones by deleting the “original”. Still, it would be useful to have the option to delete all occurrences (clones) of the bullet. (Although, you could do it manually with a text search; see next paragraph.)

It would be nice to get a list of all places where the bullet is cloned to, but a simple text search already makes that possible (if the search would treat each clone individually).

One other detail: the “Make Backup” function. I do feel more relaxed, knowing I have a text backup of my stuff. So the question is how does a clone look like in “text form”. In the spirit of treating all occurrences equally, I suggest plainly copying them (with content).
But I have no idea what to do with infinite loops from clones within a clone. (Maybe limit the recursion depth while exporting (making backup)?)


No clone inside clone should suffice.

That is, you can’t insert a clone inside a cloned item. And you can’t clone an item that only contains a clone. Hmm, I think we’ll still miss a few cases on the first try which will freeze Dynalist with an infinite loop… thanks for bringing up this.

Yeah, I agree in the backup it should just copy the text form. Maybe with a special marker that this is a cloned item.


I think we only need one rule to prevent loops:

Do not allow the user to clone a node into itself or any of its children.

I think that should ensure the outline is always a directed acyclic graph and will never have a loop.


What if you clone some unrelated node B under A, and later clone A under B? That doesn’t seem to break the rule but it sounds like it’d cause an infinite loop.

P.S. Totally didn’t expect a graph theory discussion in the community forum…


Yeah, that’s a great point! I think you’re right – we need to word the rule a little more carefully:

Do not allow the user to clone a node into itself or any of its own descendants.

In your example we have nodes A and B:

  • A
  • B

Then we try to clone B under A. This is fine, because A is not one of B’s descendants. Now the outline looks like this:

  • A
    • B
  • B

Then we try to clone A under B. This should fail, because B is already one of A’s descendants.

This rule also prevents us from cloning A under A.

This also covers another, less obvious scenario:

  • A
    • B
      • C
  • C

If we try to clone A into C, it should fail, because C is already one of A’s descendants.

So essentially I think we’re saying that any time we try to paste a node as a clone, we need to check the child node’s entire subtree to make sure there are no references to the parent node. If we find no references, it’s safe to paste.

Thanks for taking the time to think through this with us.


Yeah, that’s the idea. In reality we might check it differently, as checking it this way might be expensive (it can have tens of thousands of descendants). But in effect, yes, what you said.


From a UX perspective, would it be easier to present it as search results inside of a list instead of multiple views of the same instance?

Right now we have the ability to search and display content at the application level; it’s a common usage pattern that most users will be familiar with. By using that same language for displaying clones/filtered lists and views inside other lists, it might help users understand the difference between copying an item into a new list and displaying an item from a different list.

Familiar framing would also help users navigate the system with markdown/the UI. They’d have a query to search for (a tag, a string, etc), sources to filter in/out (documents) and display limits (number of results, depth, etc) to work with. All of that can be handled in a relatively concise markdown-like string, and the UI approach could easily emphasize that they’re creating a view of things from elsewhere instead of copying content into another document.

Pair that with some color blocking for visual delineation and a “view in original context” button of some kind, and the system would be reasonably accessible. The issues with visible depth and understanding object deletion would be handled and additional features (copy view to current document, etc) could be displayed through the context menu.

On the recursion front, terminating the loop with an item that looks like an internal link with a context-relevant icon (looping arrows in crossed circle, etc) and microcopy would be a forgiving answer. It wouldn’t kill the entire query, but it’d prevent it from displaying a loop and it’d give the user feedback on why what they’re trying to display is problematic.

In any case, I think it’s a great idea. Views inside lists are great tools, as they allow users to monitor and aggregate information dynamically without diverging from the keyboard-driven core usage cycle. Basing it on search features would allow multiple implementations of the same idea (tags vs strings, granular search scoping, granular display context) while leveraging familiar language and clear visual indicators.


I voted for this feature on Trello.

Recently I discovered this feature while researching an outlining code editor called Leo.

Leo’s actually difficult for me to use, so I don’t actually recommend anyone here try it, haha. Dynalist in comparison is awesome!

However, one idea that Leo had is the ability to clone a node of an outline. That means that that node can appear in 2 or more places in your documents.

The file system analog is the hard link on UNIX/Linux/MacOS.

Item clones would allow me to do this:

  • Separate my TODO items by project. Now each TODO item has 1 instance.
  • Create a new document (a “view”) that organizes my work by Week. I can look over my various projects and pick and choose which items to clone into my Week view. These are the items I wish to accomplish this week.
  • Create a new document (“view”) that organizes my work by Day. Every morning, I look in my Week document and choose ~5 items that I want to clone into the Day view. Now each of these TODO items has 3 instances (in Day, Week, Project A/B/C/D).

It’s just like a file system hard link.

If I modify one instance in any way, it reflects on all instances. So if I edit the text, or add a note, I can see the changes in Day, Week, or Project A.

If I complete / check the item, it will be checked in all three views.

If I delete the item from Day, it will remain in Week and Project A. It’s just like a file system hard link. Only when the last instance is deleted will it be truly deleted.

For convenience, we might want to add a right click menu that says “Delete all clones (3).” Selecting that option will delete all 3 instances of the item, and all its children.

Having this feature would help me a ton! (BTW, if you need any help designing or implementing, I’m happy to help out in any way possible. I have a decent amount of coding and UX experience and am 100% behind this feature request.)

Thanks for considering. :slight_smile:


I think clone is an unfitting name. Transclusion seems to be the right technical term. Other suggestions:

  • citation, cite
  • mounting (as in linux drive mounting in file tree)
  • (hard)link
  • mirroring, mirror image
  • wormhole
  • reference (as in computer languages: pass by reference)
  • pointer

The name is not important. What is important: we talk about multiple parents for a node. This would effectively change the graph structure of Dynalist from a tree to a directed graph (aka a concept map).

This is exactly the difference between mind-mapping (tree) and concept mapping (directed graph aka “network”).

In my opinion, Dynalist would greatly benefit from such a feature.

A directed graph is especially useful for a knowledge base. The larger the existing knowledge, the harder it is to find one single place for a new node. And with multiple parents we can put the node under all places it can fit. You could use hyperlinks but transclusion is more elegant and streamlined.

With transclusion we could use dynalist as a full concept map. TheBrain was mentioned here and I agree that they do it perfectly. If I had a magic wish, I would incorporate the relations from theBrain into Dynalist.


Let me give you some examples. I set up a shared dynalist document:
where I just copy-pasted the “clones”. (You have to use “collapse all” from the node menu, since the document is fully expanded by default.)

(This is actually a qualitative example of my own dynalist.)
You see that the notes of books are under “books” but they also should appear under the respective author. An even stronger argument is for notes from reading a book and which need to be incorporated into “Knowledge”. Both places are perfect for those notes.

This example in TheBrain would look something like this:

TheBrain does display children nodes under the “zoomed in” central node. This is similar to current Dynalist. But not less important is that the parent nodes are also visible! They are very important to navigate this network graph.

My suggestion is to display a list of all parents of a node under the breadcrumbs like this:

Of course with other separators as >.

That said, I change my mind about loops. If possible, we should definitely allow clones inside clones and even clones of themselves! That would make formally “infinite” documents but I suggest that all second occurences of clones inside clones will be displayed fully collapsed and would need to be expanded by hand.