This sounds ok. Most of the users of Obsidian probably wish to maintain the original appearance of their notes and are not very willing to have them modified by others. I hope Obsidian can continue to uphold its initial slogan, “For you forever.”
4 Likes
Might there be a way to use a CSS snippet to override the UI mode in Live Preview and force the editor to show the raw YAML as it appears pre-1.4?
Additionally, would a CSS snippet be able to increase the line density of the UI mode?
As WhiteNoise stated: “Initially, the frontmatter was indented to be used and managed by plugins only. What happened in reality what that users started using the frontmatter section, often in a non yaml compliant matter. So here we are today, we have decided to provide assistance to those users.”.
Obsidian upholds the stance It's your data and does not modify anything, except for complying with formatting rules – be it Markdown, YAML etc. – not to break the application’s functionality. I applaud that.
If you decide to install plugins that use and maybe even change the YAML data to give you the experience you want to have, it is your decision.
1 Like
Arrays are also a valid format for frontmatter, just like this: tags: [foo,bar,baz]. It’s not necessary to strictly adhere to the list format, and using a list format might affect your ability to perform global changes in VSCode.
3 Likes
I am confident that they will enhance the experience regarding the possible formatting within the rules at a later stage.
I’m glad to note that the “properties” is provided in the form of a plugin, and the property UI can be disabled without being imposed on all users. In fact, UI operations are so inefficient that they might attract some users, but those who were initially drawn to Obsidian might not appreciate this redundant mode of operation.
3 Likes
The Properties enhancement is, in my personal opinion, a big step away from the plain-text ethos that drove Obsidian initially, and I would welcome the option to just turn it off and use the pre-1.4.x YAML method.
7 Likes
Yes, please, for this feature request.
I prefer editing my notes, including YAML, using Live Preview. The property editor isn’t doing it for me, and slows down my workflow. Same goes for switching back and forward between Live Preview and Source modes just to edit the metadata as plain text for my notes.
Please bring back the option to edit YAML directly (as plain text) in Live Preview without using the property editor UI.
3 Likes
Just a change to my previous post, Obsidian v1.4.3 will introduce a 3-way setting for properties in the document (visible, hidden, source). I am gonna mark this FR as done.
17 Likes
I agree with pmbauer. Unless there will be a choice to opt out and use metatable instead, and (even better) choose a preferred semantic style (even better key by key basis), I will never update again. It’s a very bad move and against the philosophy that Obsidian held until now.
1 Like
This?
- Settings: Added a new toggle to show properties as source (YAML) in Live Preview.
what maybe you and @pmbauer don’t think of: for who is YAML made for? It is not for like markdown where you can do what ever. If you look at it that way, it’s actually a good thing that you get an interface to manipulate the YAML instead of doing it by hand. Let a machine help you write valid YAML that is primarily made for machines to read.
2 Likes
what maybe you and @pmbauer don’t think of […]
Gee I never would have thought of it like that, never even occurred to me. My world is changed.
Different people like different things. I’m thankful that 1.4.3 has the option to edit yaml as text again in LP.
5 Likes
you’re welcome, champ
I think there is something that you didn’t think of: YAML is not just for machines. It was specifically made so that humans could write and read code which would be easy to read for a machine because JSON is not as human readable and is a mess. The important point of YAML is that you can edit it as plain text and it must be as easy as possible. Technically, your apologizing rhetoric could justify Obsidian turning YAML into JSON too. Na-ah. Not having that.
Also consider this: I have a key created_at which uses ISO-8601 standard to write time. However, you can write it differently. I write it like this: YYYY-MM-DD"T"HH:mm:ss.SSSZ, which saves year, month, day, hour, minute, second, millisecond and the timezone. I need it to be exactly this way because I might be traveling between timezones in the future and this info is important to me. That’s why if Obsidian decides to drop it, it’s a dealbreaker, information is lost. Also I want it to be using exactly this style using hyphens and colons to be consistent across all files. That’s just one example of absolutely unacceptable behavior.
More tolerable is something like turning a list which is done using hyphens, into a list which looks like an array. But it is still mildly annoying, since I like to store location in the list that looks like an array, and tags in the list which looks like… well, a list, so that I can add them or read them easily while in plain text mode.
I say interface for YAML sounds great! But provide this interface with all the features YAML has in plain text mode and don’t restrict it! It includes how you write time, lists, and also nested keys.
The current issue with Obsidian rewriting YAML is that at times I want my value to have a line break, and I believe this is valid in YAML, but Obsidian keeps removing the line breaks. What about issue with hierarchy? With the new Properties view we need to sacrifice some YAML features?
Edit: Whitenoise already linked a related feature request for hierarchy support in YAML here
1 Like
Yes exactly. Properties look nice and clean, but they are invasive. They take away the features. That feels like something that Apple would do. But Apple does stuff for convenience without being that much considerate about client preferences on how and where to store their info. Leave “It just works” for them, I come to Obsidian for “It just works the way I want to”. Is there any good reason not to include extensive settings options?
If Obsidian had chosen a different metadata format for plugins - like a json sidecar, there could be no conflict. If it had kept plugin YAML separate from user YAML, as originally proposed, there would be no conflict (but some users wouldn’t like their separation). As it is, Obsidian needs a consistent system that works across plugins and a way for users to add their own homebrew that’s consistent with the plugins.
1 Like
Stabilisation before public launch ?
Read this as: releasing a functional core feature working for most (at a “basic” level) which can, later on, be improved depending on the feedback/use cases/bug reports…
(This is just my 2 cents 
)
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.