Working with subsidiaries to non-Namesakable items

[alx]

Brainstorm has a rather non-obvious logic when dealing with information subsidiary to non-Namesakable entries, i.e. entries with Namesake Off; here's an example to demonstrate it:

- Create a new Brainstorm model
- Type an entry, say [David Tebbutt]; let's refer to this entry as Entry1
- Promote the entry (make it a heading) and enter some information on David
- Demote the entry (go up one level)
- Now press Ctrl+N (Namesakes Off) over Entry1
- As we can see, though non-Namesake-able anymore, Entry1 maintains its subsidiary info; fine.
- Press Ctrl+N over Entry1, to make it Namesake-able once more

- Now, type another identical entry, i.e. [David Tebbutt] again; let's refer to this as Entry2
- Brainstorm will rightly recognise these as Namesakes and make the information under Entry1 available to Entry 2 as well.
- Now press Ctrl+N (Namesakes Off) over Entry1 again
- You will now notice that the original information under Entry1 has disappeared and remained as subsidiary of Entry2

Brainstorm apparently prefers to allocate ownership of subsidiary info to those identical entries that maintain "Namesake potentiality" rather than to isolated ones, even if they are the original headings of that info.

What if you want the subsidiary info to remain with a Non-namesakable entry? The simple workaround is to enter that info after you make the heading Namesake ignorant.

In fact, you can have as many identical entries as you wish with different subsidiary info, as long as you turn Namesakes Off for those entries before adding any info.

alx

[david]

To throw a little light on our thinking:

If a bunch of entries share attributes (descendants) then the removal of an entry from that bunch (by non-namesaking) shouldn't deprive the rest of their shared ownership.

[Fionvarin]

This is very useful to know. The namesake function has great charm but it's nice to know how to control it.