Three writing panes or at least a resize option for copyholders

I need to compare across multiple documents and ideally would like three writing panes. As an iMac user there is more than enough room for this.

Having raised this previously and been told the designer(s) are not interested, I have tried using copyholders.

This does not work for me.

  1. I am used to vertical splits and can easily compare across documents.
  2. There is no (obvious) resize option for copyholders, meaning the text is too small to read comfortably.
  3. Having to resize the text manually to accommodate is a pest as I then have to resize it again .
  4. The quick reference panels do not work either as I have to keep resizing them and the rest of the screen to make the thing workable.
  5. All in all, the workflow is made more fiddly, irritating and time-consuming by not using a third or even fourth writing pane.

The whole point of Scrivener is to have a project available to pull up and work with and across documents with ease. The new workflow is just going in the other direction fast, at least for me.

A third writing pane, with the same functionality as the other two, is what I need. I imagine many users feel the same, whether they bother to report it or not.

Kindly explain your refusal to implement this.

If you are wedded solely to the status quo and wish to push copyholders, please, at the very least, implement a resize feature as per the regular writing panes. Thank you.

Resize text in a copyholder, editor pane, or quick-reference panel: CMD SHIFT MORE-THAN SIGN [or LESS-THAN SIGN]

For an explanation from the developer about the number of available editors, see your previous thread on the same subject:

literatureandlatte.com/foru … 18#p268318

And following Keith’s explanation, here is an image showing five writing panes, with three of them arranged vertically:

Slàinte mhòr.

Thanks, but these approaches create more problems than they solve.

None of them suit the workflow established in the first two versions and are just fiddly, slow and annoying.

I appreciate the effort, but the copyholders and quick reference windows do not work for me.

I will have to continue to hope that we are simply given the option of another writing/editing pane. It doesn’t seem like much to ask.

With all due respect, Keith doesn’t have to ‘explain his refusal’. He’s said he looked at it and the current implementation is the result.

As Keith has said many times, this is a wishes boards, but not all wishes come true. It’s not a popularity poll where the most requested come true, or where the most persistent come to pass.

If it fits with Keith’s vision and is doable, then It may happen, and every now and the a user suggestion sparks him to find a way to do the impossible, witness Scrivener iOS.

While what Amcmo says is true, this is not a topic without prior explanation, and without ample documentation and description of the design theories behind Scrivener’s two-pane system, and the mechanisms that such a system affords. In addition to the aforementioned link, you will find prior discussions on this topic, here in the forum (and I’m sure there are more to be uncovered if one wishes to do a little searching!):

To elaborate: the two-pane design concept is, you might say, a genre of software design. It is very different from freeform multi-split editors, where integration between these editors is often limited to keybinding pairs to rotate between them or target them numerically. Generously, I would say the concept of the true freeform multi-pane editor has somewhat died off at this point in time (outside of IDEs), replaced by the linear tab-based approach made popular by browsers (and perhaps by TextMate within the plain-text editor realm), but carried onward in Sublime Text, Atom and countless others. Some editors, like Vim and Atom are capable of both parallel content, freeform splitting and tab-like obscured data models.

Of all these different approaches, and superficial similarities aside, none of them are anything like a dedicated integrated two-pane model. In this approach, the level of integration between the two panes can be augmented beyond what is feasible in a system where panes can number from 1 to 100.

As described in the user manual, pg. 159:

If you want to peruse a few practical examples of how tightly integrated panes can work together, check out the Window ▸ Layouts ▸ submenu where these built-in demonstrations of how the UI can be set up, are accessed.

As you explore those options, you may note that it is possible to set up automatic navigation linkages between a primary split view in outliner/corkboard mode and its subsidiary Copyholder, to load end point or non-branching content, and wonder why we cannot just broaden that principle further—but do consider the key words subsidiary and end point. You cannot load a corkboard in a copyholder and thus you cannot expect further navigation events beyond that relationship. Crucially, the subsidiary/primary relationship keeps such optional integration within the split. The whole split, copyholder included, remains fundamentally integrated with the other split and the binder—you can think of the Copyholder as being more in the split than alongside it.

Another example of such integration is the ability to directly manipulate the other editor without switching to it. With the use of split-independent history queues and remote control history navigation, I can maintain around eight to twelve present tense documents without too much of a mental or finger burden—using a similar model to data obscuring pane flipping as provided by the tabbed view model (which I would say around the same limit in terms of how much content can be feasibly kept “under one’s fingertips”).

There is more! Option-clicking in the binder and in may other contexts to target the inactive split, the way split locking automatically favours navigation into the other split by default, etc. These are all concepts that become greatly complicated and perhaps even entirely infeasible in a non-binary design. There are surely other things, though some such as split swapping and matching could be better defined as complementary capabilities provided by a two-pane system, rather than isolated reasons to advocate for the use of a two-pane system—however that notwithstanding, probably capabilities that wouldn’t be able to exist outside of it.

When we set out to define what additional content meant within the two-pane design, and arrived upon the implementation that was later coined the Copyholder, one of the utmost design intents was for that system to be, again, a subsidiary construct to the two-pane design. Not something that would encumber it or dismantle its design principles, but to instead augment them with the ability to view parallel information (since again we already have a obscure information model with history), and as well to provide a new role in the software: a content view that is implicitly “locked” as a default state—that is not volatile to navigation events by virtue of being outside of the two-pane design’s scope.

In conclusion, I suspect that somewhere within that sense of that you feel, this workflow established between these two panes in versions 1 – 3, is what has been described above. Your reaction to Copyholders not having that same integration is, as noted, quite intentional in the sense that a deeper integration would compromise and potentially dismantle the workflow you speak of—quite possibly making the whole system as “fiddly, slow and annoying” as you style copyholders to be.

[size=110]See Also[/size]

  • §12.2, Controlling Sidebar and Editor Integration, pg. 286.
  • §12.3.3, The Built-In Layouts, pg. 296, where the aforementioned built-in Layouts are described.
  • Controlling the Opposing Split, pg. 162. Concepts such as these would be overly complex and burdened by a system that allowed unlimited splitting.