My hope is to be able to edit the files in a different application, save the changes in the sync/external folder, and retain the original comments/metadata without having to do an extensive roundtrip. In other words, some times editing something in Pages or Microsoft Word (just a different look) allows me to see mistakes and typos I didn’t see in Scrivener (and vice versa). But true compiling and round tripping is very time consuming. If I were to edit these pieces in sync mode, my hope is that comments /footnotes/notes/ect are all intact, no? right now I am going to a mess of hell to reimport changes I made.
I wonder if you have tried doing what you want just using a Scriv-Word-Scriv workflow? You can compile to Word format and have the compile format place a marker at the start of each constituent doc in the compile. You can edit that doc in Word (leaving the markers alone — it is even possible to protect those in Word, if you are worried). Then Scrivener’s import function can bring that document in and distribute the pieces of it back to their respective source Scriv docs (snapshotting each for safety before it replaces it with the updated text).
Perhaps a more trouble free round-about for what you want?
That workflow destroys metadata, links between documents, document bookmarks, snapshots, synopses, document notes, and maybe a dozen other things I can’t think of off the top of my head. But it’s fine if you don’t really use the power of Scrivener. Most people don’t, I suppose.
2 Likes
Yes, this is exactly the problem. I am working on a very research heavy nonfiction book and have tons of comments etc and notes and bookmarks. To keep notes etc Round trips still require a hand merge and delete method. By the way no one has ever gotten back to me about that bug in support even tho I’ve sent it a dozen times. There’s gotta be something we can figure out?
Do you mean a custom paragraph style on one or more paragraphs, while H1, H2 … is used on others? Or do you mean a custom character style? The latter works for me just fine. I don’t use ANY stock styles.
Proper editing is always manual. You have to do the work of viewing the comments someone may have added, deciding what to do about it, and making the change. If you don’t want to do that, then Compile once to Word and leave it to an editor after that.
1 Like
Uh … I don’t think you understand. I’m talking about importing these files after I’ve edited it.
I do understand, and I’m advising you not to import Word files. If you edited them yourself, why didn’t you do it in Scrivener?
1 Like
See other reply.
I export because I have to send it to people and I do an edit in word because you catch mistakes when looking at it in a different app
That’s fine.
Export and send it. But don’t import those returned Word doc’s back into Scrivener and expect magic.
Yes, and then I’m suggesting you view those changes in Word but make them again in Scrivener to avoid losing metadata, snapshots, and the whole nine yards … and avoid bringing Word field codes into Scrivener that sometimes lead to corruption. Do it your own way, of course, but that’s how you avoid losing comments, metadata, etc.
Worse, I may have just dreamed up this functionality. 
The phenomenon is well known amongst writers that a different look of a text helps to detect mistakes, recurring wordings, etc. (And for me print still works best.) There was a version of iAWriter that put a focus on that by offering, if I remember correctly, five different view modes.
I have to submit in texts for a magazine as .docx and before sending it I read that .docx even though I had emended the text in Scrivener for numerous times already. But it’s a different use case than yours—if I actually find something I have to correct I return to Scrivener and compile again. No re-importing of the text.
A simple suggestion: How about using different settings in the standard editor and in Compose Mode? Changing the line-width for example re-arranges the text. I can’t tell if that will work for you, but it surely won’t take much effort to try.
1 Like
Very good suggestion.
That’s how I do it.
Just changing the width of the editor so that the lines lineup differently is often enough for me.
Like making the editor as narrow as an e-reader.
Then, once I got used to it, change it somewhat again.
1 Like
Put it on the wish list.
Our initial test cases involved styles (any styles, including built-in) that were making use of the previously mentioned attribute. When this attribute was removed, syncing and exporting worked fine. This doesn’t necessarily imply that all styles with that attribute may break, or even that within that simple test, removing them was the only trigger. Bugs can sometimes have multiple triggers that only appear in certain combinations or scenarios.
Since then we have discovered other triggers as well, so I think it’s safe to assume there is some underlying bug that causes multiple different triggers, not all of which are known or easy to find. In short, not all styles break the feature, but any use of styles may break it.
Regarding round-trip editing and such, there are a bounty of existing discussions on this matter, here are a few:
- Round-tripping from Scrivener-to-Word-and-Back ?
- Export → Process/Edit → Import (ideally retaining binder layout and styles)
- Editor Use Case
I’m very much the same way, and as someone else posted, I think most of us are. You form blind spots that are unique to the working environment, and removing your work from that environment greatly aids in spotting them (I even do that for my forum posts—I’m typing this up in a Markdown editor, but I’ll be proofing it using the forum’s preview). My own approach is to compile to the end format, and generally in a form I can’t edit. Its only purpose is to divorce the content from the original environment. For me, that’s PDF. I drop the PDF into my Project Bookmarks list, and when I’m ready to proof, I drag from the bookmark list into my split editor’s header bar, which views it straight off the disk (no need to import and clutter up the project with proofing copies). See below for tips on making this PDF a better proofing tool with links back to Scrivener, within it.
Now I can continually compile back over that PDF file as I work, and refresh the PDF viewer in the other split. It’s easy—and I’m making my revisions in Scrivener, not some other program/file entirely that I have to tear my hair out attempting to reintegrate. For me that would be very difficult because my workflow involves starting with something that does not in any way resemble the output at any level. Since I always compile proofing copies to the same folder, with the same file name, that project bookmark remains valid and convenient for starting a proofing session. You dont even need the project bookmark though, if you prefer sequencing proofing copies with a date stamp or something, then just drag the PDF into the editor header bar from the system to view it without importing it.
That’s how I do it, but there are many other ways, and if editable text works best for you, I’d still encourage using it as-if it were read-only. The main benefit we’re looking for after all is that context shift. We don’t need to edit in the content shift copy to get all of the benefits of it. I like using Scrivener’s splits because I can PageDn the other editor while editing in the main split—but multiple program windows side by side also work. There is no one right way here. Some prefer using ebook reader software and epub output, which has the benefit of being able to read from a more comfortable environment, and jot down problems using the reader software’s annotation features.
Please don’t. 
A few searches should reveal that’s already been asked for, and here is the best answer as to why that is, conceptually speaking, not even just technically, extremely difficult.
The feature I believe @gr is referring to is more passive than that. There is a setting in the compiler (Insert links back to Scrivener in each section) that will insert special URLs into the document that link directly back to the binder item used to generate the section following that link. Open the compiled document in Word, Ctrl-click (or whatever you need to activate a hyperlink) and your project will open up, if necessary, and load that section.
There is a secondary option below that, Insert unique document identifiers only, that inserts a plain-text code into the output. These are uglier, though more robust in that they won’t get cleaned out by security mechanisms or otherwise damaged when edited in tools that don’t understand Scrivener’s links. When a document containing these markers is imported back into the binder, it will not be split by them, back into the original items because that is unsafe (for the reasons given in the linked post above), but the markers will be turned into native internal links to greatly ease incorporating revisions. Open the imported reference into one split, and by default clicking links opens the original in the other split.
As an aside, stemming from that setting, you can see we do not recommend never importing Word documents. There is a whole host of features, not just these, supporting that capability. We even built our own custom DOCX read/writer. So the suggestion one should never do that and only load up Word alongside Scrivener is a bit overkill. The main concern raised there is that some advanced feature usage in Word might “corrupt” Scrivener—honestly I’ve seen maybe two or three actual cases of that over many, many years. The risk is very low, and not difficult to revert from. And besides we’re talking about something exported from Scrivener, being edited and then brought back in. The odds of such a document being littered with advanced field codes and complicated page layout features at all is extremely minimal and trivial to avoid as you have to go well out of your way to end up with a document that includes those things. Just don’t implement an expensively designed corporate letterhead into your .docx file that you’re proofreading, right?
Lastly, as I’ve said before, the challenges of trying to get two completely different kinds of software working together on the “same source” is one of the big reasons for why many people do not consider Scrivener part of their late-phase editing workflow. If you’re banging your head against obscure bugs or simple conceptual problems that cannot be resolved, for days/weeks, then at some point you have to question whether or not it is just best to sit down in Word and use track changes. There’s no harm in that. Very few things in life can all be done with one single tool.
Some can make it work, there are good answers above and laced throughout the forum! Don’t get me wrong, I’m just saying if it is causing one frustrations there are almost always more efficient solutions that involve using the right tool for each aspect of a job.
5 Likes
I do love me some overkill, in general, but thanks for taking this particular worry off my list.
I can try that-but again, once I pull it out in word, I still go through it, because there’s always something that doesn’t format correctly. I am also in the middle of working on these drafts so I am sending these chapters out for awards or residencies and in some cases I have to format things for the chapters that I don’t want to do in the scrivener doc yet (it’s an oral history so in the final book version I will have NAME, TITLE, YEARS AT PAPER: “QUOTE.” but in the scrivener working draft, I just do the name: quote because in the book the titles will be first time appearance only. but when I am sending out these chapters, I have to insert the names and titles, hence the need to insert names in the word doc. do you follow?
so I have ‘no style’ for the text. I bold the names. I do use some block quote but yesterday when compiling I removed block quotes and created my own thing.
my scrivening titles are quotes.
would you want to look at my document to see if there’s any formatting I should kill? I don’t think I’m using headers anywhere.