Moving back in document history

I love the ability to move back and forth through the document history when editing, as it allows me to quickly check something in a previous document and then jump back to the one I was editing. However, when I’m editing I usually have the binder open so I can quickly move to a document I want to check. When I move back however, using CMD[, the binder still highlights the document I selected and not the one I have moved back to.

To clarify: I am working in a document which is highlighted in the binder and open in the editor. I come across something I want to check in an earlier document so I select it in the binder. Once done I press CMD[ to go back to where I was. The binder, however, still thinks I’m in the document I selected.

Thanks

Trip

You are describing the standard disconnect between the editor and the binder, I believe due to the numerous ways the two can be connected (IE what happens when you click on a binder selection).

I’m not describing it well, but it’s perfectly normal.

You can use the “reveal in binder” function to get what you need. Alt+Cmd+R

Yes I can see how that would be, as I am selecting a document inn the binder and then going back to the previous document by using document history. With the latter the binder does not respond, even if the editor does. I guess this doesn’t quite fit with my workflow but the added ‘reveal in binder’ command would get round it even if it does add an extra step.

As Jenny says, this is standard behaviour (it’s even in the FAQ :slight_smile: ). The interface flows left-to-right in general, and history should not affect binder selection. Here’s the entry in the FAQ:

literatureandlatte.com/wiki/ … nterface&s[]=document#the_binder_selection_does_not_follow_what_i_am_currently_editing

All the best,
Keith

Yes, it makes absolute sense. And yes, I didn’t read the FAQ — I’m heads down at the moment and interactions on forums are my only contact with the outside world! :smiley:

As a solution to merge this extra step into the first step, you could use an application like Spark to assign a keyboard shortcut to run an applescript. Scrivener doesn’t (yet) have an API to control Scrivener by Applescript, but you can still use a script to send keyboard commands to Scrivener.

Here’s a script that will send the (back in document history) and (reveal in binder) commands to Scrivener.

tell application "Scrivener" to activate tell application "System Events" to keystroke "[" using {command down} tell application "System Events" to keystroke "r" using {command down, option down}

A script such as this would send both the [ (back) and r (reveal in binder) instructions to Scrivener, so you can have one keyboard command running both.

Just don’t try and assign this script to the commands you’re running in the script. As if you use the command+[ to run the script and the script fires the command+[ again then the script will run again and it will call itself again… and I know apple has a link with a certain “infinite loop” but you don’t want them in your code.

@ Jenny Great idea. Not heard of Spark but will definitely look into. :slight_smile: