Transclusion/clone (display item in multiple places)

(Moved from Trello; you can vote for this feature and see past discussion at Trello)

This feature would allow you to “insert” an item elsewhere.

This is not a copy, as the updates of the original item will be reflected everywhere that it’s referenced this way.

“Clone” is a temporary name for this feature, lacking a better name. Cloning still indicates having multiple copies (in the sense of cloning an animal), but that’s not the case here. There’s only own copy, but there are multiple references (or images).

Questions to think about:

  1. What to do when the original item gets deleted? Do the clones get deleted or not?
  2. Should we allow “clone chaining”? That is, if you inserted B as a clone of A, would you be able to make a clone of B?
  3. Does clones show up as single result or multiple results when inserting internal link?

This is probably not something we would do in the next few months, but I just want to move here because the discussion is quite interesting.

Excerpts from previous discussions:

Tamas Becz said:

As I said, the usecase I would be trying to solve is mostly filtering things to different places: think of GTD maybe. I type up notes on a meeting (maybe starting from a template I copied). Later I want an action point from a meeting to be present on the next todo list, but still keep it in its original place, for multiple reasons:

Maintain context for the original for reference (Its often enough that a simple sentence todo item won’t be enough to be able to figure what exactly you wanted to do, there might also be the materials you need to use around where the todo has been used)
Keep updates consistent. If I tick something off, and later want to see it from the original context (ie, a followup meeting) then it should be simply reflected there as well, ass well as rewording, other tags, whatnot

In a sense, this is in this is an alternative to the flattened search results. What I am doing right now is i save bookmarks to filter out things based on dates and tags, to get a list like “give me all checklist items without a due date or a tag denoting a category (next, someday, etc)” as the inbox list, or “give me all checklists due until tomorrow, or marked next”. Right now these give a good filter of those things, but are cluttered out by the original outline parents. Flatten would help that. Instead what I could do is I could send it to a designated part of the tree as a clone. (okay, not the inbox search, because it is all about finding unhandled nodes anywhere) A big bonus for usability: I don’t have a problem with writing up the searches, but non-tech people will I guess be much easier with a [[ like functionality. But I guess whatever you come up with at the send to card should be used for consistency.

About the technical difficulty: yes, it’s related to how we do things right now. There’s also the concern of circular dependence (A refers B and B refers A).
For what I had in mind, you don’t have this I don’t think you need to think in terms of source and destination, they are both item A. Think of hard links of unix world. Exact same item, just in different parts of the tree (folders, if you follow the analogy).

It’s also pretty hard to design: there should be some indicator that this is not a normal item but a “cloned” item.

I think maybe you could do that with the bullet. Make it not full, or dashed, or something. I don’t think it is that very important to stand out. You willingly trigger such, and it is probably limited to certain places.

You should be able to easily see how many places refer to this time, for example.
Yes. in that sense this is similar to the “what links here” thing you also opened

Nevertheless I think it’s a convenience feature, on top of being able to link to places.
Yes. actually now that I found out if I just put a direct link to an item without the markdown link notation it updates everything I almost said it is good enough, but then I realized that it does not show up with a search (since it is just display I guess) nor does it inherit things like checkboxes.

Other trouble I can see: conflicting (numbered) list states, and maybe non-leaf nodes (through that might not be a problem at all)

mondayrobot said:

A few things I wanted to add to the conversation, this is a feature I wanted too (if I got the description right, please let me know if this is not what you guys wanted)

  • A good implementation of this is in Tiddlywiki : They organize information in pieces of content called tiddlers (could be the equivalent of an item in dynalist). When editing tiddler B, you can use curly brackets surrounding the {{title of a tiddler A}}, which will display all of the content of tiddler A in tiddler B. Any modification made to the original, “transcluded” tiddler (A) will also automatically appear in tiddler B.
  • You could use a mechanism similar to the “[[” link trigger, using “{{” to launch a clone/transclude trigger. After typing {{, you select the desired item, which will then be inserted as a clone/transclusion (an alternative: use drag + a modifier to create it). Using click + a modifier will allow you to modify the original content (and all its instances).
  • I agree this is more a nice-to-have feature

yosemite said:

Just some thoughts to add to the discussion…

A good cloning feature would be very valuable to me. I would like to see tasks three ways:

  1. outline (e.g. by client > project > task)
  2. by importance (e.g. high medium low)
  3. by scheduled time (e.g. monday, tuesday, …)

I would like to be able to move things up and down (alt shift up/down) in the schedule - and sometimes in importance - without affecting the outline/context. I would like to be able to quickly edit the item anywhere it appears, including completing it, and have all instances change.

There are workarounds with tagging or links or whatnot but it is impossible to do this as efficiently without cloning as can be done with cloning.

Ideally, all clones are the same item. In other words it doesn’t matter which was “first”. And if children are added, all instances of the clone will show the same children. This might only work right if parent items specify their children, as opposed to children items specifying their parents. And there would have to be some anti-recursion logic, perhaps a rule that clones can’t be anywhere under any clone.

A graphical indicator that something is a clone might be nice.

It’s easy to find all clones - select all text in item, copy, go to search box, paste. A function to do so might be nice.

FYI vimflowy has cloning. GitHub - WuTheFWasThat/vimflowy: An open source productivity tool drawing inspiration from workflowy and vim


Since it appears that it would work the same way like symbolic links, I would suggest allowing it to update links to items that are moved around, so that way they don’t break.

Fortunately it’s not a huge issue if you’re linking to an item and don’t change the text on either side. So if it says “Colors: Red, Green, Yellow” and you move the bullet point, then you can simply search for it later, get the link, and then replace the “broken” one.


I would love to see this. Like yosemite, my use case would be when I have a list that could justifiably have several parents — the project it belongs to, the context (e.g. Computer Work, Errands, People) and my calendar (e.g. next week).

Two workarounds are available. One is tagging. But to add to each item all the tags that apply is laborious and the results are messy. True, I can click the tag and it acts / looks a bit like a parent, but true multiple parents would be much better.

This solution also means I have to decide that one dimension gets full-fledged parenthood, and all the others are relegated to tags. I got frustrated trying to decide which of my ways of collecting / categorizing all my lists to convert into tags. I tried it several different ways and ultimately wasn’t happy with any of them.

A second workaround, which is what I use now, is to have one official place where the list lives, and everywhere else it would go I use a link. This is an ok solution for me in the absence of multiple parents. But I would much prefer the latter.

That said, I agree that it’s likely non-trivial to implement and would have to be done well.


Broken links shouldn’t be a concern if this is implemented correctly. When the original item gets moved and get a new id, all its clones should update to reflect the moved item.


That’s why we want to hear from you guys! :slight_smile:

How do you imagine yourself inserting a clone to another item? Similar to how internal links work right now?

There are also a bunch of edge cases which all contributes to the nontrivialness. You don’t need to answer them, just putting them here so we can gather more feedback on them:

  1. What to do when the original item gets deleted? Do the clones get deleted or not?
  2. Should we allow “clone chaining”? That is, if you inserted B as a clone of A, would you be able to make a clone of B?
  3. Does clones show up as single result or multiple results when inserting internal link?
1 Like

I would love to have either a clone feature or a flattened search result. I think flattened search results might be easier to implement but prove to be a nice temporary workaround for clones. As is evident implementing clones would be vastly more complex.

@Erica - I have requested this feature before and I was wondering if it is under consideration.

1 Like

Yes clones are deleted too.

Yes, but while you perform the clone of B, it doesn’t actually clone B, it will create another clone of A. Just saves from having to jump around further as I see it.

If linking, my preference is no. I already have such a long list of items when I go to link to something anyways. Only the original should be show as a result. (This is an area I think many will disagree on, but as I see it, if you need to link to where that clone is, you should generally link to the parent anyways, otherwise it should be the original).


How do you imagine yourself inserting a clone to another item? Similar to how internal links work right now?

  1. keyboard shortcut similar to [[
  2. if an item consists of the text (dynalist url), then it’s a clone.

What to do when the original item gets deleted? Do the clones get deleted or not?

clones get deleted.

Should we allow “clone chaining”? That is, if you inserted B as a clone of A, would you be able to make a clone of B?

Cloning B should create a clone of A.

Does clones show up as single result or multiple results when inserting internal link?

Just the original.

Also create date / change date / etc. are always those of the original.


That would conflict with internal links, no? Sometimes a person might just want to insert a link without creating a clone.

1 Like

Well, I was proposing that an item consisting of a link with empty link text (and nothing else on the line, no notes) be treated as a special case — that it’s a textual shorthand for a clone. But I’m open to other ways to do it.

1 Like

Got it. Sorry I understood it as you’re just omitting the link text.

That could work, and as you said there are other possibilities as well, e.g. [[link]] or something like that.

1 Like

This a really important feature to me.

I’ve a shared document for each team member. The document includes lists of tasks, daily progress, etc.

Instead of going to each document and check their things that I want to check like daily task for example, I want to make like (symlink) in my own main document list as dynamically updated points once they update it, I get synced with them and vise versa.


Employee A doc

  • Tasks
    • task a.1
    • task a.2
    • task a.3

Employee B doc

  • Tasks
    • task b.1
    • task b.2
    • task b.3

Team leader doc

  • Team Tasks
    • Employee A tasks
      symlink to employee A tasks list get listed and synced not just a hyperlink to send me to his tasks. Should be:

      • task a.1
      • task a.2
      • task a.3
    • Employee B tasks
      symlink to employee B tasks list get listed and synced not just a hyperlink to send me to his tasks. Should be:

      • task b.1
      • task b.2
      • task b.3

Yeah, that sounds like a huge improvement to the existing flow!


In my opinion, this will be the #1 most important feature Dynalist will add. I wouldn’t think of it like a clone, I would think of it as an item being capable of having multiple parents.

Definitely! I don’t want to worry about having to delete all the clones too. There needs to be a seperate way to remove the link between a child and parent without deleting either of them.

I don’t think they should be clones, rather I think they should be the same exact item viewed in different places.


Being able to have multiple parents has been accomplished in TheBrain. The way they handle it is perfect. They also support a third type of link between items that is neutral instead of parent-child relationship, but I don’t know how that would fit into Dynalist exactly.

Whichever item is current the “main” item (the one on the top) could show above it each one of its parents. Probably lots of other kinks to work out to make this all work, and I’d be happy to share my opinion on anything! I love organizing stuff like this.


I didn’t read through all the details in this intricate thread.
Multiple parents can be tricky to manage. It becomes a database rather than simply a hierarchical structure.

My first thought was that a lot of the use cases for this might be achievable by putting a bit more juice and sophistication into the “saved searches” concept. As a saved search is basically just a different view into the same data.
Perhaps some more features in terms of searching, as well as how it is presented. (And I believe this would benefit many other usecases not covered here, as well).

It is the same challenge in all the various task managers and so on. It has to reside in one place, structurally. But then the 2nd best to multiple parents are various tags/contexts/flags, views and filters.

Just a couple of cents since this struck my mind.

1 Like

All just IMO:

Yes clones should get deleted otherwise this could get quite messy …

If you try to clone B, it should just make another clone of A.

Single result to the item copied (whether that is A or B).

Final question might be how /whether they should all show up in searches:

I think that all clones should show up but perhaps the clone could have [clone] at the start of the item. Actually, perhaps the clone should always have some indicator like [Clone] (or whatever) that it is a clone.

Hi all, in my mind this is a very simple (and super useful) feature. It’s a simple as taking linked items and showing them virtually in place.

Ability to edit them, bonus,
Ability to iterative loop, bonus,

But simply showing items that are linked in context is a massive boost to the usefulness of Dynalist.



Yes it’s simple in concept but not simple in development, which I think is partially why not many outliners have this feature. It challenges many existing assumptions (e.g. each node only has one appearance) we made from the very beginning since we didn’t know we’d want this feature one day.

If it’s very simple we’d love to build it out very soon :slight_smile:

1 Like

i am excited. someone also thought of TheBrain in this perspective.
it is a different beast. that is a real deal being able to support multiple parents.
our knowledge arrangements are not really a tree branching structures, or so called central idea and spread. instead more like messy spider web, every nodes can be central idea.

common outlining method is basicly “one to many” parent-child relationship. weirdly most of the mindmap apps out there can only do one to many relationship, despite the name mindmap.

i wish there is a way to facilitate “many to many” parent -child relation mindset
another way to cut corner is to use tagging. in this case, any item that branching many to many relation must be save as a tag. the problem is sometimes it is a sentence or two.

i have browsed around the trello roadmap. kinda desperate bout this issue.
any thoughts?


What do you mean? This is already a Trello card that you can vote for.