Searching for note [[Test]]
[[Te]]Testshift + | (pipe)[[Te|]]Pressing shift + | should autocomplete [[Test|]] in exactly the same fashion as # and ^ do. Seperate functionality is a UX issue.
Tab then pipe works, but this is unknown. Tab places the cursor within the wikilink, whereas enter places it outside. Why so?
It’s not shift+| it’s just | or (shift+\) if you use a US keyboard.
Renamed the FR.
Currently, pipe does not autocomplete (with the currently highlighted element in the suggestion list) otherwise it would be hard to write [[not yet existing note|alias]]. The autocomplete would change not yet existing note to suggested note name upon pressing |.
Yet # and ^ autocmplete the suggested note name upon press, however they do not require the note’s section—or block—to exist, and as such, we have an inconsistent UX. Pipe should autocomplete the suggested name, in the exact same fashion as hash and caret, or hash and caret should be updated to not autocomplete at all.
The use case for [[not yet existing note|alias]] is exactly the same as [[not yet existing note#this will be my first heading]]. There is no difference, except that pipe does not autocomplete, but hash does. So this is where my desire for this feature request exists.
My suggestion is that the hash and caret functions should mimic the pipe, or vice versa, given they’re apart of the same box. Default it to pipe mimicing hash and caret as is, and provide a setting to not autocomplete should a user wish to be able to pipe (or hash, caret) a non-existing note.
They autocomplete because if the note doesn’t exist, you would not try to link to a part of it.
You can make an alias to a non existing note
You can’t refer to a heading or block of a note that doesn’t exist.
“Would not” and “could not” are where we differ here.
Based on that logic, neither should the pipe (display name)… I truly cannot wrap my head around why anyone would want to write a display name for a note that doesn’t exist? Hence wishing it to autocomplete so maybe I can just abbreviate it in a different manner.
You can actually refer to a header or block of a note that doesn’t exist, it just won’t display or create the header on click, it creates the file, in the exact same manner as pipe does. So why the different UX?!
(Side note: would be amazing if all display names automatically became aliases, maybe a seperate FR).
Because it makes sense (as in people commonly do it) to be able to write a display name for a note that doesn’t exist yet.
It makes less sense to write a link to a heading in a note that doesn’t exist.
This is the rationale. I understand you don’t like it. Maybe someday we will change it maybe we won’t.
It’s less about not liking it, and more about not being able to wrap my head around it. For sure, I am stuck thinking about my own use-case here—hence not being able to fathom why someone would want to write a display name for a note that doesn’t exist.
In my head, the logic of less sense to link to a heading in a note that doesn’t exist yet, applies also to a display name.
Could you perhaps provide a real-world example so I may better understand the benefits of this current UX? Maybe I can improve my note-taking experience by understanding better the purpose of this design decision.
Users wants to write [[non existing note|alias]], it’s not easy to do if pressing | turns [[non existing note| into [[first suggestion|
We have made | act this way. because users complained specifically about the above case.
I guess, it’s dependant upon what suggestions are apparent also. For example, if what I write brings up no suggestions whatsoever, then it’s irrelevant. Makes sense why it’s like this then.
This is why I asked for a real world example. Something from your own experience, potentially. In my head, say I’m taking notes about the Nervous System in a lecture, and my lecturer mentions the “Peripheral Nervous System (PNS)”, so I write [[Peripheral Nervous System|PNS]], so that I can later come back to it, click it, and begin an atomic note on this. Is this the intended use-case? This is a hypothetical situation however—do you have a personal use-case you could share with me?
Maybe the display name becoming an automatic alias is a worthy FR… So that if I were to click on the above link and create Peripheral Nervous System, PNS automatically becomes an alias, allowing me to forego display names in the future and link directly to the alias? E.g., my next link I can immediately do [[PNS]] which autocompletes to the above. This could be an improved workflow, however I don’t know immediately what the drawbacks may be. What are your thought on this?
Thank you for your knowledge and the discussion, I am learning about alternate use-cases and am sure to be a better note-taker because of this.