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.
It does because you would be able to to put tags with a hashtag in lists and those would be picked up by your regexp.
It does because you would be able to to put tags with a hashtag in lists and those would be picked up by your regexp
No, you have not understood it correctly, and I’m tired of arguing in what at this point is just support theater (“move along, no bugs to see here”).
So then those hashtags would be retained but ones in the tags field would be stripped? That seems confusing and inconsistent.
First, me pointing to that FR was not an endorsment that that feature request will happen.
Second, if that FR does happen (detecting tags in list items), then certainty the hashtag must be present otherwise we couldn’t distinguish a tag from a simple string (in the context of a list of items).
I wanna add that one of the reason for keeping the tags: property without hashtags is for compatibility with static sites generators like Jekyll and Hugo.
But why enforce the change on everyone?
Why have all users got to have their YAML rewritten just to support those people who also use Jekyll and Hugo? Those people can learn to write for the platforms they use, can’t they?
From the Obsidian website:
Your thoughts are yours.
Obsidian stores notes on your device, so you can access them quickly, even offline. No one else can read them, not even us.Your knowledge should last.
Obsidian uses open, non-proprietary files, so you’re never locked in, and can preserve your data for the long term.
These don’t correlate, IMO:
These are questions. Just trying to make sense of what looks like significant contradictions between what is being claimed and what is being done.
I would think the compatibility with other text editors is the most crucial feature. There one would search for #foo . The stripping in YAML breaks this.
I don’t know Jekyll and Hugo… I can’t imagine they’re more important.
Additionally it was also the behavior I simply expected from Obsidian. That I would have to type tag:foo is surprising, cumbersome and not easy to spot (one would have to know that results are missing).
This also breaks Quicksearch (the CTRL-F search and the \ search via VIM-mode). None of them show the tag: result. I would consider that broken - unless users are supposed to consider several caveats and inconsistencies when using these basic features.
As for workarounds such as using comments: most importantly it’s counter-intuitive. The logical assumption for most users would be that this is exactly what the properties/YAML are for. Users would have to invent their own additional metadata-system. Either on top - cluttering the start of files, or at the bottom - which splits the metadata and is incompatible with other features. E.g. when one extracts headings to that file. They get put after these comments. One would have to fix this structure each time.
The simplest solution seems to me (as non expert) to make the list array - "#foo" the standard format. Or at least not strip them. It seems compatible with YAML.
PS: Just as a twist, I’ve seen tutorials using - " #foo", which enables auto-completion.
“CTRL-F” is for finding text in a single note. Tags in Obsidian apply to whole notes, so there’s not much reason to implement tag search there.
From my point of view, all that’s happening is that the YAML is being tidied and systemised with an expectation that it will reduce the number of issues faced by users who write their own. The possibility of this happening was always there, as evidenced in my post from 2020.
In Python, the simplest solution to handle changing properties is using the JSON module.
To do this, you’d load the JSON module, read the properties from the file, change a value in the returned dictionary, and then use json.dump() to dump the changes to the file.
This is ultimately the simplest solution, which is why the developers went with something like this. I don’t think they considered users wanting to preserve the formatting of their YAML, that requires extra work to allow for that.
I’m expecting that whatever equivalent module they’re using for YAML, the module strips out hashes or treats them differently in some way, so they are ultimately removed in the yaml.dump() process.
If the user does something weird with the formatting, the code that reads the YAML is then expected to notice that pattern and repeat it. That sounds like a lot of extra work, so I can understand the non-enthusiasm for this. It would be very cool though.
It sounds like some custom YAML interpretation and writing is in order here, which ngl sounds like a fun project to work on, though is possibly outside the scope of Obsidian development.
Ok, from that perspective then the search is broken, because it doesn’t show all results that are in the file one is searching in.
For the user this is getting too confusing. The quicksearch returns hashtags (#foo), but not tags, right where the user would expect them. So tags and hashtags are not the same … but then when using the other search they are (both tag:foo and tag:#foo return the tag. But then the normal text search doesn’t. The user has to notice by themselves that results are missing in some searches. Then they need to fix it, by inventing their own metadata format … despite having already metadata for that.
I’m not yet clear about the why - because using the quotes don’t break YAML rules, right? I suppose it’s to keep the syntax and implementation simpler? But at the cost of breaking the user expectation and ease of use? Especially for beginners that might not know workarounds.
Editors reformatting text surprisingly in the background also is tricky - especially for Obsidian which aims at Interoperability. I would err on the side of the user having had intend about their input (for Obsidian or external tools), and only modifying if’s invalid YAML.
Starting with v1.4.4, we will not strip the # if you use it.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.