Let the binder reflect which split pane is active

Damn, I thought I was agreeing with them too…:wink:

Human beings have no instincts that concern computers*, only habits. A lot of these habits stem from first experiences with computers and software, which were most likely (depending on how long ago this happened) old, slow computers and software that was still missing a lot of concepts that were only developed later. Therefor, it is absolutely necessary from time to time to adapt to new habits – otherwise we would still be punching cards!

  • Because there were no computers around while homo sapiens was evolving.

On more than one occasion I have caught myself editing a document in Folder A, when I had intended to edit its identically-named (but not identical) copy that was in Folder B. I would very much like to be able to quickly and easily determine a document’s location. I appreciate the argument that having a document’s location reflected in the Binder would be distracting when using the split editor. I’d be very happy if moving the mouse pointer over a document’s title in the Editor would cause a tooltip-like window to pop up, showing the document’s location.

shortguy, why not just rename the document in the title bar of the editor rather than using the binder in this instance?

As mentioned up-thread, opt-cmd-R - Reveal in Binder - does this nicely.

Happy New Year!
Keith

To maintain parity between the documents’ titles.

Yes, it does. I am proposing an enhancement that does not require removing one’s attention from the editor.

I don’t understand.

I’m not sure what you are proposing, then. Do you mean being able to see the location from the editor itself? If so, click on the icon in the editor title bar and select “Path”.

All the best,
Keith

I did not explain this very well, in part because it is a long explanation, but here it is.

As part of my backup practice, I often keep in my Scrivener project duplicates of folders, to preserve work in progress. (I do use snapshots, but for the purpose of preserving a document prior to making major changes, not for backup purposes.) By duplicating the folder, the entire context of everything in the folder is preserved. And, I do not have to search for and open a backed up version of the project to refer to a recent copy of a document (which will cause Scrivener to create a backup of the backup as I open it). As the work progresses, I periodically purge the duplicate folders.

Because the duplicate is made on the folder level, all of the documents contained in the folder retain their original names. So, when I refer to a copy, I do so in the split-screen editor, and have two documents side-by-side that have the same name.

Recently, I found myself making changes to a preserved duplicate instead of my current work-in-progress document. For reasons that I don’t understand, I could not undo all of the changes. While I was able to retrieve a copy of the document from a backed up version of the project, the utility of having a document’s location available with minimal intervention occurred to me.

(I suppose that instead of duplicating the folder, I could compile a version of the folder, print it to pdf, and store it in the project as a read-only copy, with the decreased utility that the work is now in one file, and not in easily-referable sub-documents. AppleScript would be useful for automating this process–or alternatively, for duplicating a folder and adding “copy” to the end of each document’s name, a tedious process to do by hand…)

Yes, this is a quirky way to work, but it works for me…

I’ve become so used to Cmd-Opt-R that I forgot that this context menu was there. Is there a way to bind a custom key sequence to “Path” in this menu so that it is accessible without clicking on the icon? I set up Ctrl-Opt-P in System Prefs, and the custom key sequence is displayed in the context menu, but is only triggered after clicking on the icon, which is not very helpful, since the point of the custom key sequence is to display the path information without needing to click on the icon…see the screen shot.

Thanks, and happy new year.
Screen shot 2012-01-04 at 11.03.19 AM.jpg

I can certainly understand this way of working, although I don’t think having the binder reflect the editor document would solve this - for deep binder structures you would not be able to see the enclosing folder with the different name so it still wouldn’t be obvious which you were using. An option might be to apply a “Preserved” status to the preserved documents and check the inspector before editing, or - what I do when I do something like this - use Binder Affects so that clicks in the binder only affect one of the editors. I then load anything I need into the other editor by dragging to the header bar. That way you know that one editor is always for reference and you’ll never open anything there by mistake, because you can only open documents in it by dragging to its header bar.

This is an annoying limitation of menus in OS X, unfortunately - keyboard shortcuts only send the action of a menu item, they will never cause that menu item to open its submenu to the best of my knowledge, and certainly not when it is buried in a button’s menu.

Happy New Year yourself!

All the best,
Keith

Shortguy: Did you know you can drag a snapshot into an editor window to view it there? I ask because if you’re contemplating compiling to PDF to create a read-only copy to view along side your text before doing major edits, taking a snapshot and then dragging it into one of your split editor panes would do that without anything so arduous. And it’s read-only to boot, so no risk of accidentally editing it.

Edit: Just to head off any confusion, you actually drag it onto the editor’s header bar, not into the text area (or corkboard or outliner for that matter).

I find that duplicates are more discoverable than snapshots, but I will experiment some more with snapshots, and give that a try! Thanks very much for the tip.

I agree (my proposal was, when hovering the mouse pointer over the document’s name in the editor, a tooltip would display the document’s path).

Perhaps I will see if something like a Keyboard Maestro macro can trigger the Path menu item (why didn’t I think of this before).

Thanks.

When you take a snapshot, the icon in the binder gets a dogeared corner. When viewing the document, an asterisk next to the camera in the footer of the inspector appears. These indicators are both a bit subtle, but if you train your eye to look for them, you can see at a glance which documents have snapshots.

Yep. When I first started using Scrivener, I did the exact same thing. And here’s where the confusion happens:

You have documents with identical names open in split pane view. You use the binder to navigate to one of the documents. Then you mouse click on the other document and begin editing in that window. However, the binder highlight remains on the first document. So, if you glance at the binder, and if you don’t know this quirky thing about Scrivener, you will think that you are editing the first document and not the second. It’s a very easy mistake for a new user to make. Because, in almost every other computer program, when something is highlighted, it is active.

So, maybe, at the very least, the binder highlight could be removed when the user navigates away from a document.

Scrivener seems to have been built from the ground up to be different. The whole damned thing is “quirky”. It throws out a lot of previous ideas and replaces them with something better. That is why so many people use it. It is a ground-breaking piece of software, so I don’t think we should be surprised that we have to learn new things when we use it. It is all about working in a new and better way. In some cases old things that maybe had their uses had to be thrown out so that something more important could be made to work. I’d say “don’t lose sight of the overall picture”.

Cheers, Martin.

It’s not really a “quirky” thing about Scrivener anyway - it’s generally how source lists work. (Sometimes it’s the user expectation that’s quirky, and not the feature itself - especially when it’s only a handful of users out of many, many thousands :slight_smile: ) Ioa and I have already explained why this works as it does, and why that is the best way for it to work, so I don’t think it’s worth us repeating ourselves here - but I will say that this won’t change.

Ah, I must have missed that! That should be possible, and is a pretty good idea - I’ve added it to the list.

All the best,
Keith

Thanks, Keith.

I’d also like to suggest that the tooltip appear when hovering over the document’s name where the mouse pointer is located, regardless of which editor pane has the input focus.

See the mockup:

  • Folder A and Folder B each contain a document named “Untitled.”
  • Folder A’s “Untitled” is loaded into the left-hand editor pane.
  • Folder B’s “Untitled” is loaded into the right-hand editor pane. This editor pane has the input focus. Coincidentally, this document is Revealed in the Binder.
  • The mouse pointer is hovering over “Untitled” in the left-hand editor pane.
  • The tooltip reveals the location of the document where the mouse pointer is located, regardless of which editor has input focus.

Thanks again.

I am new here, and a bit new thrown off by the strong opinions. It don’t see why it is necessary to do everything diffferently (even the good stuff) that worked great in other software. This sounds more like a religion to me than a tool.

Like the CON side, I don’t want my structure in the binder to get messed up.
Like the PRO side, I think the binder should reflect my current position.

Reveal in Binder doesn’t do it for me, because it drills down and then reverts back to the same inflexibility I started out with. Back to square one. Once again I have to press Reveal in Binder after switching editors.

I want the binder view restored (as it was) whenever I click in either editor.
8 chapters collapsed, 2 chapters revealed, current scene highlighted - I expect to see this again when I go back to the other editor, the way I left it.

This would serve both sides, Pro and Con. This is the way I am used to (I am visiting from the Windows section, though alas, Scrivener doesn’t behave like this in the Windows version, either)

Because it worked even greater in another way?

It’s not religion, it’s experience. A lot of participants here (among them myself) work with Scrivener since it’s first incarnation in january 2007 (four years ago!), and actually I don’t remember that this subject came up at all before there was a Windows version of Scrivener. I personally had never ever the slightest problem with my orientation in the binder and never missed what so many now claim to miss so deeply. I am really baffled by this discussion.

So am I. It – like several other current debates – seems to spring from orientation to an OS. “This is not the way we do it in Windows; therefore it is incorrect. Please change.”

ps

Fortunately, Keith is a former teacher, and as such knows how to politely deflect unreasonable demands–and also how to sift out the reasonable ones and enact them.