Single-source reusable text snippets

Apologies if this exists and I haven’t figured it out yet.

I’d like to see reusable text phrases, similar to using the tag in DITA. This would enable you to write a sentence in one place, and then pull it in via reference when compiled. For example, if you want to use the same line to end each document, you insert a reference to the source phrase, so any changes you make in the source automatically propagate to the rest of the places it’s referred to.

This would be pretty useful. Thanks!

Stick with DITA or use AsciiDoctor. I’ve tried using Scrivener for technical writing (I’m a professional technical writer), but it’s simply not designed for it. Once you start needing more advanced stuff like conditional statements, conrefs and includes, variables, single-sourcing and so on word processors, even those as powerful and flexible as Scrivener just fall flat, you’re better off using a tailored made technical writing solution.

It will be possible to pull content from one item into another, in the future. As for using a plain-text system, there is nothing stopping you from doing that in Scrivener, and in fact it can be quite useful as a plain-text document generator, what with replacements and the stuff you can do with the formatting pane and separators. It’s what we who use MultiMarkdown basically do, but there is nothing stopping you from using Scrivener to even put together source code if you wish.

Interesting, I hadn’t thought of using Scrivener as a wrapper to a plain-text format (other than MMD). I imagine the advantage of that is you get all of Scrivener’s organisation tools sitting on top of your project. It wouldn’t really work for me personally, thanks to my reliance on Git and lots of of build scripts but I imagine it would appeal to those who prefer Scrivener to a text editor.

This is all good info, thanks! I’m also a technical writer and use Oxygen for DITA in my day job, will probably stick to that for reference-intensive work.

The conref idea was a potential workaround the Scrivener limitation of not sharing documents across projects. I would really like to be able to single-source my poems across multiple manuscripts, but that doesn’t seem possible at the moment – if I’m mistaken please correct me! More on that here: https://forum.literatureandlatte.com/t/poetry-book-template/32873/6

Sorry for my ignorance Amber, but where’s the setting that I need to do to have Scrivener default to using plain text /on disk/?

Thanks!

There is no setting for that, I’m not sure where you heard otherwise. I wouldn’t say there is much need for it, how a program stores its data internally is rarely of interest over how you can get the data out of that format. It’s mainly an issue in cases of data recovery, but with RTF being used for storage, bulk conversion to TXT is simple.

Let’s say, it is not entirely simple, because while of course I can convert from RTF to TXT in one line of Perl, having a way to actually maintain formatting, let alone embedded pictures, is not all that simple as you need to carry along not only what you had, but also where you had it. That’s probably why even in Perl the RTF support kind of sucks. My question on that was short on purpose, as I’ve spent some considerable time on that - and one issue being that while I can make work the mapping back and forth with file system structure and rtf over txt and back, when I understood you saying you can just use txt, I specifically was missing a setting to actually do that. It was like the thing number zero I was searching when I started with scrivener, and I could not find a setting where I could say, please use TXT, always, I don’t want visual editing. A simple setting like that. Not there - and having understood, probably mistakenly, that you said it’s there, would save me a lot of time by just being too blind to see it :slight_smile:

Yeah, rich-text sucks. I only tolerate using it because of Scrivener.

HAHAHAHA

you just made my day. But let’s take into account what Amber has said about the user base. The typical author writing 50 shades of grey will want to, well, see 50 shades of grey, which doesn’t work so well with plain text. After all, yes, rich text sucks, but compared to all other options that I know of, it may be the least sucking option. It allows for embedding 50 shades of grey, but it also it allows for relatively lossless conversion to plain text for the plain text people like you and me. I mean I’ve just spent some late night hours this week to make that work, using a simple perl script. One thing I found when I looked at it this morning (http://www.mnott.de/unscrivening/) was that RTF really only gets in the way when merging content, but on the other hand, if you convert RTF to something that will maintain all your annotations, then you end up with either a file that hasn’t got a lot of annotations to start with - like a plain text marked down file - or you have a file format in plain text that will contain a whole lot of annotations, like HTML - which likewise sucks at diff, because really, you get 95 % of annotations and 5 % of content you are interested in.

I may be wrong here. I haven’t yet found a better way than the Perl RTF module that I use. But fundamentally, unless you separate text and format, you’ll always have this problem. And if you separate, you’ll need to better know what parts of the text are formatted how, and that means you have problem once the text changes, but not the format. Actually Scrivener does some nice things on .comments, putting hyperlinks into .rtf and then putting rtf in CDATA in xml in .comments. That’s actually quite awesome, and it could potentially be used as an approach for more of such things, not only comments. Because, once you’ve clearly delineated CDATA kind of elements (and I really don’t care about XML, just about separation), then you again can know where merges are going.

Every problem in computer science can be solved by another layer of indirection. Unfortunately, that also normally creates another layer of problems.