Selection Crossing Boundary in Edit Scrivenings

The practical bug is that if your selection crosses a document boundary and you pick Edit from the main menu or use the context menu, you are offered an un-greyed-out Cut option. The Cut option should be greyed-out because you are apparently not allowed to Cut across a document boundary in E.S.

The philosophical bug is that you should be allowed to cut in these circs. A text selection should not display modal behaviour depending on what is selected.

Did I mention that Scrivener is terrific? Thanks, Keith.


The fundamental limitation with Edit Scrivenings is that when you select across documents, you are actually looking at two different files stacked together, and made to appear as one. Just as you cannot start a selection in one file, end it in another, and cut from both at the same time. E.S. does a pretty good job of hiding the fact that you are editing a dozen files at once, but when it comes to the boundery areas, the illusion breaks down a bit by necessity.

Hopefully in Scrivener 2 or something, a technical way around this will be discovered. As for now, the ability to select between multiple documents is mostly useful as a way of bulk copy.

This is well-publicised and not a bug - moving to Technical Support, where it belongs. (This is unlikely to change ever - thing of what should happen if you delete a range of text that spans a whole file that contains notes and other things - deletion like that should be handled via the binder.)


P.S. Thanks for your kind words about Scrivener. :slight_smile:

It seems like graying out the Cut menu item would make sense, still.

@AmberV Not sure this is really a “technical limitation”, although implementing it may not be easy. I realise of course that we’re cutting across separate files, and therefore have two cuts that will end up in one cut buffer. But why not?

@Keith Putting aside the “philosophical bug”, wouldn’t you agree that offering to do a Cut across a boundary (by not greying out the Cut option), when that Cut isn’t implemented and can’t be done (for whatever reason) is incorrect behaviour?

I’m not convinced of the validity of this yardstick. After all, the Founding Fathers of UNIX gave us rm *, trusting that we would use it wisely. :slight_smile:


Here’s one: Which undo stack should Cmd-Z initiate, since each document has a separate stack in Scrivener? How would the initiator know that 2, 10, or 700 files need to redactions, and send undo commands to each of those files? Assuming a theoretical meta-array that centrally monitors Undo: What if file A+B is cut, then file B is edited, and Cmd-Z is initiated from file A which has had nothing changed since the A+B action? Does half of the cut action restore and some other arbitrary change in B get restored, or nothing happen in B? And that is only a simple example. Since the undo stack is infinite, what happens if 82 changes are made in one file, 47 in another, 10 in a third, and 2 a fourth? If you revoke undo status from all multi-file actions to avoid that mess, then you really do have an rm -rf *. UNIX geeks know to triple check their action when they prepare to bulk decimate a branch of the file system–who thinks to triple check Cmd-X or backspace in the 21st century?

I think questions like this are best answered by asking what the user would expect to happen. The user doesn’t expect to be offered a Cut function that then isn’t available, which is why I filed this originally under Bugs.

If the Cut function is offered, the user expects it to be available, and as you say, expects the Cut to be reversable. My first line of approach if I were programming this would be to check how many (n) files were involved in the proposed cut, concatinate them, inserting division markers, and make the cut into a cut buffer, relying on the Undo for that newly created unified file. No changes need be made to the Binder and its constituent files until the user exits from ES mode. At this point I might also consider snapshotting the n files.

If this approach began to look too hairy, we have a precident already in Scriv’s Convert Formatting for a warning dialogue box that suspends Undo for that particular action. If the user really does want to alter n files from within ES, then that’s what he really wants to do.

“I’m sorry, Dave. I’m afraid I can’t do that,” should be the last resort of the programmer, not the first. :slight_smile:



Keith never claimed to be a programmer. He is a writer who was kind enough to share the software he created as a tool for himself with others who sorely needed something like that. And, I do not think that Scrivener looks like a piece done by an amateur, it is amazingly professional. It looks great, works great and is 100% stable. The best piece for writing I have ever used.

On the other hand I ask myself whether the pieces of text are ordered well if there is a need to edit parts of text which cross document boundaries. I never encountered a case where I wanted to cut over the edges of one piece of text, when writing in Edit Scrivenings mode. Somehow, there is always a deeper reason for the boundary, and therefore no need to edit parts of text from both sides altogether. :confused:


Absolutely agree, of course. One of the reasons we spend time discussing these finer points here is that Scriv is worth it.

“Ordered well” carries a lot of implications. If you’re choosing to divide into scenes, do you know up front that your scenes are ordered optimally, that they begin and end where they should begin and end. Have you never wanted to combine the scene in the library with the following scene by the pond at the bottom of the garden? :slight_smile: And isn’t ES mode where you’d be most likely to discover that?

It would be no less meaningful to declare that “if text is written well I question whether there is a need to edit it”.



you took the word “well” I chose instead of several others (logically, correctly etc.), but indeed it wasn’t a better choice. My experience is only a personal one, I have to admit. I started some “non-academic” writing less than two years ago, and since I get good response recently, I think it is not too bad. I am amazed how scenes develop, characters develop without planning. They are there, come up during writing and are just right. My editing only regards the language, I struggle with the language, the words, the pictures. This is all ultimate joy: Seeing the stories coming up without effort and then polishing with great effort and trouble and a feeling of “that’s it after all”. So, yes, I have never come across this problem, although I have written --yes-- nearly a thousand of scenes and several articles with academic background, where the scenes are “subtopics” (and which I do not enjoy writing, just for the records.)

But although I am very old, I am still young enough to look forward making this experience… :wink:


Except programmers do this all the time when they have to allocate a finite quantity of their attention and effort.

It seems to me that Scrivener would not be able to hook into system routines for Cut, Copy, Paste, Undo, etc. across file boundaries. So this requires a monumental refactoring of these routines. And other features may take priority for the major version increase. In which case the response might be, appropriately, “I’m sorry Dave…”


Which is why, as I say, my first approach would be to consider concatinating the n relevant files. :slight_smile:

On your first point, you’re quite right, of course. But you’re not contradicting me: “last resort” scales to whatever resources are available.


Why not just merge the offending documents into one? Then you can do whatever you want with them/it, including breaking them at new places and reshuffling the pieces using the Binder and Corkboard. And Keith doesn’t have to write any new code. :slight_smile:


Oh but keep reading.

Then I guess I’d argue this feature does not merit a solution of last resort.


If you really spot two scenes that need to be merged, just lock the E.S. session (Cmd-Opt-L), select them in the binder and merge (Cmd-Opt-M) them. The E.S. session will even update automatically. Same goes for split.

Except that in this case, the user is expecting something that is potentially unreasonable, even if it seems logical, based on the illusion of E.S. being one buffer. Users can expect some pretty unrealistic things, I know, I’m one of them.

This has all kinds of problems. Division markers are prone to accidental destruction if they are invisible (say something out of some obscure Unicode block), and accidental syntax error of they are visible. In your very own example of cutting across a file boundary, you would have accidentally cut the division symbol with the two paragraphs. Those two files would now be joined, and when you pasted, you would be splitting some file as the division marker would be dutifully cut and pasted too. Yes, there are ways around this, but they all involve hacking the cut and paste system in potentially dangerous ways, entering into the realm of least returns which Bryce brings up.

Secondly, you are forgetting the implications of Scrivener’s splits. I can have an E.S. session open in split A, and one of its constituent files open in split B. If I perform some action which causes this pseudo-spanning buffer to be created, causing the E.S. buffer contents to no longer be synchronised with the file system, it is also no longer synchronised with split B. If I edit stuff in E.S. (not necessarily the doubled constituent file), and the stuff in split B, when I dismiss E.S. in split A, the spanning buffer will be re-split at these hypothetical division markers, blowing away the changes I made in split B. Worse is if a user keeps an E.S. session open for a long time (somewhat forgetting it is there), and after having edited a bunch of documents over the course of a month, realises they are wasting space and closes the E.S. session. Which promptly and dutifully applies all of the spanning-buffer to files that have potentially gone far beyond the point where they are suddenly being brought back. It seems like a silly situation, but that doesn’t mean it won’t happen. I have some project files where things like persistent E.S. hang around for quite a while. I honestly don’t know if I’ve edited constituent files in the meantime, though I’m sure I have. Not knowing if I have, but knowing that as soon as I cancel E.S. I lose changes made in other files, I’d have to do some major work to salvage the situation.

On the surface, using snapshots might seem an Okay safety device, but that is an abuse of the snapshot philosophy, which is supposed to be an intentional milestone device, entirely controlled by the user, not to be cluttered by automatic systems. Consider someone who seldom uses snapshots, but does a lot of editing that triggers the spanning-buffer solution. Over the months their project would become grossly cluttered with machine snapshots, obscuring the location of the few truly important ones they intentionally made.

Finally, warning boxes should never mix case severities into one box, that is a very fundamental truth. An action that is non-destructive should not have the same warning that a destructive action has. Font changes also fall under spanning issues as actions that are user expected, probably more so than cut. The user would desensitise to these boxes, having to dismiss them every time they bold between files–reducing the effectiveness of the warning for that one time when it really matters, moments before they blow away 8 months of work.

To me, it sounds like Katherine’s suggestion is what you really need, if you have to work across file borders so much. In preferences, you can specify your own division marker for merged documents, making re-split easier. You can edit a chapter as if it was a single fine, and Keith doesn’t have to implement horrifically complex and dangerous adjustments to the basic editing system.

I’m still finding it hard to accept that the kind of cut I’m suggesting is dangerous or confusing or poses huge philosophical problems. I certainly accept that it might be difficult to design and program. (How about an alert box that says: “Making this cut will combine these documents. Do you want to proceed?”)

But can we at least agree that the UI should reflect the capabilities and limitations of the underlying functionality. If a Cut is not possible in a particular circumstance, the Cut function should alert the user to this by being greyed out wherever it is presented, whether from the main or context menu. This is standard Apple UI stuff, surely.


As folks here have gone to a lot of trouble to talk me though this I think on reflection it’s a bit cheap of me to dismiss their arguments in one sentence. Let me see if I can respond more fully without adding to the confusion.

Consider the case of two documents viewed in ES mode. Doc 1 ends with paragraph D1End. Doc 2 starts with paragraph D2Start.

The user wants to select D1End and D2Start and delete them. As the software stands at the moment she can extend the selection to cover both pars, Cut appears to be an option, but the result is a plonk noise indicating that the Cut has failed. (I hope I’ve managed to persuade all here that this at least is a bug…). A corresponding Copy operation under the same circumstances will succeed.

However, the user can work round this Cut limitation in ES mode by selecting and cutting D1End and then repeating the operation with D2Start. Have all sorts of metaphysical horrors been released by this action? Not that I can see.

So what would be the philosophical problem with implementing exactly the same double delete action, but behind a streamlined UI that allows the user to extend the selection across D1End and D2Start and then Cut? The orthogonality of Cut, Copy and Paste is thus preserved in ES mode, and the interface behaves exactly as the user would expect, no more no less.

Difficult to program? Yes, perhaps – Keith will be able to speak to that. But opening a Pandora’s box of unspeakable beastliness? No, as I say, I’m not convinced… :slight_smile:


Ah, I seem to have missed the original point. Okay, I’ve added it to my list to grey out “Cut” and “Delete” when a range of text that spans more than one scrivening is selected.