Change`[[]]` behavior to contain #tag behavior

[feva]

Hi everyone,

Here’s my thought process for this:

Some tag features:

• Tags are a shortcut to a search function, but this function is limited. I cannot use regex with them (for example tag:/^#string/), such as tags starting with something or ending with something. In this specific sense, a tag is inferior to a normal search.
• Tags are weak links between concepts, as there is not a specific page to tie the two concepts together. Sometimes you just want to relate two or more things without creating a page. We should keep that.
• Tags have a dedicated panel
• Tags look different in the document

Today I was wondering, should my dates be tags or notes to link to? The concept of daily notes calls for the later, but there are cases where I just want to tag something with a date as to not create a page. So right now I feel like I should be using both tags and notes for my dates, and tags only for when I don’t need the page.

So, a realization came to mind, a link [[]] can become a tag if Obsidian makes three changes:

1. A key combination, something like Alt + Click that when pressed instead of going to the page, it becomes a search function such as "[[string]]".
2. An option in the configuration to ask before creating a page with a link click, in case the page does not exist before. This has to be paired with a visual signal to differentiate which links have pages created and which ones don’t. There are many options here, color, adding a pound symbol at the start of the link like #[[string]], etc.
3. A way to save searches and/or to have links be listed in a separated panel. Similarly to the tag pane.

These three things would make the concept of links [[]] contain the concept of tags # with the added benefit that there would not be restrictions for multi-word tags (no needed to join with -,_, etc.)

Another plus is that there would not be an unnecessary worry if a concept should be a link or a tag, as the link would serve both.

The big con here is that there would be two competing features that overlap with the same use-cases, making things confusing for the users. So there should be a clear path of implementation paired with an option for users to massively reformat notes, in case this comes to fruition (similar to the markdown importer).

Thoughts?