On discussing design intent and outlining

I am afraid you got a lot of this wrong…


I think you’re going to need a screenshot to explain this. I’ll check your trust level to make sure you can.

As far as I can tell, you cannot actually nest text within text.

It just puts them in a row. Meaning the child is just slapped on to the end, as a sibling.


Trying to pop-out a clue into its own binder item (such as for linking) is actually just cutting the one into three.

If we actually could get real child-parent, I’d start doing that in hearbeat. The degree of personal headache is due to this being unsupported. It would require tracking where within the parent to place the child, like an inline comment.

Where else would it put it?

If you want to put Section C in the middle of Section A, then split Section A in half at the desired location. (As you have done in the top half of your screenshot.)

It is fine to not support it, but it’s not child-parent, and IMO should not be displayed in the UI as if it is.

That will only lead to more issues w/ people being unable to communicate, as the reality does not match the functionality.

Where the user designates.

With a highlight subsection → make child option being plenty intuitive.

Again, that is where this feature would solve many of the text-linking complaints while encouraging binder item subdivision.

While I would not create such small pieces for the purpose of re-arranging them, using them for links, keywords, labels would be plenty helpful.

Instead, I am best served by using a comment, or even a footnote.

Documents → Split, maybe?

I’m sorry, but I think you and I are using “child-parent” in different ways.

A linear text, which is what the Editor represents, will necessarily put children “under” parents.

An outline structure, which is what the Binder shows, can show more information.

The UI isn’t “lying,” it is showing a level of structure that is not easily represented by a linear text view.


Setting aside whether this is the “real” way to handle child-parent relationships in an outline, what happened to the method I showed for doing what it seems you are describing? This already exists in Scrivener.


If there is a way to place a text binder item within, as in between the lines of, another text item, I would love to know how.

It would be a very flexible and useful function, one that I think would satisfy a lot of the questions/requests here.


I have not once so much as indirectly implied what you accuse.
I have repeatedly added affirmations of Scrivener’s usefulness, and am getting tired of needing such delicacy.
As I have sated before, they very fact I am spending my limited time here, and using the software, implies the exact opposite.

My continuously repeated explanation about child-parent versus sibling-sibling has, quite obviously, been a discussion of “what Scrivener offers.”

And yes, part of that discussion includes what Scrivener lacks.


My position, as demonstrated in the screenshot, is that a folder containing two text items is functionally the same (actually has more options) as assigning a child text item to another.
This is easily represented in a linear view.

It is, in my opinion, misleading to display the sibling text items as nested parent child.

I think it would honestly be a good idea to disable the nesting of text items within each other until/if that functionality exists.

Instead, limiting that to siblings within folders would likely result in less confused/aggravated users.

No, these are not the same.

Among other things, you can assign different output formatting to different levels of the Binder hierarchy. So the “flat” items might be output as standard text, while the “nested” items might be output as italic. Or excluded altogether.

You can also expand and collapse the hierarchy in the Outline view or the Corkboard view, which will show (depending on settings) the item text. So you could expand the “flat” items while keeping the “nested” items hidden.

You should be aware that both Ioa and I have been using Scrivener since Mac version 1. It is probably safe to assume that if we say Scrivener can do something, it probably can actually do that thing.


Thank you, all of that is very useful information.
I am currently using alt+shift+1-8 for a whole lot of styles, and will be able to reduce that number to be a bit more manageable if I can key off the binder depth.

That said, I’m going to be using folders to hold and bump the text items to the right if that’s ever needed.

Everything you’ve mentioned sounds doable that way, and would help my sanity.

There’s also an increasingly annoying default I can’t figure out how to change.

If I click a folder, I can default to scriveneings view and see all text items in a row.
If I click a text item with a nested text item, I only ever get the first, and have to remember to ctrl-1 every time to get it to display the text.



Just click on the multi-sheet icon. It’ll remember that state after that. Until you change it again.

You can also set file groups to behave as folders in the options :


Right, my bad.
You need to check the option I highlighted for that to work.

Thank you, that’s the setting to change that behavior. :pray:

Also just a facepalming level of irony that it is directly related to all this parent-child thing I am talking about.

I am a user.
I have no affiliation whatsoever with the company which designs Scrivener.
I will tell you this:
Forget about your preconceptions.
Learn the software as if you’d never edited text before.
Some is the same, some is not.
But it works. Better even than most - if not all - other softwares.
I’ve been using it for years, I am 100% satisfied. (99.3% on a bad day.)
It works.


I don’t mind jumping through hoops. I am actually happy that there is at least a hoop to jump through, and that I can still do what the software doesn’t upfront (seem to) allow.
At least there is a way, thanks to the way Scrivener is built.
Where other softwares would just leave me dry.
Sure, they might have this or that, but if they have this but don’t have that, :man_shrugging:
None of them has everything either, btw.


Ha ha ha, thanks.

I’m already satisfied with the provided utility just at a beginner-level familiarity, but yeah, it’s always great advice to avoid assumptions.

1 Like

I’m wondering if this should be enabled by default maybe. Or would this trip up users in other ways I’m not considering? (I have it always enabled.)

So do I.
And yes, it should be the default, if you ask me.

1 Like

The pitfall lies in combining this with the “show enclosing folder text in Scrivenings” option.

Often people don’t want to see the folder text, because they’ve used it for notes, an extended synopsis, or something else not directly part of the flow of text that the reader sees. Where they treat text documents as, well, text. So if you always treat things with sub-documents as folders, and then exclude the folder text, that’s going to trip people up.


Right. I’m not doing that.


Perhaps then you should add a sub-option.
(That would be set to “folders” by default.)

“File groups display matches : folder ; file.”
. . . . . . .

Or simply make file groups have their own display setting,
regardless of the option to behave like a folder.
I’d favor this alternative.

The display sticks once clicked anyways… (Currently only for folders, that is. Files don’t have multi-document display. But file groups revert to file display when they don’t behave as a folder. And that is the whole of the issue. – Scrivener is currently doing the very opposite of what you just described would be, tripping people up just the same. Instead of not seeing the parent file content, they don’t see the content of nested files… Which one hurts the most? Seems pretty even to me.)
…And once they check the option for file groups to behave as folders, they can no longer use that ability to not display the parent (folder) content.
I think giving file groups their own display setting would fix this. Where currently there is always something amiss, no matter what.
If folders don’t display their own content and one doesn’t want to see a parent file’s content? Fine, convert the parent file to a folder. That’s it that’s all. If for some reason it is true for all file groups, then check the option to have them behave as folders.
Although I can’t think of why someone would want files not to display their own content.
It makes sense in some cases for a folder, as you just said, and I agree, but not for a file.
Especially since you tell users to split their files in smaller bits if they want to use bookmarks with refined precision.

My two cents.

P.S. It also reaches to that old request to have scrivenings able to display only included in compile documents.