I did a search through the wish list for this, and was a little surprised that it did not appear.
There should be a placeholder tag for the project last modified date & time, not just the current document.
Example Use case: front page of draft:
Allows any compiled document to include the date/time the project was modified, not just the current document (which, in this case would be the “title”/“cover” page, and is unlikely to be modified much if at all during the draft process).
Edit: I did consider the use of just $fullDate/$fullTime, but these would update even if the compiled project hadn’t changed. Take as an example this scenario: you write a draft, then compile to .docx for your editor. While she’s reading it, she sends a note asking you to send a PDF copy to someone else (a trusted beta reader, perhaps?). Using $fullDate/Time it would appear as if the PDF compile is a newer version, when it really isn’t (assuming, of course, that it isn’t). Or she gets the .docx file but her hard drive promptly takes a dump and she needs you to resend it.
The thing is—compiling changes the project. If you keep a Finder “Get Info” window open beside your project and you open it, use File/Compile…, click Compile and then wait a second after it finishes, you’ll see the modification date tick to the current time.
So while the modification time would be different at the point of compile from the current system time (if you were extremely careful not to touch anything that would trigger an auto-save), it would be in sync with system time shortly after—meaning you could only ever do this once. If you notice a mistake and recompile, it’s too late—or in your very example where you need to recompile for someone else.
I think having manual control over what amounts to a version number is a better solution. Modification dates on files are too volatile. If you need a semi-static date that is being used as a form of versioning, it would be better to be in control of that—perhaps instead of using placeholders you use Edit/Insert/Current Date and Time when it is appropriate to increment versions—or perhaps you are careful to edit the cover page only when you want to increment a version and use its modification date.
Or you can use a revision number instead of time. There is a <$revision> placeholder for that purpose. It uses snapshot counts—and so you could snapshot the cover page to increment the version count manually.
Although the revision placeholder is interesting, I’m not sure that creating a snapshot of a document that hasn’t actually changed—particularly over, and over, and over again—is the right way either. It doesn’t actually address the issue, that being a display of the date & time. Instead, it displays a revision number, which by itself is meaningless. It would add yet another layer of manual information gathering, that of recording what date & time correspond to a given revision number, offering yet another opportunity to get out of sync.
The best solution remains to have a project-wide date & time placeholder. Although, as a temporary workaround this could perhaps be done with a custom meta tag.
It occurs to me that this might be something I could look at using an Automator action for, but I don’t see any dictionaries in Automator for Scrivener. My thought was to see about creating a meta-tag, and using an Automator action when I actually want to compile a new revision. The action would update that custom metadata in the title page (probably just insert the time & date formatted how I would prefer them), then run the compiler with current settings (or even just bring up the compile window, and stop). I may look a little deeper into that, I just now had that idea so I really haven’t delved that deeply into it.
No Automator or AppleScript dictionaries for Scrivener, which means that my idea to possibly have this update that way is probably a non-starter unless I missed something.
Indeed the point would be to replace using date and time as a form of recording versions, treating the manuscript more like we record software versions where that is the only number that matters, rather than upon which hour and day it was compiled. For some things that can be a better approach if a group of people are working with one reference point over a longer period of time.
I still don’t see how that would work though, given incidental changes to the project will modify it. It’s too much like a “database” style format with an active connection to the disk as opposed to a .docx file where “Modified” literally means the last time you pressed Cmd-S and nothing else.
Regarding automation: if you have something like Keyboard Maestro that can do quite a lot (I’d wager most things Automator can do and quite a bit more besides). Even BetterTouchTool, which can chain simple commands together under a single keystroke, might work. For example:
View/Go To/Title Page (if you add that page to Favorites then it will always be at the top of the menu) menu command.
Cmd-Down to get to the end.
Shift-Cmd-Left to select the last line.
Shift-Opt-Cmd-D to insert the current date and time.
Opt-Cmd-E to compile.
Enter (or Fn-Return on laptops) to submit present compile settings and open the file dialogue for you.
Here’s a proof of that. I added an “Update & Compile” button to my Touch Bar that does all of the above with one tap. One could of course use a mouse gesture or button, Siri, keyboard shortcut, et cetera et cetera instead of the Touch Bar.
Surely you can just use the <$modifiedDate> of the title page for this? Whenever you want to update it, just type a letter in the title page, delete it, and hit Save. As Ioa says, there’s no other really good way to do this, because the project modified date would be too volatile.
Alternatively, of course, you could just keep the .docx file around, open it in Word and generate a PDF copy from it. That would probably be a better option in your particular example anyway, because that would ensure that the pagination and appearance of the PDF copy is identical to the .docx copy.
Thinking about it from a reader’s perspective it may be more user/reader-friendly to have a date & time, but I see where you’re coming from. The reader can just reference the revision number, and then it’s up to me/my editor/the other voices in my head to translate & keep track of when each revision was created.
However …
These are both good suggestions, ones I hadn’t considered because Automator and AppleScript are free and I have extensive experience with both of them. So there probably is some myopia on my part. I can certainly see where L&L can make a good argument—leaving aside how difficult it would be to actually do such a thing, which was your original point—for it not being a native thing in any case.
Although—as Mr. Blount points out—I am probably way overthinking it. All I really need to do is have a single “master” compilation (in .doc/.docx format), the title page of which I can manually update. Then if I need to produce a version of the same compilation, I can send a copy of that document or produce a PDF of it from within Word. Also, that I can automate, even going so far as to use AppleScript/Automator to add entries into the CRM I use to keep track of submissions, beta readers, and editing/advance copies.
So I suppose I’ve changed my mind about what is on my Wish List
Project Modified date & time tags, not so much. As was pointed out, it would probably be nigh-on impossible to do this way, given the complexity of what “the project was modified” really means.
AppleScript or Automator access, however, would be really excellent. Yes, Automator is less featured than is AppleScript, but it’s also way more accessible. I recognize that deciding what would be exposed to Automator could be a subject of intense debate, and the same would be true of AppleScript. There are a lot of potential use cases for both.
I will also add that I did see there were other requests for automation/scriptability, but since that wasn’t my original thought I didn’t think to look for them first. Instead, imagine that this is added onto the end of the “Automator” topic
Finally, I will mention that I understand that adding a script dictionary is a non-trivial task (though, apparently easier in an Objective-C macOS app than one written in Swift), and unless it’s something that’s already been planned and baked into Scrivener 3 it will be something that we would have to wait on in any case. No worries.
If/when we do add scripting it may have more of a basis in a cross-platform language like Python or Lua. Otherwise people would have to create two different scripts if they wished to create a process for both platforms. I think it would be a bit messy to have that scenario, where one comes across a great looking script that promises to handle timeline details but then finds out it only works in Windows, because the author of it never had any cause to learn AppleScript and wouldn’t have any way of testing it either.
