Show Inline Aliases in QuickSwitcher

Goal

Determine if there’s a method to write Aliases inline in Markdown file rather than only in YAML while still allowing them to search in QuickSwitcher.

Reason

My personal preference. The top of a note is premium economic space. The YAML front matter clutters my notes. The aliases metadata is the only field I haven’t yet figured how to move, while retaining searchability.

Related

  • Parallels Tags ability to write inline like #tag1, #tag2 and not just in YAML as tags:[tag1,tag2]; however, Tags only Search and not Quick Switch.
  • Forum to allow YAML metadata as key's in Search.

Build Up

(Skip to next section for TLDR.) Kindly forgive the verbosity, I generally patch together random things and am not sure if any of this follows community best practices. Outlining in case needed for the question’s x-y problem or in case helpful for others.

Previous Steps

  1. I’ve been beta testing Cross-site Navigation which pulls in all Tags. Therefore, I’ve majorly used Tags for project status/categorization and Metadata for individual note dynamic data.
  2. Breadcrumb’s Plugin allow my sub-folder-less notes to build into a bottom-up self-organizing hierarchy; associating notes to different parents retaining (multiple) relationship classifications.
    • Cause: Automating bottom-up MOC Emergence Levels.
    • Example: A note may be related to a system error and linked to the system object and system setting notes.) Breadcrumbs allows you to group your backlinks by multiple hierarchy associations (and also have linked non-hierarchy associations as well).
    • Pain point: I’ve been using file names to demonstrate the Zettelkasten’s Indexing. (Similar to Hackernoon, but no numbers rather than always text.)
    • Mitigation: File names can grow quite long, which is where Aliases are helpful to link within paragraphs so Preview doesn’t reflect file name lengths. I also frequently search between the TLDR names rather than full file name.
  3. From Forum, installed Hider Plugin to hide Front Matter in Preview.
    • Cause: I Zoom screen share Obsidian on internal/customer calls. (I write all WIP/confidential notes behind comments %% %%, so Preview mode is appropriate to share.)
    • Pain point: Screen share is size limited, so Front Matter takes up premium economic space. (Note: even zooming out and minimizing all side ribbons.)
    • Mitigation: Hiding allows us to get to the actual doc content faster, usually Excalidraw Plugin or Diagram Plugin architecture diagrams.
  4. Installed DataView Plugin to then use Dataview’s Inline Fields key:: value which allows me to move fields off YAML.
    • Example: site:: [Google](https://www.google.com)
      • Located at bottom of page with Footnotes.
      • Placed inside comments %% %% to keep from showing in Preview. Effectively lets you use metadata as dynamic note text / variables. (Also applies to PDF exports.)
      • Allows you to then use Dataview’s Inline DQL = this.site which in Preview will show as link to Google.

Next Step

Cause: If I have a page named “es index ilm”, which Preview shows as the following. This is sufficiently compact and gets us into the conversation / links very quick.

markdown
- ---
- aliases: Index Lifecycle Management, ILM
- ---
[doc](...)

site:: [Google](https://www.google.com)

> [doc](...) ([config](...)) doc quoted text
> ...
>  ===important part===
> ...

![[architecture.excalidraw]] 

[codeA](...), [codeB](...), [Consult](...), [[es index ilm architecture]], [diagnose Blog](...), [Github#bugs](...) [^1]

%%
parents:: [[es index]]
api: [[es api put ilm policy]], [[es api post ilm stop]], [[es api post ilm start]], [[es api post ilm policy retry]], [[es api post ilm policy remove]], [[es api post ilm move step]], [[es api get ilm status]], [[es api get ilm status]], [[es api get ilm policy]], [[es api get ilm explain]], [[es api delete ilm policy]]
%%
[^1]: asdfasdfadsf

image

Problem: However, I prefer off-calls to spend most of my time in Edit Mode. I may also toggle between Preview/Edit mode on internal calls (where commented out %% %% information is acceptable to share.)

Inherently, some of the link lengths are extended and make using Edit mode difficult and Preview preferred. But I and sharing users are usually more space limited and distracted by the YAML Front Matter. I also am I’m fairly direct with my aliases and would prefer to include them at the bottom of the page in the “misc” metadata section.

Mitigation: (You may need to close and re-open file for metadata to update (not just toggle between Edit-Preview).) You can edit YAML aliases in line like

markdown
---
aliases: asdf1
---

`= this.aliases`

`= this.site`

%%
aliases:: asdf2
site:: [Google](https://www.google.com)
%%

Therefore, we can remove the YAML Front Matter and still show our aliases.

markdown
`= this.aliases`

%%
aliases:: asdf3
%%

Problem

:interrobang: If you do this implementation without the top YAML Front Matter, the aliases are no longer searchable in Quick Switcher. (If you do with top and inline, the top are still searchable.)

I may have search foo limitations. I’ve majorly been googling and reviewing these ballpark Forum links.

Regarding the X-Y part of my question, I’ve generally gone back and forth about needing but not wanting YAML Front Matter, where I think my view summarizes with this Forum fairly well about wanting metadata links so needing at least the builtin + one custom (which is not ideal).

Does anyone know a better way to edit/update the Obsidian index’s note aliases field without interrupting search (specifically Quick Switcher)?

1 Like

Hi,
About all you said (and in a style much less verbose from my side), you can’t use aliases outside the yaml frontmatter.
Explaining…

  • If you use aliases: or tags: in frontmatter, Obsidian take that fields and “convert” them as implicit metadata (that’s why you can write in singular or plural: tag: or tags:; alias: or aliases:). Then, these inherit metadata appears in all related functions/panes: tags in tag pane; aliases in quick switcher; etc.
  • In Dataview, these implicit fields are “called” by file.tags or file.etags (for tags) and file.aliases for aliases.
  • When you try to use inline fields (a Dataview feature, not an Obsidian feature) you are creating custom fields (not implicit fields). If you write aliases:: or my_field:: or tags:: or warm:: is the same thing: custom fields without any relation with “implicit” metadata (well, if you use tags:: #tag1, #tag2 you get implicit tags, but as a page level metadata - as any tag you write anywhere in your content -, and you can write other field key as mymy:: #tag1, #tag2 or any field key at all).

In conclusion, it’s important to distinguish between obsidian and dataview features.
If you really want to use aliases you need to use the yaml frontmatter.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.