Applying a Template Removes Pre-Designed Formatting
Before the Properties feature was implemented, I would create a new file, then apply a template to the file. The way I use templates is to have commented out sections with common options that I could simply move into the appropriate variable field instead of having to type it in manually every . . . single . . . time.
CHANGE the Properties Feature to NOT Re-Format Frontmatter
As the author of the frontmatter being implemented in any given template, obviously it should fall to me to decide what the frontmatter looks like. The software should not tamper with the design of the author, that is overstepping its purpose as a software.
Regarding your specific use case, you will get suggestion based on the values of a property present in another file. There is an open FR about enumerated types.
I also have a similar use case to the thread starter!
As useful as returning suggestions from other notes is, it’s not the same thing as leaving your future self inline comments. They’re there as gentle reminders of the purpose and intent behind a particular piece of metadata. It can be easy to forget when you have dozens of templates and lots of properties! It’s akin to leaving // code comments during development. They’re helpful there and they’re helpful here too!
For now, I’ve had to move all my comments out of the YAML (I used to use ==highlighted comments==) and dropped them into an admonition beneath the Properties section as a workaround
I’m not entirely sure I understand your last comment:
But it sounds as though you’re warning me that my way of doing things will result in exactly what I’m trying to do. Any time I need to refer to the variables in the same file I use “this.variable”, and with dataview I add “LIMIT 1”.
The purpose of generally any variable I add to frontmatter is to make it relevant to dataview. And, as long as comments continue to function in frontmatter, I will continue to use them. So, the only thing the update does in my case is add frustration and extra steps to yield the same results.
I do thank you for your time though; I searched for the content of my post, but did not find the post you referenced, so that is helpful.
I am not sure there is a misunderstanding. My comment was because I noticed that you used comments as guide for a prefix set of values. I said you will get suggestions based on the values present in that properties in other notes and there is another feature request for having enumeration type properties.
Anyway, more broadly, we will rewrite things for the reasons outlined in that post. I understand you and others don’t like it, but we made this call.
Thank you for clarifying, I better understand your response now. I can see that working later down the road, when there are more similar files already filled out, but I also see that becoming a problem. For example, when I have multiple categories of templates that use the same variable names but serve different purposes.
eg:
Building Template vs Quest Template. The variable “type” has broadly different meanings, but is the ideal variable name. From what it sounds like, I would make a new quest file and start typing in the variable “type” and would be prompted with things like “house” or “apartment” instead of “delivery” or “subjugation”.
This shouldn’t be too much of a problem for future projects, but cleaning up older vaults will be a headache; especially when I have to edit hundreds of files.
On a related question, what does the [Settings > Core Plugins > Properties view] actually do? It doesn’t seem to change anything, whereas [Settings > Editor > Properties in document] does all the changing.
The best solution that I have found is to simply remove the first line “—” from my templates and add that in after I apply the template. And since, when you apply a template to an empty document, it starts the cursor at the top, it’s as simple as typing “—” + return/enter.
As long as you don’t use the Properties sidebar or top of document stuff, it won’t re-format your document.
If you go to Settings > Editor > Properties in document {Hidden} it won’t appear at the top of the document, and you can continue to work as usual, with just a little 1/2 extra step.
A solution to the recent mess with properties could be to display alternative names specified by the user and visually replace this way the new property names, so user could call the properties whatever else they want to see on screen.
Under the hood Obsidian would use its new name convention but on the surface users would see displayed the property names as specified in their property preferences.
I’m not sure I’m following. If you want the property to have a different name, give it a different name. It won’t link up with the other properties with the same name anymore, but then, if you give it a different name, it sounds like it is serving a different purpose and should be separate anyways.
That said, this is completely alien to the purpose of the OP. The main complaint I’m making is that I would like the Insert Template feature to not alter the frontmatter on use. If using the Properties top section or side bars alters it, so be it, I don’t use them anyway. But It would be nice if it didn’t change the frontmatter when using Insert Template.
I mean, properties needs more options, like the ability to configure hard coded name conventions for some properties, - but also the ability to parse default placeholder strings. (I didn’t explain myself too well because of my own stubbornness to accept some recent changes, oops )
