(1) Modified keyword search and (2) info in search field

Two unrelated requests.

First, currently when one searches from the keyword HUD for a given term, the results include everything with that term AND whose keyword includes that string of letters. E.g. a keyword search for “fiction” returns items with the keyword “nonfiction.” I think the two should be treated discretely.

The ability to search more effectively using keywords would be huge. (Also – although this might start veering into bloat territory – the ability to do boolean searches – e.g., non fiction and NOT history – might be useful too.)

Second, I think it would be helpful if the toolbar search field when it is unpopulated would show in dim lettering the parameters of the current search mode. (I am wording this poorly, probably.) To wit, if the pulldown menu is currently set to search, say, titles only, then when unpopulated the search field would show “Title” in dim text. That way, when one uses cmd+ctrl+F to access the search field, one would know beforehand what kind of search they are about to embark on. Make sense?

Anyway, this is a brilliant product. Huge thanks.


Thanks for the kind words.

I explained why the keyword search, imperfect though it may be, works as it does here:


As for (2), I did experiment with that, but there’s just no way of fitting all the necessary text into the search field, so I settled for just showing the scope.

All the best,

Ah – sorry I missed your earlier response to my keyword thoughts.

Not to insist on rejected features, but while implementing the kind of keyword search I suggested might not be feasible through the toolbar search field, it seems like the problems that you noted with doing that wouldn’t be problems with the HUD panel. In other words, ctrl-clicking several keywords in the HUD could return results with only those keywords, treated as discrete entities.

Right now, the keyword behavior doesn’t pose many problems, as I am only working with 20 or so keywords, and I can ensure that their spellings don’t “overlap” in a way that returns anomalous search results. However, if I start to use keywords the way I use, for example, openMeta tags – and just generate them without thinking them out beforehand, eventually ending up with hundreds – then I can see a situation where I could run into trouble.

Anyway, that’s just a closing thought. As it is, Scrivener is a tremendous tool.

The trouble is that currently there is no difference between the toolbar search field and the keywords HUD search - the latter is just a convenient way of calling the former. And the search criteria of the search field can be used to create a collection. So to achieve your suggestion the keywords HUD search would need separating out into an entirely different feature. So maybe ultimately it might be a nice idea, but it’s less trivial than it at first may appear.

All the best,

OK – thanks.

In any event, there is a kind of workaround I could use, which is perhaps a little artificial, but seems like it would do the trick: namely begin and end each keyword with some arbitrary character like “.” and use underscores instead of spaces for keywords that have multiple words. A way to avoid the problem of “overlapping” keywords.

Also: for some reason the search field is showing the dimmed text that I was asking for in my initial request, and would have sworn I didn’t see before. Don’t know if this is a bug, where the text is not visible when the program is in certain states, or if I’m just losing my mind.

It disappears when your focus is in the search field–could that be it?

I seem to remember that previously I didn’t see it even when my focus was in a document. Because I recall thinking that it would be useful to be able to just jump to a search using keyboard shortcuts, without having to remember what the scope of your last search was. So, I don’t think I was confused by that, but… who knows. Anyway, thanks for the suggestion.