Add YAML front matter to a file that includes the key “tags” and as value a list of tags formatted as '#tagname' (valid tag, valid YAML due to inclusion of single quotes), e.g.:
tags:
- '#meeting'
- '#work'
Now edit the tags inside Obsidian as part of the file Properties, e.g. by adding another tag.
The formatting of the existing tags is not changed.
Ideally: New tags use the same formatting. (A setting to handle this would also be great.)
Actual result
Tags are reformatted, the preceding hash sign is stripped.
The above example would look like this:
tags:
- meeting
- work
Environment
SYSTEM INFO:
Obsidian version: v1.4.2
Installer version: v1.2.8
Operating system: #1 SMP PREEMPT_DYNAMIC Mon, 24 Jul 2023 20:19:38 +0000 6.4.6-arch1-1
Login status: logged in
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Additional information
The reason I see the behavior as a problem is that it breaks any workflow outside of Obsidian that relies on finding tags in the files by looking for words preceded directly by a hash sign. Parsing the front matter YAML is not an alternative as that is vastly more complicated and not even possible in some circumstances where only simple text search is available.
If you don’t want to parse YAML, YAML may be the wrong place to store things.
If you just want to have tags that aren’t visible in reading view, you can put them in comments.
This bug will probably be closed because the feature is (in this case) working as currently intended. But there is a feature request to allow hashtags in text properties.
If you don’t want to parse YAML, YAML may be the wrong place to store things.
If you just want to have tags that aren’t visible in reading view, you can put them in comments.
I cannot stress enough how unsatisfactory of an answer that is. So let me restate the problem you’re dismissing so cavalierly: Obsidian is automatically modifying the content of files in a way that I cannot prevent and that demonstrably breaks existing processes!
And let’s be clear here — what Obsidian currently does in the front matter is not a simple reformatting. #foo is a tag, foo is just a string like any other that only Obsidian will still recognize as tag.
The base promise of Obsidian is that it works on standard files without a proprietary format thus allowing compatibility with other apps and preventing lock-in. This basic promise is being broken here.
Suggesting to just no longer use the YAML front matter is ridiculous. That’s where meta data belongs. It’s a feature supported not only by Obsidian but other Markdown editors as well.
This bug will probably be closed because the feature is (in this case) working as currently intended.
The moment “working as … intended” is confirmed as the developers’ official stance is the moment I will start looking for Obsidian alternatives because this would be the first step in an alarming direction.
I’m not dismissing your problem. The text you quote was specifically in response to this:
(Which contradicts your more recent statement about YAML’s wide support.) I thought if you felt YAML wasn’t portable enough, then why use it in the first place? (YAML isn’t portable enough for me, so I only use it for aliases.)
Putting foo in the tags field has always been the only way to put tags in YAML in Obsidian. I understand your desire to put hashtags in any field, but that’s new behavior that has never been supported. That’s why this bug report is likely to be closed — the team only accepts them for existing features that aren’t working as promised. A feature request is more appropriate. One exists already because you’re not the only person who wants this, so I pointed you toward it to help you further your goal.
It’s not ridiculous — I do it myself. There are many ways to use Obsidian, and no need to mock others for doing it differently.
This is a beta feature, subject to change. I believe the current behavior is intended, but it’s not set in stone. There is discussion happening in the feature request I linked and in the Insider channel on Discord. You can upvote the feature request by pressing the heart under the main post, and add new info in a comment. Here’s the link again for convenience:
(Which contradicts your more recent statement about YAML’s wide support.) I thought if you felt YAML wasn’t portable enough, then why use it in the first place?
You’re misunderstanding my main point here. I have nothing against Obsidian using YAML, my problem is that it changes the existing YAML content.
Putting foo in the tags field has always been the only way to put tags in YAML in Obsidian.
That is just not true; you absolutely can put real tags written like '#foo' in the YAML front matter (quoting is necessary because the hash sign is used for comments in YAML). This still works, those tags are recognized as such by Obsidian.
I understand your desire to put hashtags in any field, but that’s new behavior that has never been supported
This is not at all what I’m talking about (see below).
It’s not ridiculous — I do it myself. There are many ways to use Obsidian, and no need to mock others for doing it differently.
I’m not mocking you. I’m dismissing the idea of throwing out a perfectly working baby with the bath water. Not only is the front matter generally a good place for tags if you want to separate meta data from your text, the introduction of Properties seems to indicate that it will become more important in the future for new Obsidian features and plugins handling meta data.
You can upvote the feature request by pressing the heart under the main post, and add new info in a comment. Here’s the link again for convenience: […]
The feature request is not about the use of hash signs for tags but the recognition of tags in YAML lists other than the one called "tags". But you might have noticed that the request in its example uses the same tag format that is now broken, which is what my bug report is about.
I understood your main point; I was clarifying something I think you misunderstood.
I did not know that! I’ve somehow never encountered (or remembered) mention of it and it’s not documented in Tags - Obsidian Help. That undercuts everything else I was saying.
I did notice that, and thought that part of what they were requesting was to allow the hash mark to work. (They don’t actually say that.)
One of the goals of the new Properties setup is to prevent malformed YAML, so it writes in a standardized way and sometimes changes the format of existing metadata. I thought the removal of the hash mark was part of this, but that seems not so likely now.
It happens, I’m glad it’s cleared up now. And I’m sorry if anything I’ve written came off a bit harshly; this issue is really important to me. Losing the ability to find tagged files outside Obsidian with something as simple as rg -l '#foo\b' would be a big loss of functionality; and no longer being in full control of your own data, i.e. what gets written to your files, seems like a breach of trust the users have put into Obsidian and its developers.
I can imagine that the devs will come up with a solution for this, since there are several people having issues with the tag formatting. Maybe in the settings of the Property feature having the possibility to select different flavors of formatting the yaml.
Personally, I don’t mind if Obsidian flags YAML as being invalid (in its opinion), but I don’t like the idea of it actually rewriting the YAML, potentially changing thousands of lines without review or approval.
Thanks for adding the video; that makes it really clear what’s happening.
Touching the Live Preview Properties UI once reformats everything. I ran into this with quoted aliases.
I could even live with automatic reformatting of the YAML code but changing e.g. '#meeting' to meeting is not reformatting but actually changing the value, which is only obscured by Obsidian handling them the same (inside a list called tags).
YAML is not a mess and is much better standardized than markdown. However, it is hard to write properly formatted YAML by hand.
We have decided to take a more active role in the YAML management and preserving exactly what you wrote is non-goal of change. As long as what we rewrite is semantically the same, we are gonna be okay with it.
Regarding this specific BR: yes, we intentionally introduced a semantic change. We deprecated the format “#atag” and when we encounter it we rewrite it without the hashtag.
Please, keep the thread in topic with rants about point number 3. Rants about point 2 should go in a separate thread.
I tested a number of separate approaches for “protecting” formatting on property values (even ones that have been moved into the lineated array syntax) when editing properties through the interface, and found that the only protected syntaxes are '"ex"' and "'ample'" , which for the purposes of tags at the very least are quite cumbersome. The tags will assume a “true” form of #"ex" and #'ample' respectively (henceforth “double-paired” strings).
Additionally, modifying any property or adding a new property will fully reformat all entries excepting those that are “protected” in the manner described above—yet if this is deliberately avoided through only modifying the YAML through Source Mode, single-paired strings will still be appropriately recognized as tags.
Proposed solution
Personally I’d like to see at least one of two options:
The forced formatting should be reduced or made more permissive, such that single-quoted values may be preserved since they are already recognized by the app and function correctly even in the Catalyst build of v.1.4.0.
The YAML Frontmatter should be made to either explicitly disallow single-paired values with regards to native functionality, such that the following would no longer be recognized as valid tag syntax for any native features of the app.
tags:
- "#ex"
- '#ample'
Current workaround
The only present solution is to avoid using the Property interface and only edit the YAML Frontmatter in Source Mode or through external text editors / programmatic methods.
Related feature requests
None at present, will be updated as brought to attention.
Thanks and Miscellanea
This issue was opened following and initial observation by @mediapathic , and his insights and suggestions regarding this feature request should be taken with greater priority than mine since it directly affects much of his work.
@WhiteNoise, thanks for commenting but what you’ve written leaves me with some questions.
As long as what we rewrite is semantically the same, we are gonna be okay with it. […] Regarding this specific BR: yes, we introduced a semantic change, […]
That sounds to me like you agree that there is a bug that should be fixed.
[…] we deprecated the format “#atag” and when we encounter it we rewrite it without the hashtag.
This on the other hand sounds like it was a deliberate decision.
So, could you please clarify the current status of this issue? And if there is a decision either not to treat this as a bug or not to implement a solution, I’d be interested in a response to the criticism expressed in this thread and elsewhere.
Edit: As a meta-commentary to this bug report — I find it extremely confusing how these forum threads have now been merged and split and why this one is apparently scheduled to be deleted in 7 days. I understand that any additional system needs maintenance and focus but an actual issue tracking system would be preferable to this slight misuse of a forum.
My bullet points were an attempt to separate the different issues raised in this thread.
Again, specifically for tags, stripping the # is an intentional change not a bug (along with deprecating tag in favour of tags).
As of now, there are no plans of revering this change.
I am sorry for the inconvenience, there is also the FR that @CawlinTeffid posted, which may address what you are facing.
@WhiteNoise, so I understand this correctly — the criticism of this change is ignored, not even given the courtesy of a rebuttal, and to top that off it will be deleted from this forum?
there is also the FR that @CawlinTeffid posted, which may address what you are facing.
If you had read the previous posts, you would know that it doesn’t. I also don’t care for the stance “we broke it but intentionally, so it’s not a bug; perhaps ask for the ‘feature’ of getting it fixed.”
This encounter has left me disillusioned. I like most of what Obsidian has done in the past but using it always came with the risk of any proprietary software. Well, there is no license to cancel, so … have a nice day?
