Search results with adjustable "context"

You search for a term, and for each instance it returns (in a Scriverner editor view) the found line, plus a designated number of lines before and after the term. Extra points if each result could on the fly be adjusted to show more or less lines.

Usage: Say I use the word sigh too much. Show me all the sighs. (I’ve set the “context search” return range to be 3 above, 2 below.)

Ah–I get a big ol’ list of 5 line segments (between separators)–because I have those extra lines of context, I can quickly see if and how I might change that word. AND I can easily see all the other instances without scrolling (much) as would be necessary in the traditional method of jumping all over the novel to show the results on their actual page.

If I need a little more context, doing something snazzy like dragging the separators, or an inline scroll would be a sweet bonus. (hmmm… what did she do in the previous paragraph? -drag…drag…drag- Ah!She swooned! Guess a sigh here is a little much.) Though something like that is probably harder to implement by a factor of 10 compared to just returning a specified range.

Too often, searching for terms by bouncing through documents never gives you a “big picture” view of the occurences. And methods that just return the lines in a list are too fragmented to make intelligent edits. The above method, for me at least, would be a great tool for zeroing in on each item with enough context to actually edit it, while staying cognizant of the other instances of it in the work.

Something like this may appear in the future. Improvements to this area have been requested before and are on the long-term list. We do also intend to make document level searching easier, when coming out of a project search. We want to make it so that the search term is pre-loaded into the search utility so you can just start hitting F3 immediately, then you dodge the whole matter of how much context to show, and how to show it, since you’re working with the best form of context possible: the actual spot. But right now it’s a bit of a bother to get to that.

Thanks!
My suggestion was just trying to deal with something I often have to contend with–sometimes, for me at least, the actual spot isn’t the best context, or at least not the most useful one, because it’s so hard to get a sense of the other occurrences without a lot of (sequential) jumping back and forth. Forest for the trees kind of thing. Seeing all of the results together while each is in a useful-enough-to-be editable context would cure that, in a way I’ve never seen before. But I have to say the search–especially with collections–is pretty awesome already.

Oh, agreed. I didn’t mean to dismiss that and say that the actual spot is the only sort of context that matters. It’s just that in most cases it is, otherwise simple spot to spot Find would have fallen off the radar years ago. It’s a good system that addresses a broad set of use-cases, so making that as easy as possible to do is one approach. For the rest, like I say, we do have plans, but this is the kind of things that require UI design, research and care, so don’t expect it in the next update or anything. :slight_smile:

There are precedences for systems like this. However, most of them are found in coding editors. For example there is a cross-platform coding editor called Sublime Text that has a very interesting approach: it turns a global search result into a text file, complete with context and line number addressing. So you can go on to save that search result as a text file. Very cool—but probably more the type of a thing a programmer would appreciate than a writer. :slight_smile: We do have models to work from, but the trick is finding an intuitive and friendly way to do so—something most editors designed for programmers aren’t as concerned about.