Comment out include tag? (compiler control)

US literary agents are averse to email attachments and typically ask for a synopsis plus some sample text in the body of the emailed query/submission.

However, tastes vary. Some want 1st 10k words, some 1st 10pp, some one chapter,…

I would like to have a template single-piece query document containing all possibilities I support and to uncomment whichever is appropriate.

Is there any marker to compile that says ~ignore the rest of this line?

(Yes, I could simply delete any <#$nclude> that I don’t need, but that’s far less efficient, especially if the <$includes> to omit are discontiguous, hence the very specific question re the ability to “comment out” compiler directives.)

Something I’d consider before using include placeholders is a set of search collections that look for keywords, then you can simply tag the documents that should be included and compile using that collection either as the whole group or as a filter against the entire draft. The advantage is that you can more easily manage what gets included by adjusting which binder items have the keywords, rather than manually managing include placeholders in an otherwise static list.

If for other reasons you need a different presentation around the included text which would make having a “form feed” type approach more desirable, then it would probably be easiest to have multiple such documents, meant to be compiled individually, rather than trying to get everything interleaved into one target file.

Lastly, if none of the above does precisely what you want, or would be inefficient, the way you would accomplish this is by using multiple compile Formats, and style the placeholders for each submission type. Then each Format would set the styled placeholders they shouldn’t use to delete the assigned text, thus ignoring or commenting out those placeholders. There are few downsides to this approach beyond having to manage multiple Formats—chances are you may need that anyway though for different submission requirements.

I suppose another approach could be a series of Format-specific replacements, and then to not use valid markup, like <#include-10k:some item>, which gets replaced to <$include:some item> for the 10k Format and deleted otherwise. That strikes me as lot more complicated to manage and set up than using styles though.

Those are no doubt all generally excellent suggestions, @AmberV, but in case anyone else is considering the same (or similar issues) , let me explain why my workflow is as it is and why I, perhaps in ignorance, don’t think they fit my need. (and apologies if the following explanation isn’t entirely coherent – I’m in a hurry and really just wanted to acknowledge)

  1. I have numerous “snippets” for inclusion, depending on submission requirements (pitch, hook, genre, market, blah blah blah. Sometimes they stand alone, sometimes they might be “embedded” in a larger piece of text. I don’t fancy doing that with compile formats.

  2. I could use collections, but don’t want to think about setting up and being able to see the ordering (and not being able to see it until I invoke compile), and without investing more time that I feel like at the moment, managing keywords etc. seems even more opaque than what I have at the moment.

  3. I do have “multiple such documents” but the easiest way to manage the enormous multiplicities is, for example, to make them hierarchical. Thus I have a “template” query letter with certain standard elements, and a specific <$include…> that addresses the specific agents’ likes etc. as noted from their “see my…” profile or MS Wish List, and within the letter or the “specifics” sub-document I drag in elements as required.

I guess the answer to my specific question was, ultimately, “No.” :wink:

So why then does commenting out these placeholders (and whatever static boilerplate text around them as necessary) with styles not work? That seems to me a direct implementation of what you originally described wanting to do.

TBH I didn’t really understand the details of the “style” and format approach and maybe I’ll look again another day, but at first blush, styles also don’t seem as efficient as deleting a single comment-marking character at the beginning of the line, which I was hoping for (but not expecting).

Not an issue. I just wanted to know. Thx :slight_smile:

If you must use a text marker that you type in, then what’s wrong with a variation of the fourth idea, which can do exactly what you described? Regular expression replacements can look for ~ignore.* and zap to the end of the line. Maybe add a follow-up replacement to replace ¶¶ with to clean up any empty lines left behind, too, where that may be used at the beginning of the line to remove the whole line.

I think maybe the style notion is less of an issue that you’re thinking of though. It’s quite easy to use. The user manual for example is positively littered with such styles, wherever Windows/Mac descriptions differ. It’s a very visual and obvious way to work with singular texts that has multiple outputs.

Thank you for all the suggestions, I’m just not in an experimental frame of mind right now. I can work with what I’ve got. :pray: