Remove Current Revision Color fail

[Joy Livingwell]

Remove Current Revision Color is not working as described in the manual.

If it works at all, which it mostly doesn't, it only removes the revision color in the first document open in the editor, and then sometimes only in text before the cursor position. Most of the time it doesn't seem to recognize revision text.

I thought maybe something was wrong with my project, so I created a new one and ran some tests. Same problems. Ideas?

MacOS 10.10.5 Yosemite
Scrivener 2.8.1.2

[AmberV]

I cannot on first attempt reproduce the problem. I created a fresh copy of the tutorial and split the introductory document into three chunks, selected them all and set the view mode to Scrivenings (I presume this is the condition you are describing when you say only the first document works). I set the revision level to One. I then selected three words, one in each chunk, and used the Format ▸ Revision Mode ▸ Mark Revised command to set them to red. Going by your description, I put the cursor after the second marked word and use the Format ▸ Revision Mode ▸ Remove Current Revision Color menu command. All three instances were stripped out and the text returned to black.

I would double check that the colours are correct. Use the Edit ▸ Find ▸ Find by Formatting... menu command, set the find mode to “Revision Color”, and select the colour associated with the level you are trying to remove. If you walk through the document with the “Next” button, are all instances matched?

[Joy Livingwell]

Yes. That was how I ended up manually stripped out the colors. Using an Automator workflow, naturally.

Scrivener basically ALWAYS does what it should, so I'm puzzled to say the least. Hmm, I should try reproducing the problem on another machine & macOS version...

[AmberV]

The macOS version might matter—when we were testing version 3, we found that revision colours that had been set a long while ago sometimes wouldn’t register (but in that case, even with Find by Formatting) as being that colour. It turned out that on older Macs a different colour profile was being used by default (Display RGB vs something or other, I don’t recall at the moment), and given how RGB info is stored in the text file, it was causing these colours to be slightly wrong.

So maybe if you’ve got multiple Macs going on with different versions, test from that angle and see if the problem happens more often when marking things on one machine and trying to strip them on another. I’d still expect the format finder to fail as well if that’s the case, but it’s worth a look.

Unfortunately I cannot test your scenario precisely as I no longer have a 10.10 installation. I was testing with 10.12.

[Joy Livingwell]

I've been passing the original project I noticed the problem with back and forth between a Mac running Yosemite (10.10) and another running 10.6 Snow Leopard. But I don't see how that could have caused this problem, because my test was to create a NEW project, and apply revision colors to NEW text. Scrivener still didn't find and strip out all instances of those revision colors, even though I had just created them moments before. Weird.

[shrumpkin]

I too have had this problem, and Amber is correct in mentioning older OS versions, since I had added the revision colors while running an older version of the OS. The revision colors wouldn't strip.

[Joy Livingwell]

Amber, if I do what you did -- select one word in each of several documents and select Mark Revised -- I don't get the problem either!

If I create a new document (using the Blank template), there is ONE document in the Binder, I type some text into it, then turn on Revision mode and type more text, Scrivener will correctly remove the colored text.

But if I make copies of that document, Scrivener will NOT remove the current Revision color from colored text in those documents that got duplicated, only in the first one. Regardless of whether I select multiple documents or only one.

Now I Mark Revised or type text into those copied documents after I copy them, Scrivener will remove the text that got colored after the document was duplicated... while ignoring the text that was already colored when I copied the document. (It does remove the coloring in the first document selected in Scrivenings mode, even if that is a copy... but skips copied colors in subsequent selected documents.)

In all these cases, Scrivener can find same text just fine using Find by Formatting > Revision Mode.

The crucial element seems to be making copies of the document after Revision Mode color is applied. Once that is done, Remove Current Revision Color stops recognizing the copied revision color in those documents, even though Find By Formatting > Revision Color finds those instances, and even though Remove Current Revision Color still works to remove color from sections of documents that got colored after the document was duplicated.

I can get the problem to happen and not happen to text with the same color in the same document if some resulted from typing in a previous document and then copying it, and some was typed or Mark Revised after the document was copied. The duplicated coloring doesn't turn black (except in the first document); the typed coloring does.

I have now replicated this problem in both old and new documents on both MacOS 10.10 Yosemite and MacOS 10.6.8 Snow Leopard.

Amber, please see if you can replicate the problem doing what I did:

1. Create a new Scrivener project using the blank template (rather than working from the tutorial)
2. Type some non-colored text in the default document in the Binder
3. Turn on Revision Mode & type Revision-colored text here in there in your text (I inserted both individual words in the text and entire paragraphs in each revision color I used)
4. Repeat with at least one more revision color (I used 4)
5. Make several copies of the document by selecting them and clicking Command-D
6. Select all of these documents in the Binder in Scrivenings mode so you see the documents stitched together
7. Place the cursor at the beginning of the first document
8. Now try Remove Current Revision Color, and see whether it removes ALL instances of that revision color in ALL the documents

HTH
Joy

[AmberV]

Excellent, that seems to do the trick!

I also tried using the Remove All Revisions command, which successfully removed *all* red markings, but again the orange markings remained.

So I tested all of the colours, and it looks to me as though levels one thru three work fine no matter what the conditions. Levels four and five do not work under these conditions. I can even reload the project, load one document all by itself, and find it unable to strip out orange or purple markings.

[Joy Livingwell]

Good catch, Remove Revisions is buggy for me, too.

I restarted the machine between creating my test document in MacOS 10.10 YoOS, and when I tested Remove Revisions just now, it didn't remove ANY revisions that I saved in the previous sessions, however created (I used First through Fourth Revision). It DID remove revisions I typed in THIS session.

So it's official: we have a bug, Houston.

[AmberV]

Yup, turns out the problem has to do with how colours are loaded out of the underlying RTF. It works in the editor you start with because that one was never loaded off of the disk as RTF, it was held in memory the entire time and so all of the codes are spot on. Once you close and reload the project, then it has to go back to the disk of course and the first file no longer works.

Now unfortunately there won’t be a fix that on 2.x, hope you understand, but it will be fixed for 3.0.3 and onwards.

[Joy Livingwell]

I understand. I'm still using 2.x because I use older versions of MacOS so that I can continue to use legacy software that got unacceptably buggy in later versions... and because I have colleagues working in Windows and we need to pass projects back and forth. Scrivener is about the only software I would even CONSIDER upgrading my OS for... but I'll probably hold out for the Windows version of 3 first.

Anyway, I'm delighted for an opportunity to give back to Scrivener, which has made my writing life ever so much better! Thank you for your fine work in this regard, too.

[AmberV]

It’s probably just as well, 10.13 is pretty buggy still, and I don’t think you can upgrade to 10.12 any more. I’m hoping that 14 will be a bit better, but then one won’t have the option of running 2.x at all as I understand it.

At any rate, thanks for the help in tracking this one down.