If I …
create a custom metadata field of <$custom:protagonist_name>
add a name in the inspector for one document for that field so it reads <$custom:protagonist_name>: Marco
and in the document type: <$custom:protagonist_name> walked into a bar.
… how do I get it to compile as Marco walked into a bar.?
At the moment I just get [blank] walked into a bar.
Thanks
The name of the custom metadata field itself doesn’t include custom. You just use e.g. protagonist-name. There isn’t much setup, please see this attached simple project and result using name and age custom metadata fields:
CustomMetadata.scriv.zip (61.8 KB)
Wow, a huge PEBKAC error (perhaps I should change my forum user name). I have used Scrivener for years but never worked with inline metadata in this way.
Thank you very much for the sample project and for the time and advice you have shared. Brilliant.
We Scrivener users continue to follow the long path towards enlightenment, but we can never attain it… 
I see Ioa @AmberV used different syntax types for his replacements in the Scrivener User Manual. I wonder if there is some syntax types that is better to avoid.
For example, I would find something like “<$par:edit_menu>”, “<$par:delete_command>” (for command/parameter-class variables) or “<$hw:edit_button>” (for hardware-class variables) extremely fast and easy to read. They are immediately recognizable as variables.
But would this syntax interfere with other variables in Scrivener?
Paolo
Careful not to confuse “styles” and placeholders.
“Styles” already referring to stored/recallable formatting throughout the software.
This could easily (and fast) lead to miserable confusion.
Yes, I couldn’t find a better word. But I was not referring to placeholders, but to the way they are written. In my example, the “<$” followed by a class abbreviation, followed by a colon (:), followed by the variable name, and closed with a “>”.
But now I think it should be called syntax, and I will change it in my previous message.
Paolo
Replacements are flexible pattern matchers, you don’t need to use <$...> as a template, you can use any unique text identifier e.g. {{hw:edit_button}}. You can get fancy with RegEx and groups if you need more power… I’ve used ««text»» in the past as I like the look while editing 
If you wanted to use these fragments to replace with placeholders, then there may be some problems with using certain characters like : in the label name. You could use e.g. {{hw-edit_button}} which would convert to <$custom:hw-edit_button> so the placeholder could work as expected…
Indeed, it might, in fact, be more future-looking to not use the same syntax as Scriv uses for its placeholder functionality. If you were using ‘<$var:______>’ for your replacement operation, it would be an unpleasant surprise when the next version of Scriv introduced some new placeholder functionality with the same syntactic trigger, potentially undermining the compile of any project where you had used that for your own purposes.
Great!
This works! Flawless!
Thank you so much for your kind help!
Hi there!
I wonder if I can use an editable field that once I change its value the new value is updated wherever I have placed this field along the whole document… I mean… like a variable
Thank you all
See Appendix C4 on the User Manual for Custom metadata. In a recent post I shared a sample project you can check out:
Now custom metadata applies per-document, and it may be you only want one value for all documents (like a constant)? If so, then if the custom metadata is a list or checkbox you can group edit it; otherwise for text you can use any unique text tag and then use replacements at compile to set this tag to the final value you want…
or if it is a name can just you find and replace project wide so John Bean is replaced by Jack Reacher. Once done is not reversible per se. (could do the reverse search for Jack Reacher and replace with John Bean).
