Why can’t I display the contents of a folder from the binder in the right-hand edit pane when I have two edit panes open? Is there some design here that I’m missing where this makes sense? I’m probably using the app wrong still, but I’ve been fighting this for a while and just now realized why one of my folders would open up into the edit pane and why the other wouldn’t.
Thanks!
P.S. Please correct my Scrivener vocabulary if needed. I’m sure “edit pane” isn’t the spec name for it.
My guess is that you are referring to wanting to display the combined text contents of the item(s) contained within the folder. If so, try this…
If that’s what you are experiencing, here’s what is going on (I think).
The Corkboard and Outliner buttons are single purpose or single mode… clicking one of them puts the active editor window into that view mode and clicking it additional times does nothing further (I think).
The Scrivenings button is dual purpose or dual mode… not only go into Scrivenings (text?) mode but… 1) show just the folder’s own text vs 2) show the combined text of the folder and the items it contains. When you are viewing the combined text of multiple binder objects, you’ll see them separated by gaps containing white space and a dashed line. Scrivener remembers which text view you last used for each item and will present that view if you move away from and then back to the item.
That can be confusing. Best analogy I can think of is that items in the binder (at least in the manuscript/draft portion of the binder) are all basically a single fundamental type of item, that have multiple characteristics (name, current type/icon, their own text, various other attributes and of course the items (or links to them or some such) that they may contain. I’m sure that is an oversimplification.
Anyway, basically the Scrivenings button is not just selecting text edit mode… but also toggling between you seeing and working on just the selected item’s associated text OR its associated text plus the text of items that it contains…
Not necessarily the most elegant or intuitive, but the developers have explored alternatives and have not yet identified a better approach.
The above is discussed in 5.2 VIEW MODES of the Scrivener manual (available within Scrivener via help, also available in downloadable PDF (Adobe Acrobat Reader) format at literatureandlatte.com/support.php#Scrivener
I also took a stab at discussing this in another post if you are up for it… https://forum.literatureandlatte.com/t/gaps/26461/1
I could be wrong.
Hope that is of some assistance.
That was totally it! Thank you!
I don’t think I quite understand the advantage of the mode where you can’t see all the text in the folder. It seems to be a zero sum thing where you see everything or nothing when the folder is selected. I’m unclear as to what the use case is in this instance. I’ll look at 5.2 and your other thread.
Regardless that was exactly what the problem was, and I thank you very much for your guidance and thorough explanation.
Sorry… this is going to be verbose…
What you encountered is a result of Scrivener being a robust generalized tool that doesn’t lock/limit users into a single approach to their work.
Here’s my guess at what’s going on behind the scenes in Scrivener and why.
My guess is that all items in the manuscript/draft portion of the binder, even though they take on different appearances and results vary based on those appearances, are the same underlying item type… which just presents different faces (folder, file, notecard, etc. depending on which view you are in) and gets processed differently based on which face it is presenting.
Basically, sort of a single multipurpose building block. I tend to think of it as a chameleon super-molecule that has a bunch of attributes… meaningful visible name, numeric based name in the underlying computer’s operating system’s file system, type it is currently to be presented and processed as, text (its own), synopsis, general metadata, notes, … and optional subordinate items (actually, links to optional subordinate items).
This is supported by the fact that one can change a “folder” to a “file” and vice versa, without losing associated attributes and subordinate items.
So, why display the “folder”'s own text, either by itself or along with the test of the “folder”'s subordinate items? Why not just hide the “folder”'s own text? Because it proves useful, in an open generalized way, to support that.
An example… perhaps a bad one. Chapter title text.
Some folks will create each chapter as a single text file item, containing the entire chapter’s text. Others will create chapters as folder items, containing one or more text file items (scenes?). Others will do other variations, such as chapter folders containing subordinate folders (scenes?) in turn containing text file items (beats/points within scenes?), etc…
For those who do each chapter as a single text file item, they might place the chapter title text at the start/top of that text. (There are probably other ways of generating chapter titles from the outline during the compile process… I have yet to learn those.)
For those who do each chapter as a folder containing subordinate text items, they would have the option of placing the chapter title text in the folder’s own text. At which point there would be something visible there if view only the folder… and also visible at the start/top there if viewed the entire folder and its subordinates’ text contents.
Ditto for scene headers or such, if one uses additional levels of subfolders.
And one can specify various compile behavior for items, based on their level in the folder hierarchy, I believe.
All this also provides robust generalized support both for moving sequentially from outlining to drafting to compiling and also for moving arbitrarily between outlining and drafting and compiling.
Start with a “text” item with a few words or few lines of text while brainstorming and outlining. Then possibly add additional words/lines to that text. At some point, as that chunk of text grows, split that single text item and its text into multiple items. Turn the top item into, or add an additional item at the top as, a folder. Move the all remaining now split out text items into/under the folder item. And you have hierarchical structure. If turns out need additional breakout/detail… repeat this for each of those subordinate text items.
A folder’s own empty text may also prove useful for generating white space. Or not.
Whether or not a given item’s own text appears in the compiled output is controlled, either in the Inspector panel for each item or via checkboxes in the File > Compile dialog.
Etc.
So, robust deliberately generalized toolkit, which can be a bit confusing and intimidating… but which also let’s you brainstorm/outline/write however works best for you, rather than forcing some particular approach or theory on you.
It does have a learning curve, but as evidenced by its popularity, many find it useful. Frankly, despite some frustrations and limitations (all apps have such), I don’t just find it useful… I find it breathtaking. Within a few minutes of starting to use it, I was somewhat confused and intimidated… but I was also relieved and reassured. I was home!!! Your mileage may vary…
Best I can suggest is just plunge in and keep learning, a bit at a time. It’s not perfect or magic, but it is sweet!