My cause for concern is the repeated “Conflicts with how the software was designed to be used”
That implies there’s a right, and a wrong way to use software. IMO that perspective, which I used to have, greatly limits understanding and potential.
.
Even way back in web 1.0, the idea of jumping to a specific piece of the page was understood as a worthwhile feature, and adding #tagID to the end of any webpage still works to this day.
Scrivener itself acknowledges there to be many character-specific pointing needs, and caters to them. Comments being the most visible example.
The very manner in which the comment window is designed seems built for the need to click and jump precisely to each one.
At some level, the use, appeal, ect of this functionality is already understood.
.
Hence my concern that there is some misplaced ideological component creating a blindspot here.
.
.
Those concerns aside, I can put on my developer hat to get a level deeper:
The problem is that Scrivener does not do what it claims to with child/parent text. Links cannot do what they were designed to do, because of another problem that I’ve not seen called out.
Attempting text-within-text only results in sequential documents. IMO, the UI nesting these elements is downright no-bueno. “lying” about that w/ the UI is causing problems.
To be clear, you cannot put the child text at a spot of your choosing, it’s literally just parent first, then child 1, child2, ect. Those are three siblings, and this disconnect is the root of this, and likely other problems.
In this specific case, Scrivener is not “achieving its vision” or whatever, the missing feature is why people need to hack together their workarounds.
If carving a child chunk of text out of a document does what it’s supposed to, then the linking feature becomes more functional, and could do exactly what everyone inquiring here needs it to, without using the comment system. many people here need it to, without using comment-based workarounds .
Again, if Scrivener supported actual parent-child text-within-text, this problem disappears without “compromising” any vision.
The chunk pops out as a child within the binder view, but can stay collapsed w/o clutter while offering linkability and other features of a binder item.