Viewing Preference Not Being Remembered


Hi Keith and Co.,

First - great work on the Scrivener 2, truly impressive.

Now, I’m sure I’m missing something glaringly simple here, but I can’t for the life of me figure out how to get my split editors to behave the way I want. Here’s the scenario…

  • I’ve got a project for which I want Scrivener to behave like a traditional three-pane outliner/notebook.
  • Setup = Binder + Left Editor Split + Right Editor Split
    - “Auto-Load” is enabled
    - “Binder Affects Left Editor” is enabled
    - “Treat all documents with subdocuments as folders” is enabled
  • I want the left editor to always display my binder selection in outliner mode. (My configuration is currently remembering this view preference when binder selection is a container or is multiple-documents, but I can’t figure out how to get it to remember this for single, child-less documents.)
  • I want the right editor to always display as text editor - for the document selected in the left editor, if there is one, otherwise, for the document selected in the binder. (My configuration is currently only doing the former.)

Any help getting this set up correctly would be much appreciated. Thanks.

It sounds like you have most everything set up the way it should be for 3-pane emulation. I use a layout like this myself. Binder+Outliner+Scrivenings is how I work for large projects with deep outlines. So a few points here: group view modes will never automatically load when you view an item that just a file (with no children). You can always manually turn a group view mode on so that child can be fleshed out, but it won’t do it for you. You might try using folders more heavily, while brainstorming. This will force group view mode even if the folder has no children, and you can still add text to a folder as if it were a file. Later on, once you’ve stopped fleshing out the outline so much, you can convert those items back to files if that is what you want. That’s probably how I would approach the problem.

On your second wish: this can’t happen because you have set up the binder to not affect the right-split at all under any circumstances. This behaviour wouldn’t happen under any case any way, but it wouldn’t be logical to allow something like this with binder affects left turned on. What you can do is drag items from the binder to the right editor’s header bar. That logical point aside, I’m not sure this would be a desirable reaction for most people. In all cases, Scrivener doesn’t load stuff unless you make a specific action to load it. If you click on something, or drag something to a header bar, etc. It doesn’t load things because you deselect things. I don’t think it would make a lot of sense to change Scrivener’s behaviour here in such a fundamental way.

There are ways to increase efficiency and accomplish various conditions like what you are doing though. The history buttons are very capable of jumping between one selection and another, for example.

If your focus is in the left editor, you can also still use the contextual menu or the shortcut cmd-shift-O to open a selected document in the right editor, even when “Binder affects left editor” is turned on. Not sure that’s helpful for how you’re using the split, but just throwing it out there. Also the previous/next document buttons or shortcuts might help, similar to the document history.

Historically, the biggest problem that I ran into with this layout was when I was viewing a container in the left editor as an outline, and some file within that container in the right editor. If I wanted to step back up to viewing a scrivening session of the entire container, with binder-affects-left, there wasn’t an easy way to do that; drag and drop from the binder was the only way. This is now much easier because Ctrl-Cmd-R will now ascend up the hierarchy without changing view modes. From the text editor on the right, I can hit that shortcut and instantly be in the container’s scrivenings mode, seeing that document in textual context with its siblings. Cmd-4 does the opposite.

Thanks for the responses and the tips, Ioa and MemeticMouton.

I hate to admit it, but I remain a bit confused, so I’m hoping you can indulge me a bit further, here.

So if I understand correctly, there is absolutely no way to set or coerce a particular editor to always display a particular view mode - i.e. Left always displays Outline or Corkboard, Right always displays Text? If not, is this something that might be considered as a feature for a future release - the ability to toggle this kind of view-preference on and off for each editor?

Related to the above, I was digging around the forum archives and found a thread ( posting.php?mode=reply&f=2&t=10751 ) where Keith said, “By default, the editor will switch to text mode for text items and to corkboard mode for folder items. However, if you are sure that you want one pane always to be a corkboard no matter what and the other to display the editor no matter what, you can go to the Navigation pane of the Preferences and uncheck “Automatically switch back to editor mode when changing documents”. If I understand you correctly, that should do what you want.” This was for a 1.x version, but I just want to be absolutely sure that there’s no way to do this in Scrivener 2; at least at the moment. :slight_smile:

Next, hoping someone can explain to me the quickest way to view - for a container document selected in the binder - both its outline and its text in vertically split editors. When I select a container in the binder, with “binder affects left editor” set, the left editor opens the container’s outline view (as Scrivener conveniently remembers is my wont for it to do). However, when I use the Documents > Open > Open in Right Editor menu or keyboard shortcut, my binder selection opens in the right editor in Outline mode, while I was hoping it would open in Text mode. To get it into Text mode, I see that I can click in the right editor, then use the menu or button or keyboard shortcut to change that editor’s view mode from Outline to Text. Is there another way to do this?

Thanks for considering my questions.

P.S. (I fear I might be going against the grain with some of this in terms of intentional design issues, so I really do hope I’m not ruffling any feathers.)

Generally speaking I don’t think you’re at all “going against the grain,” except that Scrivener never defaults to one of the group view modes (such as outliner) when only a single document is selected, probably for the sake of clarity. In your context, you may be doing a lot of outlining where you purposely select a document with the intent of adding children to it, thus you want it to open in a group view mode, but most people I imagine will use single documents for text and seeing an empty view when they select a single document (since the corkboard or outliner will be empty until subdocuments are added) can be confusing; it’s not always immediately obvious that the corkboard, for instance, isn’t displaying that document’s synopsis because it’s showing the non-existent subdocuments. That may not be the particular thought that went into 2.0’s design, but it is something that’s come up a lot as a point of confusion, so it’s a guess. (Regarding 1.x, the link you posted doesn’t direct to the thread you’re discussing, so I can’t check exactly what you’re referencing, but is true you could force the editor to always display in the same view mode. This had its downsides, too, though, since it was a global setting and it could get confusing.)

So, in answer to your questions:

  1. There’s no way I know of to coerce 2.0’s editor into always displaying a particular view mode for everything, with the exception of single document view. Single documents always come up in the regular text view, regardless of other settings; all you can adjust is how folders (and, if you choose to have them treated as folders, document groups) appear. This is specific to each editor split, however, to a point (treating docs with subdocs as folders is a global preference, so that’s all or nothing) which means you can choose to have your left editor default to outliner and your right editor default to something different.

  2. As I said, each split will remember its own settings, so just as you have the left editor remembering to always open groups or folders in outliner view, you can do the same for the right editor with single document view. Open a group or folder in the right editor and then switch it to the single document view. Scrivener will then use that same view mode for folders and groups in the right editor; single documents open that way by default regardless, so you should achieve what you’re looking for there.

A single click in the binder can only affect one editor at a time; there’s no way to click one document and have it automatically load in both editors simultaneously. The “fastest way” may be subjective (well, no, Ioa could probably give you a really long explanation on why using keyboard shortcuts is physically the fastest option), but selecting the document in the binder–thus opening it automatically in the left editor–and then using the keyboard shortcut to open it in the right editor might be your best shot. Given that once you’ve set the above the right editor will remember to open doc groups and folders in the proper view mode, this should be a quick method. One hang-up may be that you’ll have to pay attention to which editor has your focus, as the keyboard shortcuts switch: rather than being rigidly locked to right or left editor (given that they could also be top or bottom or there may be no split at all), the shortcuts are really linked to which is the current and which the alternate editor. So cmd-opt-O will open in the current editor and cmd-shift-O will open in the alternate.

Does that help?

Hi MimeticMouton,

Thank you for the detailed and helpful reply.

Re. the wrong link: Whoops, this is the location I’d meant -

Re. your point #2: “…each split will remember its own settings…”. Thank you for this. I’d somehow gotten it into my head that the group-view settings were remembered not per editor, but per group. Knowing how it actually works helps a lot.

Re. open in other editor: I agree that using the keyboard shortcut (and paying attention to the fact that they are focus-aware and shift accordingly) would be the quickest way to view a group’s text in the right editor.

In the course of exploring your helpful suggestions, I’ve noticed a couple of other things that may be worth mentioning:

  1. When right-clicking on a document or group in the binder and following the contextual menu path to Open > in Right Editor or Open > in Left Editor , I notice that the keyboard shortcuts are not provided, as they are in the Menubar > Documents > Open menu. Not sure if this is by design or not, but seeing them there might be helpful.

  2. A navigational behaviour that I’m not sure how to make sense of. Settings = Vertical split, Binder Affects left editor, Auto-Load enabled, Outline-view in left editor, Text-view in right editor. When navigating from one group to another in the binder, then selecting in the left-editor outline the document that has the slight highlight (the highlight indicating, it seems, that this was the last document selected when previously viewing this group’s outline), this document’s text does not Auto-Load into the right editor. This feels a bit confusing to me, but maybe I’m missing something?

Again, thanks for the help.

Hi edmo,

Glad that helped a bit. As far as your two points, Keith or Ioa would need to explain the specifics here, but I will point out that I’ve never seen a keyboard shortcut in any contextual menu in any program, so I expect that even if it’s possible to do, it’s a UI sort of thing that is frowned upon. If you’re using the contextual menu, you want to get where you’re going fast and not be distracted by shortcuts, for one thing; they’d also make the menu wider. …I was going to say something else, but I realized as I tried to explain it that I don’t really know what I’m talking about, so before I sow confusion I’ll just stop and let someone better informed comment on that. Suffice to say, showing keyboard shortcuts in contextual menus is not really the done thing.

As for the second, that is a bit odd, I see what you’re saying–if you open Group1 in the left editor and it shows docs A, B, and C with residual highlighting on C, you need to click somewhere else in the editor to move the focus before you can click on C and have that load properly in the split pane. Not sure if there’s a reason for that or if it’s just a bug, so maybe when the L&L team gets back from holiday they can clue us in.

Hi MimeticMouton,

I do appreciate your presence and time, looking into this stuff with me.

I have looked around and see what you mean about contextual menus not displaying keyboard shortcuts (though I see there are some exceptions to this rule for certain apps and certain services - Notational Velocity and Tofu are two apps that I currently have open that differ in this respect). I don’t know how often keyboard shortcuts are displayed in CM’s, but at the very least it looks like, as you suggested, a ‘developer’s choice’ kind of thing. When I posted my last I’d just noticed that one case because it was what I was focussing on; Had I done a more thorough investigation, I would have seen that contextual menu choices are displayed without shortcuts consistently throughout Scrivener, obviously as a conscious choice.

Re. the navigation issue, if anyone from the L&L team does explore this further, it seems that this “selection in editor A does not load in editor B despite Auto-Load being enabled” happens in at least the following two cases:

  1. When the editor in outline-mode has a document with ‘residual highlighting’ to indicate that it was the last one selected the last time you were in this view, and that document is the first selection you make in the outline, it does not auto-load in the alternate editor.

  2. When the editor in outline-mode has no documents with this residual highlighting (which seems to be the case when that editor has been switched from outline-mode to text-mode and navigated to a different document before navigating back), and you use one of the various methods to move the focus to that editor, any document you select in the outline in any way (via mouse-clicking or arrowing-down) is not auto-loaded in the alternate editor.

If that’s not clear as mud, let me know and I’m sure I can find a way to explain it more poorly. (And again, all of this is written assuming that perhaps this is not intended behaviour, while recognizing that it may well be and I’m simply missing something conceptually, or what not).

Urf, yeah, now of course I see it in NV, having said that. Although NV is interesting because it doesn’t show the shortcuts in all the contextual menus; eg if you right click in the note text area rather than in the list of titles, the contextual menu doesn’t list shortcuts. So that’s actually weirder to me. Although I clearly never actually use the contextual menu there, so I never noticed. :wink:

Regarding the navigation issue, I think I understand what you’re saying but I’m not able to get your second case when I try it, switching the focus via the keyboard shortcut or the View menu and using either the keyboard or the mouse to select a document. Is there a particular set of steps to reproduce what you’re getting?

Hi MimeticMouton,

To reproduce both, see if the following does it…


  • Setup your project so that Binder Affects editor A, editor A is in Outline mode, Auto-Load is enabled, editor B is in Single-Text mode
  • Ensure that editor A has the focus
  • Click on a container in the binder - should see sub-doc outline in editor A
  • Click on a non-highlighted sub-doc in the outline in editor A - should see its text in editor B
  • Click on a different container in the binder, to see its sub-docs outlined in editor A
      • If one of the sub-docs in editor A has a beige-ish highlight, select it - Notice that its text is NOT auto-loaded into editor B.
      • If you can’t find a container in the binder that displays one of its sub-docs in editor A with a beige-ish sub-doc, then
            • Select a sub-doc in editor A, viewing its text in editor B
            • Click back on same container in the binder
            • Focus is now on binder w/ container highlighted in blue, and the sub-doc we had previously selected in editor A is now highlighted beige-ish
            • Click cmd-shift-o - should see container’s text, if there is any, in editor B
            • Now click back in editor A on the beige-ish highlighted sub-doc - Notice that its text is NOT auto-loaded into editor B.
  • In either of the above two cases, clicking on a different sub-doc in editor A will cause its text to auto-load in editor B, and any subsequently selected sub-docs in the outline will auto-load as well


  • Remaining in the outline in editor A, click cmd-A to switch editor A to Scrivenings mode
  • Click cmd-1 again to switch editor A to Single-Text mode
  • Click cmd-3 to switch editor A to Outline mode
  • Now click a sub-doc in the outline in editor A - Notice that its text is not auto-loaded into editor B

There may be more cases where this occurs, and it may not be dependent on some of the settings/preferences I’ve mentioned (for instance, it seems to work the same when I’ve tested it with Binder Affects Left Editor and with Binder Affects Current Editor).

Please do let me know if you get the same results.

Ahh. Thank you! Yes, I was able earlier to get case 1 but not case 2. So it appears that the key is switching the modes and then clicking without changing the container in the editor. Simply loading a collection in editor A that has no selection and then clicking one its subdocuments in the editor does not get this glitch; the document loads in editor B as expected. Likewise if there is residual highlighting when you first open the collection in editor A you can click elsewhere in the editor to lose the selection and then click a document and it will load as expected (this is the same as in case 1; clicking anywhere in the editor will “reset” it so that clicking any of the documents, including the one that had been highlighted, will load them properly in editor B.)

Specifically it appears to have to do with the switch to/from Scrivenings mode and single view mode; both are required in combination with the outliner or corkboard (or both) to get this bug. E.g. corkboard>Scrivenings>single view>outliner: document doesn’t load on selection.

" E.g. corkboard>Scrivenings>single view>outliner: document doesn’t load on selection."

That sounds about right, and the order of operations wrt the Scrivenings and Single views does not seem to matter (though you may already have been saying this). E.g. " corkboard or outline > single view > scrivenings > corkboard or outline" also means that the document doesn’t load on selection.