Alias from dataview?

[ryanwwest]

I found this plugin amidst searching for how to get rid of YAML frontmatter entirely since Obsidian treats it as a second-class citizen (e.g., no support for wikilinks) and since it looks a little ugly. This appears to allow this by no longer needing the aliases key, but I wonder if this plugin could support other ways of loading in aliases? For example, recognize a Dataview field aliases:: that acts the same way as YAML frontmatter does (including multiple aliases, but also supports the selective renaming that this plugin supports)?

I'm a little concerned about relying on the first heading always since I have hundreds of notes that often start with a generic templated heading like # #Summary, so I'd rather be able to switch this off and still explicitly define aliases out of YAML frontmatter. (though I know this is a bit contrary to the plugin name)

[basham]

That's an intriguing idea. I don't use Dataview, but it looks like it has a lot of good support.

To clarify: You would like this plugin to search for and update content matching the inline field annotation, such as [aliases:: 🥕 Build a raised garden bed]. By using "aliases" that will mean that it is picked up in Dataview's file.aliases implicit field.

I need to give that more thought. I would be hesitant to do any work that would create a tight coupling between this plugin and any other. I don't want one to become a peer dependency of the other. However, if this would mean just expanding on the source and update mechanism of the alias, then that is reasonable. With that, the markdown content is the connection point between the plugins, and there shouldn't be a hard dependency.

I'm I interpreting all this correctly? Thanks for the suggestion!

If moving beyond headings and YAML as the source of aliases, then, yes, a new plugin name may be appropriate. And it would likely need some amount of user configurations. This plugin currently does not have any.

[ryanwwest]

That's right. Dataview's inline field notation (with or without brackets) is what I am interested in. I was not aware of Dataview's implicit file.aliases field until now, but it makes sense that this would include this.

However, it doesn't have to be Dataview, per se. My only real reasons for using aliases are to make it easier to quick-link to the notes with the auto-suggester box and avoid accidentally making essentially duplicate notes (e.g. 'USA' and 'United States of America'), not anything Dataview-specific. I suggested Dataview since it is the most common standard outside of YAML front matter to store queryable data and is supported or even required by many plugins, and might make parsing multiple alias values simpler.

But to avoid dependencies, perhaps there could be a user-definable pattern (maybe regex?) that lets someone arbitrarily define aliases. For me, I would just have it search for the first line beginning with aliases:: , capture everything after the space, and separate multiple aliases with a , delimiter if it exists. Or alternatively, wrap each listed alias in quotes if we want to support commas in aliases. While my example chooses Dataview syntax and will also be recognized by Dataview, it doesn't actually rely on the plugin. Maybe someone else would prefer a different string (like # ... :) )

[basham]

A regex configuration is a good solution. It would give users the option to adapt it to whatever their needs. I could see the plugin come with some suggested regex patterns (to capture the first heading or the Dataview fields), but it could be tweaked beyond that.

My primary concern with this idea is that it opens up the user to make potentially destructive choices. Regex is tricky to get right, and since this plugin replaces content, the user could accidentally capture more than they intend. I wonder if a preview is warranted. As in, you enter your regex and some sample markdown. Then the plugin will show how it interprets the sample and what it would output. Have to ponder that more. I've spent a lot of time testing the plugin in a dummy vault before bringing it into my primary vault. I would just want others to feel comfortable trying something before they commit to it.

[basham]

FYI, if I would invest in making these changes, I likely wouldn't be able to start on it until October or November, due to other side projects and commitments.

[ryanwwest]

Either a sample tester, or a simpler option (like only being able to specify a string at the start of a line, nothing fancier) could be good. Although, what destructive choices could the user cause besides failing to recognize an alias?

And no worries, you have no obligation to code this. Although I presume others would find it valuable as well.

[basham]

Although, what destructive choices could the user cause besides failing to recognize an alias?

Yeah, you're right. I was projecting based on my earlier experience with testing the plugin, in which I could make some destructive choices. That wouldn't be the case for users of the plugin. But yes, merely miscapturing an alias would mean that there would not be a match found. And because only exact matches to that alias in the form of links are changed, it should always just work with whatever you did.