How could one show the (binder) path, the location of the currently shown, used document?
Technically, I donât think the development team wants to encourage you to be messing with those files⌠(Thatâs kind of why there is no obvious way to get that specific path â no point implementing it under the circumstancesâŚ)
This said, you can see the complete path if you right click the document in the binder, then
âŚand finally paste that somewhere (say in the notes panel, for e.g.).
But unless you have very very very good reasons why youâd want to go there (you donât, actually â use a sync folder instead), donât.
. . . . . . . . . . .
[EDIT] If I went overboard and all that you want is to locate in the binder the document that is displayed in the editor (say you lost track / binder position for some reason), right click the documentâs icon in the editorâs header, reveal in binder.
And then there is the âpathâ alternative ; that somewhat shows just that to you â document position relative to the master âdraft/manuscriptâ folder (right underneath, in my above screenshot).
If for some reason you donât get any visual cue, make sure to have this option checked :
Thank you very much!
Sorry for my bad expression. I meant the location in the binder in the left panel. There is a hierarchy of docs and folders. How could I quickly, easily let me show the location (the path in this binder) of the document or folder the cursor just is? Without having to move in the binder (e.g. going to the top parent item, etc.).
I believe I just answered that.
Read the second part of my post once again. 
The path reads upside-down.
Ops, very sorry, do not have any idea how I could have missed that, may be slow brain activities or so.
There is now way to ALWAYS somewhere show that path. Like one could show the path of the project at the top of the program?
On the Mac, at least, if you hover your mouse over the document title, a tooltip comes up giving the full binder path.
Is it not the same on Windows?
Mark
NB: My screenshot app removes the cursor arrow from the screenshot!
2 Likes
Yes, that seems to work here as well, thank you.
How could I get with a single click or shortcut to the next parent item?
Navigate â Reveal in Binder (it has a shortcut on the Mac but I donât know what it would be on Windows) will take you to the binder with the document highlighted. From there, how easy it is to get to your ânext parent itemâ (whatever you mean by that exactly) will depend on the structure of your project and how many levels deep the document in question is. But I would think (or hope) it would be visible and therefore only a mouse-click away.
Others may have a better idea; this is not something Iâve had to contend with personally.
Mark
The problem with that is, those buttons take you to the previous or next document. Now in the case of the project my screenshot came from, there are several other documents between the one I am looking at and the next potential âparent itemâ, on the same level as âPart 17â, but what if the actual parent item I want to go to is on the same level as âFood in Literatureâ? Iâd have to be clicking the âNext documentâ dozens of times before I got there. Using Reveal in Binder, to me itâs quicker and easier.
But as I said, it does depend on the structure of the project and what you consider the ânext parent itemâ you want to access to be. If you have a very simply structured project, with chapter folders with a single scene document in each, your method will work admirably; if you have more than a single scene document within each chapter folder, or if you have a multi-level project like mine, youâll potentially end up with a lot of clicking. Reveal in Binder (Use shortcut), click on the next parent, will get you there in two clicks with maybe a scroll between them.
Mark
By the way, if your project has a simple structure of chapter folders with a single scene document in each, Reveal in Binder shortcut followed by down-arrow will get you there⌠two shortcuts Iâm afraid.
But it does depend on how youâve structured your project.
Mark
Bearing in mind that your keyboard focus needs to be in the binder (there is a keyboard shortcut for that, in Navigate ⸠Focus, once youâre there, you can use the shortcuts found in Navigate ⸠Outliner Groups to jump between the next and previous containers, skipping over everything in between. Note this disregards hierarchy, it is very literal, from one group to the next.
Windows tip: by the way I changed the keyboard shortcut which is labelled (âMove Focus To > Supporting Editorâ) in the Keyboard options tab, to Ctrl+Tab. I donât know what that default is meant to conform to in regards to standards. Every program Iâve ever used either uses Tab or Ctrl+Tab to switch between major panes. I find that easier to quickly swap between text editing and binder navigation anyway. I use the direct shortcuts as well, in that menu, but only when it makes sense to (like going from the inspector to the binder).
Thank you!
Canât get any of this to work.
The shortcuts shown in the Navigate > Outliner Groups menu (after changing them) sometimes seem to work.
Note this disregards hierarchy, it is very literal, from one group to the next.
Does that mean, if a parent item is a document it will be skipped? Or in what way does it disregard hierarchy?
I want to achieve this:
Some doc or folder is selected, marked in the binder. I want to jump up in the hierarchy (in the binder) to its (next) parent item. And from that parent item I want to get, jump to its parent item, etc.
I guess, there is no way to somewhere ALWAYS show the path of the current shown, selected item in the binder?
Some doc or folder is selected, marked in the binder. I want to jump up in the hierarchy (in the binder) to its (next) parent item. And from that parent item I want to get, jump to its parent item, etc.
Ah! Okay thatâs a different kind of movement from what I was thinking. I would think of this as moving âupâ in the hierarchy, from a child to its parent, and then from that to its parent, and so on all the way up to Draft.
So of course, in the Binder, from any non-group item you can just hit the Left arrow once to go up. Pressing it again in that condition would collapse the folder, and then a third time would go up again. So it has a kind of dual-mode of operation depending on the collapse state of what you have selected.
From the editor, if you want to navigate the editor itself up, then use Navigate ⸠Go To ⸠Enclosing Group. That is one shortcut I use constantly, it is extremely useful, and can be triggered from any editor mode, so you can go from a very narrow text editing scope, to Scrivenings with that note in its context, and then even broader.
Does that mean, if a parent item is a document it will be skipped? Or in what way does it disregard hierarchy?
So the way that command works is like this. Say we have the following hierarchy in the draft folder (and to clarify, I mean this as a list of nested files, without any folders in the mix, as folders are special and always considered groups no matter the state of the outline):
Chapter 1
Section A
Subsection a.1
Subsection a.2
Section B
Subsection b.1
SubSubsection b.1.1
SubSubsection b.1.2
Section C
Chapter 2
Section A
Subsection a.1
Okay, with Section âAâ selected at the top, in Ch. 1, if you use the Next Group command it will jump to Section B, skipping over the subsections, since those arenât groups. Press it again, and Subsection b.1 will be selected, because it is a group (with two subsubsections). The next invocation will jump all the way down to Chapter 2, because nothing in between is a group. So thatâs what I mean by ignoring hierarchy. The command doesnât stick at the level you start on, it will jump up or down as high or low as it needs to, to select the next visible group (collapsed groups you canât see the contents of are the only thing it skips).
I guess, there is no way to somewhere ALWAYS show the path of the current shown, selected item in the binder?
Funnily enough, I was probably the very first person to suggest this, in 2006. Of course the reason given there is no longer relevant. That nut has since been cracked, as you can see with Scrivenings sessions, how part of the heading isnât editable. Here is a more recent duplicate of that original request. You might notice thatâs where the Path menu idea was added to the software, so you at least now know thatâs the official answer, and the Path menu was added precisely to address this request.
Here is another duplicate with an answer I gave. As noted there Reveal in Binder is the other intended way of finding your place. Iâd say it works pretty much flawlessly for everyone except those (like myself) who prefer to keep much of the binder collapsed. I almost never use that menu command because it would require cleaning up after it with the mouse, and at that point I might as well just look at the Path menu.
Bear in mind an exploratory trip up the tree with âEnclosing Groupâ command is very easily undone with a few âBackâ shortcut uses (which youâll find in the Navigate ⸠Editor submenu. Those just work like web browser work, and making those a habit will mean you never have to hesitate before going on a navigational tangent. This is the best fully keyboard shortcut friendly way of looking up your place, in my opinion.
Thank you very much!
Ah! Okay thatâs a different kind of movement from what I was thinking. I would think of this as moving âupâ in the hierarchy, from a child to its parent, and then from that to its parent, and so on all the way up to Draft.
Yes, that sounds like I meant it. What am I missing at the moment, what is the difference to this:
Some doc or folder is selected, marked in the binder. I want to jump up in the hierarchy (in the binder) to its (next) parent item. And from that parent item I want to get, jump to its parent item, etc.
The draft is the root (so to say)? I do not have an item named draft (I guess I renamed it, cannot remember).
So of course, in the Binder, from any non-group item you can just hit the Left arrow once to go up.
Cannot get it working sensefully here. Sorry, did not think of mentioning to not to change (collaps) the items in the binder when moving there. So I do not want the or some items be collapsed in the binder when moving. The binder, the items shall keep unchanged. And I do not want the view (in the editor) being changed when moving (what obviously happens). So I do not want automatically be switched to the cockboard (from the editor).
And when moving up that way (left arrow key) it âjerksâ, there often is a big hesitation after pressing the key (I cannot smoothly move upwards), so I do not know whether a press is executed at all or not, respectively there are parents, childs âskippedâ (when I press again). When I jump to a folder it obviously can last very long until all of the items contained are shown in the editor, so that obviously causes the hesitation.
The right arrow key does not do the opposite (move down in the hierarchy)? To âcorrectâ skipping?
So I just want to easily, smoothly, quckliy move the selection (without causing any time consuming, hesitation causing actions) in the binder to the next, direct parent (not to the parent of that parent, etc.). Just a very simple move upwards in the hierarchy (without causing other processes I do not want). From child to its parent to its parent and so forth.
Okay, with Section âAâ selected at the top, in Ch. 1, if you use the Next Group command it will jump to Section B, skipping over the subsections, since those arenât groups. Press it again, and Subsection b.1 will be selected, because it is a group (with two subsubsections). The next invocation will jump all the way down to Chapter 2, because nothing in between is a group. So thatâs what I mean by ignoring hierarchy. The command doesnât stick at the level you start on, it will jump up or down as high or low as it needs to, to select the next visible group (collapsed groups you canât see the contents of are the only thing it skips).
Does that mean, if a parent item is a document it will be skipped?
So the answer would be: no, it it contains more than one item, it is not left out?
HolyâŚdidnât know how complicated moving can get. If only I hadnât asked.
Funnily enough, I was probably the very first person to suggest this, in 2006. Of course the reason given there is no longer relevant. That nut has since been cracked, as you can see with Scrivenings sessions, how part of the heading isnât editable. Here is a more recent duplicate 2 of that original request. You might notice thatâs where the Path menu idea was added to the software, so you at least now know thatâs the official answer, and the Path menu was added precisely to address this request.
Sorry, my brain, thereâs something wrong. How, where can I find that path now, respectively activate that option to permanently show that path? Sorry for asking this question showing I understand nothing.
As noted there Reveal in Binder is the other intended way of finding your place.
Very sorry again, how? How does that show the path or the orientation, let me know where I am within the structure? It takes me to the item shown in the active editor, I would think. But I cannot find any clue saying what the path is to the item currently shown in the editor, the point within the structure I am.
Bear in mind an exploratory trip up the tree with âEnclosing Groupâ command is very easily undone with a few âBackâ shortcut uses (which youâll find in the Navigate ⸠Editor submenu.
So using that going up command might bring the selection to the next parent of the item just being selected or not. It brings the selection to the next group (what might be the parent or not). So I had to execute that command as often as the selection selects the parent?
Those just work like web browser work, and making those a habit will mean you never have to hesitate before going on a navigational tangent. This is the best fully keyboard shortcut friendly way of looking up your place, in my opinion.
For me clicking through and manually finding menu items somehow is quite ugly, it is too laborious, time consuming for me.
Sorry again for my (almost) complete misunderstandingâŚbut, itâs the brain. But, yes, the easiest most understandable way to move (obviously similarly to what I want) seems to use those groups commands.
To be clear, each item in the hierarchy has only one parent, so ânext parentâ does not make literal sense.
If I understand correctly what you are trying to do is get to the next sibling of the parent of a given document.
And there is an easy keyboard way to do this: If the Binder has focus and the given document is selected there: left arrow moves the selection to the parent. Another left arrow collapses that parent container. (Stay with me.) Then a simple down arrow gets you to the next sibling of that parent.
Since containers can be twiddled closed/open easily (left arrow & right arrow), the fact that a container gets collapsed in the Binder should not be a big deal barrier.
This may not be the implementation you dreamed of, but it is the way to do what you wanted to do. If what you wanted to do was accomplish something, you are in luck. If what you wanted instead was to have something already implemented in just the way you imagined, you are rather out of luck! (Though you could post an item to the Wish List if you wanted.)
(( As for what the Editor pane is showing during this maneuver, that is highly controllable by you. Your view mode prefs for containers determines whether you will see a glimpse of corkboard along the way. ))
All that said, I do think that some pure, basic hierarchy navigation commands Go to Parent and Next/Prev Sibling would be very sensible items to have under Navigation. In the eternal struggle between menu item choices, these make rather more sense to me than what the hierarchy-blind Next/Prev Group menu items do.
2 Likes
To be clear, each item in the hierarchy has only one parent, so ânext parentâ does not make literal sense.
Maybe not literaryly, literal, whatever this means, may be considering ânext parentâ as a tautologie or pleonasm or whatever, but other than literary it definetely, unambiguously describes what item is meant, I would think.
If I understand correctly what you are trying to do is get to the next sibling of the parent of a given document.
I am not sure about the siblings, I would say, I wanted this:
Some doc or folder is selected, marked in the binder. I want to jump up in the hierarchy (in the binder) to its (next) parent item. And from that parent item I want to get, jump to its parent (the parent of the parent) item, etc. So just climbing up the hierarchy tree each to the next parent, I would say. And back the same way.
In other words:
I want to go up to the next item containing the item just selected, then go up to the next item containing the item just selected, then go up to the next item containing the item just selected, etc. And backwards the same way.
And there is an easy keyboard way to do this: If the Binder has focus and the given document is selected there: left arrow moves the selection to the parent. Another left arrow collapses that parent container. (Stay with me.) Then a simple down arrow gets you to the next sibling of that parent.
Sorry, if I am missing anything or everything, I do not want to go to the / a sibling. I want to go UP the hierarchy, so I want to go to the top, keep going the path. I want to got up to the next parent, then to the parent of the parent, then to the parent of the parent (without changing or having to correct the view of the folder structure, items that are collapsed shall stay collapsed, item that are expanded shall stay like that.
How could I in the binder just go up to the parent item and then straight back to the item that was selected before?
Since containers can be twiddled closed/open easily (left arrow & right arrow), the fact that a container gets collapsed in the Binder should not be a big deal barrier.
Sorry, it does not make sense to me that items are collapsed if I just want to move to another item. What am I missing?
(( As for what the Editor pane is showing during this maneuver, that is highly controllable by you. Your view mode prefs for containers determines whether you will see a glimpse of corkboard along the way. ))
I just wanted to keep the editor to be shown all the time while moving, it just shall stay as it is. NO changes.
Somehow nothing of that properly works for me. Using the arrow keys in combination with CTRL (just trying) suddenly moves the items somewhere out of view without any message/warning/confirmation needed (instead of just moving the selection, which seemed obvious to me) and you obviously canât figure out where that item was before, or you have to pull them backwards manually. Does not seem to be a good idea to test in oneâs projects. But I thought just a little moving cannot do that much harm.
1 Like
Ah ha. So Goto Parent is all you need, because that can be iterated. Left-arrow is the available kbd means for getting where you want to go.
It appears at this point you have got your answer. You just really donât like it. So there does not seem to be a lot more to be said.
-
Ordinarily when working in Scrivener, you want what you select in the Binder to open up in the Editor pane. If, as in this case, you donât want that to happen, you need to invoke Lock in Place on the editor pane.
-
After going up the hierarchy, right-arrow will not lead you back to where you were in the Binder. But if you Locked the editor in place you will still be where you were. (Alternatively you could use the Back button in the editor pane, and walk back.)
I do not recall you saying what could be the purpose in running your Binder selection up the hierarchy and running back down while keeping the Editor frozen. Maybe if we knew what you meant to accomplish by this others might have strategies to suggest pertinent to your goal rather than your chosen method â and which might be more satisfactory to you.
1 Like
Sorry for the ambiguity, I just meant it as an example of a top-level (root) folder you might end up at. Draft folder is a root level folder (one of the three special ones that cannot be deleted, see §6.2, The Three Root Folders, in the user manual PDF). And while there, note the yellow tip box in the section on the draft folder.
HolyâŚdidnât know how complicated moving can get. If only I hadnât asked.
Speaking of which, I mean, there is always just reaching for the mouse and clicking on the item you want to view next. I mean to say, read the rest below in the context of that. There are multiple ways to do thingsâif something doesnât feel right to you, try another that feels more direct. I often use editor navigation, almost exclusively, others might find other combations better.
Sorry, did not think of mentioning to not to change (collaps) the items in the binder when moving there.
Yes, to prattle on a bit about why it works this way: this is a fairly typical design within the outlining genre of software, that seeks to find a singular approach to a compound problem (rather than having a huge spray of shortcuts and commands to address each individual aspect of that problem).
The notion of combining upward navigation with collapsing is a design convention, as most often the purpose for such navigation will be to conclude oneâs work within that branch of the outline and move on to another branch. Collapsing the tree with a simple and efficient repetition of a single key until you reach the level you want to move on from is an elegant way to then get to that next item, precisely because the result will now be one single line away from where you are, and accessible with a DownArrow motionâall of the stuff that had been in between is now hidden.
At this point, one can RightArrow to expand the next container, and repeat the same pattern as they desire, hitting the RightArrow key repeatedly to expand and then descend, until reaching the level of depth they requireâbut only expanding as much as needed to reveal that first child item in each container. This leaves the other branches efficiently closed, for future navigation in the leftward direction.
If one wants something else for some reason (such as you describe), to select a high level outline item without wishing to conclude editing that branch, itâs not a big deal, in my experience, because most outliners like Scrivener will also have an amplified version of RightArrow (and LeftArrow for that matter, though its effect is less obvious): Alt+RightArrow which unfolds the entire tree downward from what you have selected. Once you get to the thing you wanted to select, and it all usually goes back to how it was. I suppose we could add more shortcuts and menu commands here, some outliners do have more of them, but in my experience most outliners do fundamentally work the same way as Scrivener in this regard. Itâs not perfectly comprehensive, but like I say, it addresses the most common requirements with economy, which means a reduction of memorisation.
Otherwise, like I say there is just clicking, which never disturbs anything about the collapse states and merely moves the focus around in the outline from point to point. As much as I love the keyboard, sometimes that really is the most optimal path.
What Scrivener does have that is a bit more unusual is that Next|Prev Group set of commands. This gives you another option, another dimension of being able to jump more efficiently to a different branch of the outline without having to traverse up to a level, over, and then back down, as described above. The above is the old-school way that goes back a long long ways, but weâre acknowledging that when it comes to an outline that doubles for many as a ToC for their text, that obscuring areas of that ToC can often be undesirable.
Otherwise, as I say this is genre knowledge of a similar sort one might encounter in how to navigate and edit cells in a spreadsheet. If you rarely use spreadsheets it might take some acclimation, but once you do, you will see that what may even feel like friction at first is the result of careful design, honed over decades, from times when there was even no mouse. So there is some acclimation to be sure.
And when moving up that way (left arrow key) it âjerksâ, there often is a big hesitation after pressing the key (I cannot smoothly move upwards), so I do not know whether a press is executed at all or not, respectively there are parents, childs âskippedâ (when I press again). When I jump to a folder it obviously can last very long until all of the items contained are shown in the editor, so that obviously causes the hesitation.
Very likely an editor condition, either Scrivenings mode trying to assemble all of this data you are now broadening the scope to, or even Corkboard and Outliner might cause micro-stutters if what is on them is demanding (hundreds of images for example, needing their thumbnails drawn on the corkboard).
To mitagate that and address a your displeasure with the editor changing all in one move: consider firing off Navigate ⸠Editor ⸠Lock in Place (Alt+Shift+L / â§âL) first, and then navigating freely in the binder, turning lock back off before you step into the thing you actually do want to load (if relevant). This override has a lot of uses, obviously, this is only one of them. (Aside: Appendix A, which goes over each menu command in the software, is often a good jumping point if you want to learn more about something. If someone mentions a command and you want to dig into everything it does, youâll often find cross-references from here to more expanded descriptionsâas is the case with Lock In Place).
Iâd also step back a bit and point out that a lot of âcomplaintsâ about the binder/editor relationship, or the binder as a tool itself, can be addressed by splitting the editor and loading the working into one of the splits as an Outline. One can even, at that point, hide the binder entirely (View ⸠Show|Hide Binder).
What does this do? Well on top of giving you more optional information about each item, in columnar format, salient to what you seem to be after is that it gives you a more disconnected relationiship between structure and content. You can flip over to the outline view, jump around, and then fire off a deliberate command to load the selection into the other editor (Navigate ⸠Open ⸠in "Other" Editor).
Is that all better than locking the editor and using the binder? Maybe, maybe not. Iâd say both are pretty close in terms of efficiency, and so it will mostly be a matter of taste and context. Are you already using both splits? Then lock+and+move will be less disruptive. Use whatever works best in the moment.
Scrivener is all about giving you options in how you interface with your data. Itâs not going to hold your hand much, but will reward exploration, trying combinations of features in the menus and the buttons around the editor header bar. There are some really useful things when you right-click on the icon in the header bar, for example (including the aforementioned Lock in Place).
Sorry, my brain, thereâs something wrong. How, where can I find that path now, respectively activate that option to permanently show that path? Sorry for asking this question showing I understand nothing.
I was referring to the Path submenu, which was illustrated in this post already.
As to the rest, as noted above, and in the threads I linked to, there is no such feature and likely never will be. I would go so far as to say this is in large part how bound together the binder and editor are by default. Itâs not like a File Explorer window where you usually can only see where you are, not where you came from. In most cases you can just glance over at the binder and see all of the context youâd ever need, and that tool is exactly what you use to navigate as well, reinforcing this mental map.
To witâŚ
Very sorry again, how? How does that show the path or the orientation, let me know where I am within the structure? It takes me to the item shown in the active editor, I would think. But I cannot find any clue saying what the path is to the item currently shown in the editor, the point within the structure I am.
If you use that command, it opens up and scrolls the binder to the item you trigged it on. Therefore the path to this item is inscribed in the hierarchy of the outline leading up to it, as shown around the spot you scrolled to. You just look in the binder and see it is in âSubsection 2.bâ, which is in âSection Fâ, and so on.
Somehow nothing of that properly works for me. Using the arrow keys in combination with CTRL (just trying) suddenly moves the items somewhere out of view without any message/warning/confirmation needed (instead of just moving the selection, which seemed obvious to me) and you obviously canât figure out where that item was before, or you have to pull them backwards manually. Does not seem to be a good idea to test in oneâs projects. But I thought just a little moving cannot do that much harm.
Again, this is probably one of those matters of âfrictionâ I referred to earlier, when comparing all of this to learning how spreadsheets work. There will be aspects of Scrivener that are designed to become more powerful as you learn them, rather than spoonfeeding you about every move (a process that becomes hampering once you become adept). Consider for example how agile it makes your outlining, being able to move things around effortlessly once you get the hang of how it works. Being able to manipulate the structure of your outline as efficiently as you might manipulate text in a text editor is vital to a program like this. Throwing up dialogue boxes and asking âAre you Sure?â whenever you moved something would turn it into another kind of program entirely.
But if it is the shortcut you object to, you can change it to be something a little harder to accidentally do, in the Keyboard options tab.
Where is Goto Parent? What is kbd?
It appears at this point you have got your answer. You just really donât like it. So there does not seem to be a lot more to be said.
Well, well, no, no, very nice answer actually, obviously moving in Scrivener means something different than in other programs. It could be so simple, why not just make it a little bit less simple. Anyone can move easily, but not less easily. And finally nothing is deleted (I suppose at least) when moving, thatâs a good approach.
<Ordinarily when working in Scrivener, you want what you select in the Binder to open up in the Editor pane.
May be there is no need to when simply moving. But it would not matter, if it didnât take time.
If, as in this case, you donât want that to happen, you need to invoke Lock in Place on the editor pane.
So alwawys switching back and forth before and after rmoving. I am not quite sure.
(Alternatively you could use the Back button in the editor pane, and walk back.)
Does not seem to work here (by default). Or may be it only does when the editor is locked.
I do not recall you saying what could be the purpose in running your Binder selection up the hierarchy and running back down while keeping the Editor frozen.
I would not say it needs to be frozen. But in the editor panel the view should not be changed, I want to move and then I might want to edit. And above all there is no need to wait for the editor finishing loading items in a folder when I just want to move (the same with the bookmarks, instead of simply jumping to the bookmark needed simply by pressing the first letter of the bookmark a few times the move always is hesitated because each bookmark passing causes the corresponding document to be completely loaded in an editor).
Well, I would not think there is something special to be accomplished, just editing like usual (or may be it is even unusual). One jumps from one doc to another to edit, change something in one doc and something in another one, something in the parent folder, (quickly (to not to forget) note an idea here and there, etc.
Alright, great, thank you very much so far!