"Delete text of this style": cases where it does not work?

I am no new user of Scrivener, but this has puzzled me for a long time. If I check the option, it works for some styles, but not others. Is there anything preventing it from working in certain situations?

Moreover, in this case, annotations are not an alternative, as they won’t get removed either. I tried using custom delimiters and a regex rule to erase them, but this is also difficult as there is no way that I know to match over multiple lines (Scrivener regex does not recognize \n, so BEGIN_DELIM(.|\n)+END_DELIM does not work either ).

P.S.: It fails both when it is Frontmatter and when it comes first in the document.

At first glance, this should have worked.
Perhaps try removing your “comment” style from the style’s tab of your compile format, then add it again, using the + sign in the top right corner, and picking it from the dropdown list.
You have to make sure the style’s name matches perfectly in both places (editor and compile format’s style tab). If you added the style manually (not from your available styles list) and typed the name yourself, all it takes is an invisible extra space at the end of it (for e.g.), to ruin the operation.

If it still doesn’t work (maybe MMD is capricious?), you can try different style settings. Such as “save all formatting”, or rather use a character attribute style, include font family, font size…

But, again, aside a style mismatch between the editor and the style’s tab, this should have worked as far as I can tell.

If I bring this particular text section to the end of the outline, it works as expected. Basically, it fails when it comes first, either as frontmatter or just the first text section. I never saw anything clarifying this in the Scrivener manual (and had to spend a good many hours to notice this).

That’s odd. Looks like a bug to me.
Have you tried adding a blank document as the first document in your binder ?
Just so that document isn’t “the first”.

I’d see that as a strong indicator that there is a bug somewhere in there…
Assuming that you have the option properly checked:

1 Like

Thanks for the suggestion! It works if you add a few empty spaces to this first file. So, if I am not mistaken, Scrivener does not apply the rule to the frontmatter (which is odd).

Just curious if @AmberV or anyone from L&L can reproduce this.

I think the primary issue here is that there are two special conditions being triggered, as described in the user manual in §21.7, Using a Metadata Document in the Draft. An item named “Metadata” that is the very first item in the compile list is treated specially, and doesn’t go through as much of the compile workflow as normal items would. It’s treated verbatim for the most part (placeholders and replacements do work), and is injected into the metadata output rather than as part of the normal document flow. I.e. there might be metadata coming from the compiler that appears around what is in this document.

I would say that for the most part, the intention here is that if something needs different metadata for different outputs from the same project, then that is precisely what one would use the Front Matter feature for. If there are different editions that require different kinds of metadata, then swapping between front matter folders is how you would normally accomplish this.

Do bear in mind that there are three layers of metadata output for Pandoc/MMD. The compile Format, the project, and the “document”. We can thus provide larger global values that don’t change between editions or articles in the compile settings, leaving only the specific things that change to the document level, via front matter, and the compile Format would establish metadata that influences the overall design of the document, such as appendix-style.

But if none of that really works the way you need, you could always just dodge the problem by renaming this document, making sure it uses a Section Type that maps to an as-is layout, and handling the whole metadata block more manually. It is, after all, just text at the top of a .txt file.

1 Like

Thanks, @AmberV . Very helpful, as always. Perhaps this could be something worth mentioning in the Manual; that is, in connection with “Delete text of this style”.

1 Like