035 - bug in Reveal-In-Binder

First of all, 035, great so far here.

I’m getting more used to the reasonings and uses of Reveal-In-Binder. The case here is in making a Search, where just selecting your scrivening in any search results won’t directly have it selected if you return to binder. Right-Mouse Reveal-In-Binder (or select Ctrl-Shift-8) will accomplish this when it’s what you want.

However, at present in 035 R-I-B will have the correct scrivening selected, but the editor won’t be showing its text. Rather, the previous text you were looking at will still be there. You have to click the scrivening in the Binder once more to get it to show properly.

Side note: it occurred to me that Reveal-In-Binder might like to be actuated by a small button to the left of the title of the scrivening(s) found. What do you think?


How are you doing this? If I run a search and then select an item in the search results collection to choose “Reveal in Binder”, the document is also loaded in the editor when it’s selected unless the editor is locked. So I think I’m missing a step here or misunderstanding the issue.

Well, I just did it again - it’s 100% here, Win7 latest, etc…

  1. be on a current scrivening, in normal editor
  2. type something that will locate another scrivening into the search box, and pause (or click search)
  3. regular Binder/editor disappears, and search results of one or more scrivening titles appear
  4. right-click a chosen title, select Reveal in Binder. Or, click title, then use Ctrl-Shift-8.
  5. regular Binder-Editor reappears, with yes, the chosen scrivening selected in the Binder
  6. However, the Editor and its Title still are on the original scrivening, not the newly searched and chosen one. Binder and editor are out of sync.
  7. as corrective, clicking on the search-rib-selected scrivening will bring it actually into the editor.

This is, by the way, on a totally fresh and stock 035 installation – even removed registry content plus ditched the Program Files folder after deinstalling previous Scrivener. I have not even set up defaults for the editor yet. I did that for a reason I’ll relate another time.

Does this duplicate it for you, Jennifer?


Edit: one more thing I noticed is that a somewhat related fault happens going into the search result as well. There will be one or more search results in the Search Binder, but the Search editor will show none of them. It will show the preceding scrivening where you were before the search.

In this case, none of the Search Binder titles are selected, where one would expect the first to be. Thus the problem here is probably different; that the selection is not made. Easy to fix along side the Reveal-in-Binder, would imagine. Cheers to Lee & co. who I appreciate need out of that cave.


Sorry, yes, I’ve got this now; I think I was just goofing something earlier. So the switch back when you return to the regular binder out of a collection is a bug.

This one is not a bug–switching to a collection (including the search results) shouldn’t switch your document in the editor. The previous behavior for this was the bug, and it’s been fixed now so it is possible to open a collection without losing the document you’re working on.

Glad this showed itself clearly now; thanks, Jennifer.

Hmm. Well, I’ve given this some thought, and some practice. Back to front,

  1. I’ve tried working with two editor panes, and suspect this will operate sensibly once the bug above is repaired. In other words, I should be able to lodge the cursor in a particular editor, search, use Reveal-in-Binder, and that particular editor should end up with the search result showing.
  2. Your point: should search not show its first result? I rather think that it should; otherwise, how will you know what you found? To see that, you’re going to have to select a search-found binder item anyway, and intuitively Scrivener ought to do that for you.

Ah, I read your explanation again, and see what goes awry. My second bug is not complaining that Search doesn’t switch the main binder’s idea of current scrivening. The bug is rather that Search itself does not highlight and show-in-search-editor [the first instance] of what it’s found, at the moment you’re shown Search results themselves. Thus, at that moment, you have no idea what you found.

Fixing this will not affect the need and custom to use Reveal-in-Binder. However, I suspect this style ought to be made more intuitive, and that’s why the suggestion to also add a small button to the collection tags, so that it’s one simple move to get what you’ve found to be the focus of attention as you go back to the editor/s. This would also highlight the concept for those coming on board, no?

Enough for a very balmy Saturday afternoon – have to appreciate those. I will send essence to Lee for use at any time there is cave :wink:


I can understand a bit where you’re coming from, but I’m afraid this behavior isn’t going to change. When you run a project search, the search results list shows in the binder area–that of course stays, so you can “see what you found”. But what you’re looking for won’t necessarily be the first item in the list, and a lot of times when you are searching you’re going to recognize the title, or recognize that isn’t the right title, and not want to waste time going through it. There are also plenty of times you might run a search just to see or count the results–e.g. checking on “unfinished” scenes, as you work through the day. You don’t necessarily want or need to load the documents in the editor, you just want to check how many are left on the list. (Remember that Search Results is just a collection, so the behavior here is for all collections–just because you clicked a collection tab doesn’t mean you want your current document to suddenly change.) The way it works now, you can change the collection in the biner without losing the document you’re working on, then click to select the document you want to load out of that collection, be it search results or a static collection. When you switch out of that collection, the document you loaded is still in the editor.

So this may be part of the confusion, since right now loading in the editor from search results seems temporary–that’s a bug, as going back to the regular binder shouldn’t change what’s showing in the editor, regardless of when you loaded the documents. There’s not a special “search” editor that keeps your clicking in the search results field separate from your “normal” work in the editor–it’s all one. Using the back/forward in browser history buttons will cycle through all the documents that have been loaded in the editor, regardless of how they were loaded.

Since there was previously a bug that the editor would constantly change to load the top document in different binder views, if you’ve gotten a little used to that in some cases it might take a little time to readjust. And I appreciate that you may use search in a very specific way such that you always want to load that top document, and now you’ve got an extra step. But for general usage, and again because the behavior here affects all collections, not having your documents arbitrarily change on you is the expected behavior and will be more intuitive and less irritating for most users. So hopefully you’ll be able to come to terms with it! :slight_smile:

Hmm. Jennifer, it looks like I’m getting kind of an unexpected level of push-back here. As per usual, I am trying to help the product, this time through the smoothness and expectedness of its operation.

Let me first make it clear that I understand well that as far as implementation, the Search result very likely is just the same as any Collection view; or for that matter, the Binder. However, I feel the expected mode of viewable results for a Search is more like the Binder than a Collection. That’s where we’re at present seeing this a bit differently.

I mean, when is the last time you used search in any program, and couldn’t see the results, but rather continued to see something that was part of another view: that before the search? There is both a ‘nothing happened’ and a lack of figure-ground relationship at such a point. That’s what it feels like here, even with a good grasp of what’s going on both internally and on the view.

I take your point about doing a search just to see how many scrivening titles you come up with; fair game.

However, let’s look at what happens any time you select a title within the ‘search collection’ (quotes because semantically, it isn’t a collection until you choose to add it as one, however it’s implemented).

[And, to give the game away after I’ve finished a round of play, this is going to come out with my own view moved to what more probably is driving the Scrivener team in your reply. Just with an open mind.]

  1. If you don’t select any scrivening title, you still see your previous editor state. I mark that as disconcerting, if you don’t perfectly understand what’s going on; and looking like a fault, if you do. But stay with me.
  2. Let’s say you then manually select one or more searched scrivening titles. You observe, you decide what to do, etc… If you don’t manually also use Reveal in Binder, it simply doesn’t matter what’s been selected this way. When you dismiss the search results, your Binder and edit view (in the edit pane you were using) return to a stable and matched state. Nothing is disturbed.
  3. If you agree with the point just made, I can’t see what it would hurt to auto-select the first searched scrivening title (yes, it’s arbitrary, but an expected kind of arbitrary) – instead of nothing. That would clue that the search is now active, and naturally so, at least as I see it: via ‘ah, I found something’. Even though a found title’s selected, you can select another; if you are counting titles only, nothing bad happens; whatever is selected in the end, only Reveal in Binder can change to the non-Search editing state and stack for the arrows. Just as now, except for the natural first clue, is it not so?
  4. There may be something I’m still missing about the whole intended design of editors/binders/collections, open to that. I’m just trying to get the Search branch paths a little more visually indicative of what’s going on, in what I do appreciate as a complex but usefully open way of designing this powerful part of the Scrivener tool. Not sure what happens on a Mac at present; don’t have one though I’ve recommended Scrivener there very happily to colleagues and family. And what I am suggesting I think would make things a lot more transparent to those persons, quite professionally adept in their own fields, to whom I recommend.
  5. Now, let’s go one important step farther. While trying things to be sure how present states operate, I noticed two Scrivener results which may have to do with why there’s such a strong sense of rejection and ‘let’s not bring it up’ about this idea. I typed a search term which was a variation of one of the title words in binder scrivenings. As long as I was still matching, that title appeared in the dynamic Search Results; when I reached the deviation, then that title disappeared. Similarly, going at less than full typing speed, I realized that individual letters and clusters were being yellow-highlighted in my two editor panes where matched, until they would not after all match.

So: [list=a]
[*]Search is actually even more complex: it’s multimode as well as being keyboard-live.

  1. Thus the question would come, when would you switch out of live-on-present-editor-panels, and begin showing a first found title content as I am here suggesting.
  2. That’s a very valid question, and I agree has to do with whether such a suggestion fits in the overall power and instantaneousness that Scrivener’s design presents.
  3. Thinking a moment about it, this multiple mode or bifurcation is useful for an experienced user for whom it’s become second nature.
  4. That’s true even though there’s also a separate within-scrivening, non-global Find function actuated by Ctrl-F. Which by the way has a small but important bug: if you do a Replace with it, the Edit menu shows no ability to Undo. The ability is actually there, if you use the Ctrl-Z shortcut (though not yet for Replace All). It needs to show on the menu too, and I am now wondering how many other seemingly missing undos across Scrivener are also actually present without much additional work to indicating them. Side thought but hope it makes your list(s).
  5. Returning to the main point, there are two attracting paths for handling a move to a Search completed state, which would be necessary for the overall suggestion made here, to show where you’ve arrived. You could do it by using a delay timeout (no more typing plus short interval), and/or you could use a closure (searcher has hit Return).
  6. Yes, this would be different, and more than I’d originally intended. So, a little reflection. I don’t really like the hit-return option, as that changes the flavor of operations. Would a time-out be awkward? It would mean the found-first-title-and-content could change, if you typed more, or backspaced in the search box, etc… I guess I think Scrivener’s/Qt’s pane dynamics could handle it. Doesn’t mean it should be so.
    ]Let me leave this then, as I wish you had rather than ‘not going to change’, as something to consider. I realize by now that what was set off is the way I’ve so often solved design problems: by saying even alone that it can’t seem to be done. Immediately after, a trail of ideas creates a solution, approximately 100% of the occasions. [/:m]
    ]A solution doesn’t have to be undertaken, of course. I think it does help a lot to entertain one, and then judge if it will in its necessary detail improve on a situation. That’s what I hope happens here: that you as a group consider this, and then act as you think. I don’t have any intent to follow this down. That’s both in respect of your process and product, and because there are all too many things beckoning here to be done.[/*:m][/list:o]

Regards, Jennifer, and the team.


Well, let me add one more thought, if I may, as it’s both complimentary and feels likely to be helpful.

After the long investigation above, I went back to my dual-editor display-and-search-panels screen in Scrivener, and tried a few more things to be sure I understood what goes on with it, mentally removing the bug we’ve agreed on.

I had the sensation then, with a bit of wry smile, that has come before, both with Scrivener and with a tool I quite appreciate also which has reached a very high level of design accomplishment with its latest version, Adobe InDesign CS5.5.

InDesign has for me been that very useful software for tasks we know can be tough and name as professional work: it can really get the job done, when the going is to limits; and by the same means, has often been right there to clip you harshly. What gets the work completed is also what has made the application much less than straightforward, and tricky to use.

The accomplishment which has come in CS5.5 has been to improve those powerful areas so that they now don’t have the precipices and edges. The complex instrument has not vanished; rather it’s been smartened to work its powers very much more in anticipation and cooperation with you; and so that there are few if any ways left to fall off their edges. I really have to give Adobe one for this.

It’s come up in private Scrivener team conversation to mention InDesign before, and that was about fine points (fonts etc.) which really do require a large and intricately coordinated group of area experts to accomplish, and which aren’t needed at all for a Scrivener to be what it so powerfully is on its own turf. That’s why we pay (and wait) as we do, though, for the ‘huge project’, and I am just made to smile that they finally fulfill it.

With Scrivener, we have quite distinct matters to appreciate; a number of them, starting with the particularly sincerity of the business and the team. The accomplishment level is very high indeed, and this shows in how enjoyable Scrivener is to use, as well as how wide its powers are for actual writing, the combination a terrific accomplishment. I think we feel this each time we’ve used even the early Betas of the Windows development.

The focus is its own, and once in a while, as with this global and highly integrated Search ability now understood, some kinds of edges between capable power and transparency are going to arise.

I’d like to say that I don’t feel to know any absolute answers for it. There is some balance to be made as possible between capacity and indication; that’s what the suggestion was about.

The suggestion may not be a best answer. To make it certainly wasn’t ‘going after’ or trying to limit by over-simplifying what I see as a crucial core ability of Scrivener, needing to have just the depth it does. I think we would want to lose none of that.

The experience is there with the Macintosh version, and I’m sure you have many team observations in how well people get along (and are able to use) the fine and various points of global Search, likely in the design as shows in this Windows beta.

I can easily imagine that those who really get into work with this aspect of Scrivener will ‘automatically’ adjust to how it works, just as many have to the older InDesign abilities, in each case because of the power to cut through to what’s needed. That’s the kind of knowledge formally called ‘tacit’, and it’s a great ability persons have, to gain where they see to want to.

Whether going one step further in visual indication will help extend this is the question I put some time into asking; and that’s how I would ask you to take it: a little investigation. That’s all, and may it be useful to you.

Best again, then, and hoping that going on a bit this late Saturday evening appears to each of you in the spirit intended.


Hi Clive,

We very much appreciate your feedback and thoughtful suggestions. Some thought has gone into the way search results work, though, and I believe the current behaviour - with regard to it not loading the first document in the search results into the editor automatically - is by far preferable to the alternative you propose, because it will cause far less frustration in a greater range of circumstances. To explain, please consider the following situation:

  1. You have split the editor, with your main document in the left editor and a reference document on the right.

  2. The main document in the left editor has the focus.

  3. You decide you want to change the reference document, so run a search for the document you next want to look at alongside your text.

At this point, your proposed behaviour would result in the main editor - having the focus - changing to show the first result in the list. This could be very annoying indeed; not only might it not be the document for which you were looking, but it has been automatically loaded, without your say-so, in the editor where you didn’t want it, and now you’ve got to navigate back in that editor to return to the document you were working on; it would mean that you had to plan in advance where the focus is. As it stands with the current behaviour, as soon as the results are there, you don’t have to bother switching focus at all - you can just drag the document from the binder to the header bar of the editor on the right, where it will load, and carry on editing in the main editor, which hasn’t been affected, without any further ado, and without changing the focus at all.

There are other situations this is useful, too: for instance, suppose you have only one editor open and you want to add an image to the text that you have previously imported into the project, or you want to create a Scrivener link quickly without going through the menu. In this case, you can search for the image document or the document to which you wish to link, and drag them into the editor. With your proposed behaviour, this would be impossible without navigating back first - again, adding a level of frustration.

Another situation: you have the outliner open in the editor, and you want to drag in an unplaced scene from elsewhere in the binder. So, you run a search for that scene. With your proposed behaviour, the outliner in the editor would be replaced with the first search result, so you would have to return to the outliner and scroll back to the right place before you could drag anything in. With the existing behaviour, you can quickly find the correct document and drag it into place.

I accept that if you just want to load the search results and go through every document in those results one-by-one, looking for a particular snippet of text, then loading up the first document automatically would be preferable. However, this would cause annoyance and hindrance for the many other things users might use search for, as these examples show, and the annoyance the alternative behaviour would cause is, I believe, greater than the current effort required to select the first document in the search results manually.

Essentially, it all comes down to user-intention - what the user intends to do with the search results informs the expectation. Scrivener has no way of guessing intention, though, of course, and so I have to choose behaviour that is likely to cause the least hindrance, which, when you take the above examples into consideration, I believe the current set-up achieves. In general, Scrivener won’t switch documents unless you specifically tell it to, and I think this is a good rule-of-thumb - finding your document swap out when you didn’t intend it is more annoying than having to select a document manually.

I hope that makes sense and clarifies why this design decision has been taken.

All the best,

(EDIT: Oops, I took too long in writing this and Keith jumped in here. But I’ll go ahead and post as I want to clarify a couple issues that came up that I think are just some misunderstandings due to my not having thoroughly explained a few points.)

I think we may still be operating on different levels here due to my not being clear earlier about what was a bug, so let me try to first address that.

What you’re seeing here is part of the bug, and not how things are supposed to be working. If you switch the document in the editor while you’re viewing Search Results, when you dismiss the results or go back to the Binder or another collection (not just when you Reveal in Binder), the editor should stick with the document you’re currently viewing, not bounce back to what was there before viewing search results. That’s what I was attempting to say in my last post, but I think I wasn’t clear on it. The document switching is happening with all collections at present, arbitrary as well as search, and is a bug. There is almost no circumstance in which the editor should automatically and arbitrarily change the document a user is viewing–this should always be a specific action by the user.

You may argue that it’s not intuitive if you like; obviously you’re entitled to your opinion; but this has been built up from a lot of experience from the Mac design even prior to the Windows beta and overall consistency is usually more intuitive than sometimes having the interface change on you and sometimes not. So this is where I was coming from when I said earlier that it wasn’t going to change–this is something that’s been in the Mac version for a long time and has been working well, and changing it for Windows would mean also changing it for the Mac version since the programs are designed to be as similar as reasonably possible to make a smooth transition for the numerous users working across platform. But I may have come off a little too stubborn and harsh about it, so let me try to rephrase with something that’s a little more accurate: This is not going to change for the 1.0 release because Lee is already more than swamped, and it is not likely to be high on the list just after as there are already a lot of other priority items to work through. But development is always ongoing, of course, and so this might be something that can be considered and developed down the road, for both the Mac and Windows version, and I didn’t mean to rule it out forever, just for the immediate future. On the behalf of the developers, I claim the right to say things aren’t possible or going to be explored now and then to do a 360 and implement it later–or not, as they choose. :slight_smile:

Just to address a few other of your points:

Again, I imagine we’re just approaching this with different expectations. I do see the results; they’re listed in the binder on the left. Loading a single item from those results in the editor isn’t really showing me the results; it’s showing me one of the results. The list is what I’m looking for, and then I click for more information. That’s pretty standard in most search functions I use (look at Amazon, Google, library catalogues…) Remember this is Project search, not just a Find within a single document. I could be searching for text not even within the body of the document but rather meta-data of some sort.

So sure, some users are probably just approaching this differently, but I don’t think the current implementation is completely off-base. And again, as saved-search collections are essentially the same as the search collection, the functionality is clearer when it’s the same across all collections.

It really is a collection the whole time; even if you don’t run a search or create a collection, if you view collections from the very beginning, Search Results is there. Once you do run a search, you can switch out of that collection to another collection or the binder and then return to it and have your last search still remembered, with the results all there. You can also save it as a collection, so that running a new search won’t delete it, but the point remains that the Search Results is a collection in and of itself.

Hopefully that clarifies the opposing position a bit. I do appreciate all your suggestions and the time you spent working through this. And please trust that just as you’re offering feedback in the interest of the program, we’ve got the good of Scrivener at heart, too!

Hello Keith,

Thanks kindly for putting your oar in, for the boat here.

I went through your examples this morning, and understand your design thoughts; through this also learned further of the range of those quite useful capabilities to be found beyond the initial surfaces of Scrivener.

As mentioned, I’m quite happy those abilities are there, making this a professional’s tool as well as one for just any of us to find good help in pulling together a document or a writing.

In fact, believe it or not, I’m doing something today which may help get a feature film’s intents and moods to production, and will see how much Scrivener can help my thinking and work with that.

I just want to put in one more note of appreciation to Lee, as I think he’s really been doing the job, which this discussion highlights as a truly challenging one. We’re quite privileged to have his standard of care and effort, and his team’s results.

To Jennifer, I appreciate that in these days everyone should feel part of a design effort. One thing that occurs to me from this instance is that it could really help to have some focused learning episodes as an additional training part of documentation; a sort of ‘Learn this Corner Now’ set of materials.

The written documentation is actually excellent, allowing such ‘Corners’ to be a great supplement. They would be the chance to show how a broad architectural set like global Search and its drag-drop extensions has been thought out and can be handily used. At the same time they would be design documentation whose writing ought to help uncover issues or needed interpretations for Scrivener itself.

Hoping this is also a useful thought.

Best to each, and off to get a position on this task, Scrivener in hand.