Yes, that’s a good solution for those using styles! Since Scrivener has an awareness of a clear start and stop position, we can be much more confident of how to fix the mistake, than just taking the asterisks result and trying to figure it out from that.
@bernardo_vasconcelos: Where can I find the exact order of the processing that takes place during compile?
There is very likely no such reference, mainly on account of how complex the compile process is, and how it would be different from one file type to the next. Even just how Replacements work is a lot less simple than you would think, running multiple times at different points to catch different use-cases. I often run into cases where, even so, they do not do enough or are not able to see the end result of things before compile completes. Having the Processing pane around to pick up those cases, with sed one-liners or little Ruby scripts if I need more, has been a blessing.
I am applying a style to the text that will get added as a prefix to a section (under Section Layouts). Apparently, I can add the style, but it doesn’t do anything. That is to say, the markup never appears. Is this expected behavior?
Hmm, yeah that looks like a bug to me. This is working fine in the Windows version, but the Mac is ignoring style settings in the Layout prefix/suffix.
The problem is I cannot simply add the tags to the keywords placeholder in Section layouts if I don’t want to end up with a bunch of empty tags (which I tried cleaning out using the replacements, but that doesn’t seem to work).
Yup, I’m well familiar with that issue though in a different area. I like to use a custom metadata field to create custom heading IDs, so I can change headings like this:
#### Options [prefs-appearance-editor-opt] ####
Fortunately in that case though, typing the brackets into the custom metadata field is not a big problem, and even works in my favour since I often want to copy and paste the value into the editor to make a cross-reference link, which needs the brackets anyway.
That won’t work for what you are trying though. If the style issue can be fixed, I would say that approach is the right way forward. It handles the problem neatly. Here is the Windows output test of the idea:
<!-- frimba, dri, korsa, morvit, tolaspa, srung -->
# Test Output #
Whik gronk; thung epp rintax whik jince dwint srung sernag nix la quolt sernag brul jince. Twock, quolt whik tharn dri cree gen...
# No keys #
None at all.
You can see the empty lines where it would have been, but that is not a problem with Markdown of course.