Maria, have you looked at the search menu? If you click on the arrow next to the magnifying glass in the search field, you will see that there is a menu with the option to search the Draft only, or just the current binder selection. So you could select any folder with this option checked and the search would only look in that folder.
That said, though, I just double-checked this and realise that there is a bug in beta 1 which means that search by selection doesn’t work (search Draft only still works, though). I’ve fixed this for beta 2 - thanks for bringing it to my attention.
All the best,
I’ve been yearning for a hoist feature (or “promote” or “focus” or whatever else you want to call it) for a while. My current binder is huge…
Just to make sure we’re talking about the same thing, I mean this:
…Blah the first
…Blah the second
…Blah the third
…Blah the fourth
Selecting Chapter One > Notes and hitting Hoist would reduce the binder to:
…Blah the first
…Blah the second
NB All operations normally performed in the binder can still be performed after hoisting – e.g. Edit Scrivening etc. It’s merely that one is working on a subset of the binder until one hits “Unhoist” or whatever.
This hoist feature would be great! (I thought, it cannot be done for technical reasons.)
Instead of doing hoist I am now temporarily exporting parts of a project to a new project and back again. Better than nothing, but far away from being a real good solution.
Yes, this is why I suggested multiple binders a while back. You could have a second binder tree that only displays the items you want to focus on. The only problem is that the MacOSX UI does not really support this and it would be hard to code.
I had another idea that could make it easier though.
I thought that if you keep the binder the same as it is, a drop down button could be added to the bottom of the binder, that would allow you to select alternative binder trees (still just displaying one binder at a time). Then all the functions of Scrivener, would only use the currently selected tree.
Just realised that this would introduce another problem. Deleting documents.
Or maybe not the hard. If you delete a document, then you offer the option of deleting from the existing tree, or from the disk. If you delete it from the disk, then it naturally gets deleted from all the trees that reference it.
I think iTunes must work in a similar way.
The thing is, this is kind of why the outliner is there. You could easily have the outliner on your left with on the documents in the folder you want to see, select “Selection Affects Alternate Editor” so that clicking on items in the outliner open them in the editor on the right, and you’ve got pretty much what you want.
Right now I’m just imagining lots of panicked e-mails and posts saying, “Where have all my documents gone? I’ve only got one folder left!” People still e-mail telling me that hitting delete accidentally has lost them all their work (without reading the tutorial, FAQ, or just looking in the Trash folder), so I can just imagine the sort of trouble “hoist” would cause.
From a technical perspective it could involve a lot of work. Everything currently assumes that the content in the binder is set from the top-level. I would have to check that everything was robust enough to handle this… Dunno. It’s not like it’s a bad idea - it’s a good one - but implementing it could - on top of the work involved - lead to more problems than it’s worth.
I’ve always seen Outliner view as hoist, basically. In one-click mode, it just acts like a focused extension of the Binder. It would be nice though, as this method prohibits viewing two text documents at once without a bunch of ancillary clicking.
I agree with Keith: Hoisting is one of the most confusing features of Outliners because of the missing data reflex. The Binder would have to radically change appearance for it to be effective, such as it does with search results, yet suggest that there is more content beyond what is visible. Kind of an ugly mock-up, but something like:
…where double-clicking in the fading areas would restore the full Binder view, in addition to some ‘X’ button somewhere, like with search results.
OmniFocus has an excellent implementation of the hoist feature Keith, and the confusion you’ve outlined is largely avoided by a very neat toolbar icon that switches between and . I suspect that the underlying code is mind-numbingly complex (for the average programmer), but for a man of your capabilities… next week then?
I’d love to see OmniFocus in action but do not have access to a copy (I would join the mailing list but it would be for an ulterior and dishonest motive - to see how they implement certain things - and besides, only a subset of the mailing list get a key anyway). If you could describe in more detail how they do it, I would be interested. Though the complexity involved in getting Scrivener to do this makes me think this would be a neat 2.0 feature. Gotta save something for 2.0, you know.
- Withdrawn -
For what its worth, I’d like to see something like a hoist command too. When working with a complex document, the binder becomes overcrowded and it becomes difficult to focus on the bits you are working on. Perhaps another way of achieving this would be to allow the use of colours in the binder, so that one could select a particular chapter and make the folders and documents in it all become yellow (for example) in the binder itself. Would that be difficult?
Exemplary use of “hoist” is found in omnioutliner (not, I think, omnifocus, where perspectives and filters and all kinds of complicated things help you to focus).
Or maybe something like this is already possible, and I’ve overlooked it.