Document locking

Hi Keith and team.

I realised, recently, that I had inadvertently pasted some text into a finished manuscript. I was using twin panes in the editor and referring to the manuscript in one pane whilst creating another document in the other. I suspect this may have happened before and now I need to go through the manuscript to check for chunks of pasted nonsense!

It would be very handy in a future update to have a way of locking documents (and un-locking) to forbid further editing so that people like me can’t be careless!

Thanks,

Stuart

The same amount of effort (remembering to click on the “lock” button) can be use to create snapshots. They’re pretty handy. Just make sure you understand that a snapshot occurs at each document, and that a folder can have it’s own text, so you have to be sure and select everything under it too in order to get snapshots of it’s contents.

This video explains the feature far better than I can this morning:
youtube.com/watch?v=1bo8mdW1ZEI

Thanks Robert,
I use snapshots regularly - great feature - but it doesn’t help if you paste content in the wrong place without realising. You could compile your 100,000 word manuscript without realising there are errors inside somewhere, so you won’t think to revert to a previous snapshot.

Locking the manuscript to avoid accidental editing while keeping it open to refer to, would be a useful extra feature, I think.

Actually locking does make sense. I was initially thinking that snapshots would get it, but I bumped up against that usage scenario that you mentioned. I wonder though how you would indicate a locked vs. unlocked doc in the binder/editor in such a way that you

  1. Don’t make it so intrusive that folks get irritated.
  2. Don’t make it so unintrusive that support gets inundated with “I can’t edit my novel” panic.

KB will have to weigh in on it, but it does make sense to me. Which should probably cause you a bit of concern.

Although I can understand the desire for such a feature, I’m afraid that I’m against it. This is exactly the sort of thing that would weigh down with support with angry, “I CAN’T EDIT MY WORK AND I’M ON A DEADLINE I HATE YOU!” emails. :slight_smile: Users manage to accidentally turn on script mode and revision mode all of the time, so I have no doubt that we’ll get plenty of users who would accidentally lock their documents and panic.

All the best,
Keith

Just because I am a pest…

How about a preference option to “enable file locking”? Make it one of those things you have to beg and plead to get the command syntax then use terminal to enable.

maybe? Please? I’ll keep vic-k occupied for a while…

Maybe a big old padlock symbol overlaying the draft folder’s icon, which, when right-clicked upon, would have “UNLOCK” in bold at the top of the contextual menu? Maybe even some kind of background watermark of a padlock behind the contents of the binder, as well as scrivenings, corkboard, and outliner views. When you try to click into the text, a tooltip appears explaining it’s locked, and to unlock it, go to such-and-such menu item?

I agree. Big toggle padlock on or off for whole manuscript or draft folder. Make it an opt-in preference to lock out those who would give Keith a hard time!

Hi,

With locking being an opt-in preference and using a combination of icons and context menu, this feature would be simple and unobtrusive.

A major benefit is for those of us who create many closely relate works in a single project. For example: Article writing in a single niche.
Each article has it’s own publishing cycle and a lock-when-done feature would help a lot.

See attachment for sample icons and what the context menu could look like.
Scrivener and Locking Feature Request.png

Kind regards,
John.

Hi,

You can take a snapshot of a document when you want to lock at at a particular point - that way, even if you accidentally make edits, you can always return to the locked version (the snapshot). As I say, there are no plans to add a feature that will lock a document and make it uneditable, though, so this snapshot approach is going to be the best solution.

All the best,
Keith

How about adding the option to compile a certain snapshot of a binderitem?
Let’s say I’m finished with “draft #7” for example, create snap shots of each item and want to compile exactly that version. Now I can select that snapshot by name, maybe with a little warning if that name doesn’t exist, so I can select another one for that chapter where I typed “draft 7” by accident and be happy. :wink:

Wouldn’t that add a level of document locking without distracting those users who aren’t technical savvy or don’t bother reading manuals?

Adding my voice of support for this feature.

I understand the concerns about users accidentally locking their documents but since discovering the lock features for the editors and inspectors — this has become an essential part of my workflow. Surely there is a way to make it visually obvious what document is locked? (greyed out with padlock symbol ? )

I’m using Scrivener for academic writing and being able to lock the documents from accidental editing would protect me from myself.

This is a fundamental feature for many situations. I really do not understand the problem: they suggested some solutions, the most extreme would be that when user tries to edit his work, it appeared an alert such as

"The document is locked. Do you want to unlock it?

Yes No"

I do not think it would be too intrusive (unless one is so careless that continues to accidentally edit) and it would work infallibly for the most inexperienced user in the world.

1 Like

What does “try to edit” mean in this context? Dropped the cursor? Selected some text? Tried to actually type something? Tried to save changes?

Katherine

I mean anything that modifies the document in any aspect.
Saving does not modify it.
Selecting a part of text does not modify it.
Selecting and copying a part of text does not modify it.
Selecting and deleting a part of text, obviously, modifies it.
Pasting a part of text, obviously, modifies it.
Typing, obviously, modifies it.
Anything that changes in any way the document, after user locks it, could produce the alert I have talked about.

After working for ten hours in a row on Scrivener and concurrently with other apps, copying, pasting and typing text it is possible that I accidentally write or past something in the wrong place. Of course it would be useful being able to lock the entire file, when you work with another scrivener file or other app’s files, and to lock singularly one or more documents or folders contained in the binder (showing a padlock near the document/s and folder/s locked, as suggested) when your are working on a single file.

Many apps let users to lock documents, I do not think it could produce complaints by people, especially following the advice given here.
I hope you and Keith change your mind on this topic and add this feature in the future :slight_smile:

One year on since the last post in this thread… I guess we’re not getting this feature, but I would like to add my voice to the request. Especially after I published an eBook that had a random word dropped into a sentence due to an absent-minded search attempt in the final draft… Imagine if it was a dead tree publication!

Apologies for reviving this post but Scrivener is my favourite writing software but I no longer use it because the document cannot be locked. This in itself is not a problem, as on a Mac a warning comes up asking if you want to save changes should you accidentally change something, However Scrivener has overridden this safeguard.
As I go to research libraries and type extensive notes, which I keep forever, the chances of accidentally changing something over several months increases. I know that probably nothing has been changed but probably is not good enough, I need to know for certain. Even the most basic, simple text editor has this.
I now use either IAWriter or MacJournal repurposed. I occasionally use Scrivener for rough notes but not for anything that I need to keep. I know you recommend snapshots but for me it is convoluted and not a natural way of working.
Unfortunately the almost perfect writing software is unusable only because you have overridden a basic Macos facility that I take for granted.

It sounds like you are referring to how some applications work with individual documents you open, like Scapple or .txt files—i.e. simple formats that can be loaded entirely into memory at once and operated on purely “off disk” until you choose to save the file (or not). There really isn’t much of a comparison between formats like that and a program like Scrivener. I just tried three other programs that work more like Scrivener, where one loads a container that houses potentially thousands of files and only loads into memory the ones you work on within that session, and out of all of those, none of them had some kind of overarching “Are you sure you want to quit without saving changes?” when closing the container/database/etc.

It is (a) not a feasible mechanism for this kind of software, and (b) there is no infrastructure for it on the Mac even if it were. So we aren’t “overriding” anything, and we aren’t doing anything terribly out of the ordinary for this kind of software.

I will agree with you that locking would be nice in Scrivener, and it isn’t uncommon to find locking in database style programs—but it is a little more complicated than you seem to be thinking it would be, and of the one example I tried that is very much like Scrivener in this regard (Ulysses), it works exactly the same, with no locking.

Consider for example if you have one locked paragraph in a 100-item Scrivenings session (or a section of sheets in Ulysses). What happens then? Is there an immutable chunk of text in the middle of your file? If you change the font wholesale on that 100-item chunk of text, are patches of it ignored if locked? That could result in some embarrassing mistakes down the line if you thought the font was changed and never noticed until a reader wondered why there was suddenly a Courier paragraph in the middle of the book. Or what if you loaded that chunk of text with the intention of bulk search and replacing a character name? These are not challenges that a more typical database style program has to face—where one doesn’t consider chunks of text in the outline to be smaller ingredients in a longer span of text. It’s probably not an impossible problem to work around, surely, but I have a difficult time visualising an elegant approach to these problems.

Theory aside, here’s what I do to have peace of mind: switch on the Take snapshots of changed text documents on manual save setting, in the General: Saving preference pane. Using manual save is already a bit of a habit for me because I also make use of the Back up with each manual save setting in the Backup preference pane. When I’ve done a chunk of work and I’m happy with the state of everything I’ve worked on in that session, I hit ⌘S and in doing so I get every single file I’ve touched backed up individually with snapshots, as well as the project structure and content as a whole.

There is nothing convoluted about that to my mind—it is in fact precisely the same sort of mechanical action/reaction you get from a single-document based application where when you save a file that’s your last anchor point set. I don’t have to think about these snapshots, I never do, and when I need them they are there.

The only downside to that approach really isn’t much of one in Scrivener 3. In the past it meant a proliferation of hard to clear out snapshots. The snapshots still proliferate of course—that is what we want after all—it’s the clearing of them that is now easier: the Documents ▸ Snapshots ▸ Snapshots Manager feature makes it a simple affair to purge these old automatic snapshots across large groups of documents at once.

Thank you for your reply AMBERV. Like you I use manual save but have basically switched off automatic backups by using a very long time in the preferences.
I will definitely give this software another try and when some research is completed and checked save a snapshot as something like 'final corrected version’. However MacJournal does allow you to lock a document by using CMD + i and unticking the editable box. Also IAWriter is simpler software of course but does allow locking. I do try to get into the ethos of software I use so will give it another go. (Another thing, I wish you could switch off automatic backups altogether.)

We might be using different terminology for backups. I’m referring to the zipped archives of projects that are, by default, created whenever you close a project. It’s another safety net in that if you close with unwanted changes you can go back to the previous state and pull out the desired text from that backed up project, plugging it back into the main one. You can switch that off in the Backup preference pane, but in most cases I would say it’s a better option to switch it off for individual projects, in their respective Backup pane in Project ▸ Project Settings…, particularly if the problem is a few very large projects that take a long time to back up.

Now you seem to be talking about auto-save, which is something else entirely. That’s not a backup as it writes data right back on top of the thing you have open. It’s just like auto-save at the macOS level if you choose to enable it. We don’t have any plans of making a switch for turning that off, it is very rare that anyone really wants to do that, and for those that do, setting “9999” on the idle timer or whatever is surely good enough. It’s a much riskier way of working, and contrary to the design of the software, so we’d rather keep that a somewhat “undocumented hack”.

All right, I see the checkbox in MacJournal now. Such falls right into the lines I drew regarding categories though. You can lock files in DEVONthink Pro, and in EagleFiler you can globally lock down all editing in the viewer pane as opposed to finer grained locking. None of these programs are designed to assemble dozens of chunks of text into one editor however—where entries/records/notes are discrete files really. I think perhaps if anything were to make sense in Scrivener, it would be such a global lockdown of all editing. Kind of odd perhaps for a writing program (never mind a massive job rewriting every widget that is capable of modifying stuff)—but that makes more design sense than fine grained locking.

I don’t have that software, but it wouldn’t surprise me if IAWriter is merely providing a front end to the ability to lock any file in Finder with the Get Info palette. It’s a rather stripped down plain-text editor more along the lines of TextEdit, and not a database of files. Maybe they do something else, but it wouldn’t make much sense to me to roll a whole new locking mechanism from scratch when the file system already has it built in. Unfortunately that mechanism was never designed for multi-file package formats like Scrivener’s however.