Find by Formatting bugs [limit search to highlight colour]

Scrivener Scrivener for Windows
,
1

Windows Scriv 3.1.5.1

Bug #1 - Find by Formatting, Find: Highlighted Text, limit search to a specific color

image
image587×249 5.74 KB

Result: Find by Formatting ignores the “Limit search to color” checkbox and finds all instances of highlighted text, regardless of the highlighting color.

Bug #2 - Find by Formatting, Find: Colored Text, limit search to a specific color

image
image594×268 7.01 KB

Result: Find by Formatting doesn’t work at all. That is, it doesn’t find anything.

Best,
Jim

1 Like
2

Thanks for the report. The first one with the highlight we have logged, but I’m not able to reproduce the second case. Could you share the steps you’re taking to see this problem?

Here's what I'm doing:
  1. In a new blank project, write three lines of “test test test test” in the document
  2. Select the first two words of the first line and use the format bar to apply the green text colour (from the top row of colours)
  3. Repeat this for the second word in the second line and the last two words of the third line
  4. Duplicate the document in the binder
  5. Place the insertion point at the start of the first document
  6. Open Edit ▸ Find ▸ Find by Formatting... and set to find “Colored Text”, then tick the box to limit search to color and set the color to green; leave Search In to All Documents
  7. Click Next repeatedly to jump through each instance of green text in both documents
  8. Click Previous repeatedly to jump backwards through each instance
3

Interesting, Jennifer, thanks for checking.

For the second case, I can replicate your results, in the test project and in my real project. I think it was user error on my part. I was using HTML (#ff5aa4) to set a custom color and perhaps I typed the HTML incorrectly.

So all is well for the second case.

Best,
Jim

1 Like
5

Reproduce:

  1. Make several highlights in text, all grey but one is red.
  2. Menu> Edit > Find > Find by Formatting
  3. Pick the Highlighted Text value in list
  4. Tick Limit search to color:
  5. Select the same red
  6. Click Next
  7. Repeat

It will “find” all the highlighted text, even the grey ones.

1 Like
6

I would say it’s not a big deal, but since I saw that option, I decided to use it by harmonizing the highlight colors, and then, upon looking up for what I need, it fails, and so it’s a bit of a letdown (not complaining too much, just the context).

7

Thanks! I’ve merged this with the existing bug report on it.

1 Like
8

Addition:

After searching highlighted text through the whole manuscript, this leaves the last highlighted text of each sub document selected , when we get back to any of those document. :warning: Useless, mildly annoying et potentially dangerous (typing will replace!).

9

Well that should just be general intentional behaviour, rather than specific to this tool. If you double-click on a word to mark your place, and then go somewhere else and come back, it should remain selected (and scrolled into view).

10

I’d like a chance to explain it better, if I may try again.

Usually, using the search feature, it highlights (select) the first occurrence of text, and then, clicking next (or kbd shorcut) scrolls to the next find, and highlight this other occurrence while the previous is not longer selected. And this behavior unfolds like this all along the document without any exception (unless wrapping back at the first maybe).

Now, with the project-wide find, I would expect a similar behavior, even more so in Scrivener as a tool that has the ability to showcase the whole project as a single content.

And that is not how it behaves. Former selections lags behind at each document frontier, and if you consider the whole content (as a thought experiment) it seems that the selections are randomly sticking here and there, so to speak. What for? Despite the user having moved to another place to search.

This is how I see it: more inconsistent than consistent with the usual behavior. Maybe it’s a matter of point of view, but then we could look at the practical usefulness of such behavior.

1 Like
11

I do kind of understand where you are coming from, but I think the main problem here is that finding is an act of selection (and is normal to do so, as you note) which means there is no functional difference between this kind of selection, and the one you make yourself. There isn’t a second kind of selection we can use that doesn’t collide with any selection you had made prior, it overwrites it, becomes what is stored in the metadata for this item.

(The obvious exception to this is Project Search, which does indeed passively highlight all matches at once where it can, but those persist even around typing events, so it can’t really be compared to this.)

So the question then becomes, where would the selection go, if the Find by Formatting command somehow were to revert to the previous selection upon document switch? That could very well be the second to last find highlight that occurred, which would in my opinion make even less sense. But even if it were to, upon navigating into a document, cache the original selection or cursor position, and then restore it upon leaving, I think that would still be a bit weird because then it would go against the notion of Find being, in general, a hybrid selection and location tool.

1 Like