When I create a link to an existing note by typing [[, I can enter a few letters to narrow the search, then arrow down and press Return on the one I want. The link is inserted, however it always duplicates the first two letters of the linked note’s name.
E.g. [[Inf
list shows Inferior Parietal Lobule
I arrow down, then press Return
InInferior Parietal Lobule is inserted.
Doesn’t matter how many letters I type to narrow the list, the first two of the note’s name are always duplicated.
I disabled PopClip and Keyboard Maestro. Any other suggestions?
Edit: this may only happen if there are spaces in the link-to note’s name. I.e. [[Schubotz2014 works as it should.
I’m seeing the same thing as JohnAtl. I thought it was me being ham-handed.
It might be the length of the container title. I’m not near a Mac right now but I’ll check later - with and w/o PopClip, and with short and longish [20+ chars w/spaces] container titles.
I tried shortening the name of the linked-to notes e.g.ventrolateral premotor cortex to PMv., but it didn’t help.
Tried using the mouse to select from the list, rather than arrowing down and pressing return, but that didn’t help either.
It’s not the length of the title. It seems to happen when there are multiple titles with the same characters to select from. That is, create three containers:
complex
complex titles
complex analysis
Type [[. Three choices appear. Down arrow to select complex. The link text becomes complex, and the link goes to the complex container. Down arrow to select complex titles and the link appears as cocomplex titles, and the link goes to complex. Ditto complex analysis.
In the same scenario as above, I found that selecting a title from the drop down with the mouse rather than down arrow SOMETIMES results in doubling, and sometimes not.
Maybe it IS me being ham-fisted. I hold my iPhone wrong, too. I’m left-handed. The world isn’t built for us.
I’m on the road this week. Wikilinks are finicky, depend intimately on poorly documented Apple APIs, and were originally conceived for CamelCase WikiNames without spaces.
We’ll sort this presently, but not (as we frequently do) overnight.
I’d agree the terminology is confusing. Using [[ as the trigger to start a Tinderbox text link_ (within the $Text area) compounds the issue as it is how in-wiki links are marked up in the source of MediaWiki (and perhaps other wiki variants). The latter is most likely to confuse those with the least knowledge.
Tinderbox wiki-links (N.B. link to an old version of aTbRef), were a feature lost in the move from v5 to v6 and the re-write of the app. I’ve linked to my notes on this old functionality as it may help explain how the two sorts of links were separate.
This all feels a bit like people assuming OPML is a fixed and stable standard. Well, it is, but hardly anyone uses the standard without adding undocumented custom elements to the format and its thus no wonder why OMPL doesn’t always work well as a data transfer mechanism. ‘Wiki’ means quite different things to different people, or so I’ve noted in recent study. Those different understandings seem linked to whether they can install/configure a wiki (not many people), create/edit wiki content (rather more) or simply read the wiki’s content as HTML pages (most!).
I don’t really care what they are called
I just need to be able to link to a note that is somewhere else in my map - one that can’t be reached by using the text link parking spot. If I need to CamelCase my notes, that’s certainly doable.
Essentially, I want it to work like roamresearch.com , i.e. without having to think about how to do it, use multiple mouse click-drags, etc. [[ seemed like it was what I needed.
Maybe I’m missing another way to do this?
Actually, none of us do, , but when trying to help someone asking a new question here, it is practical to start out responding to the terminology first used (“Wiki-link creation bug?”) even if it transpires that was mistaken.
Whilst the to-be-link-anchor’s text is selected, any note on the current map can be reached, you just scroll the view.
Regardless, it seems the issue here isn’t anything to do with the means of link creation but rather that something has gone awry with how the palettes involved (there are pop-ups atop pop-ups) aren’t behaving quite right. I believe the problem is now reported to the developer. If you need more urgent action, given the fix needs changes to the app rather than user behaviour, I suggest emailing tech support directly. Here, as a user-to-user forum you are talking to fellow users (some experienced with the app) rather than support, even if the developer does sometimes post here. Indeed, the first reply in the thread to you was from the developer!
Yes, that is the challenge. The notes I want to link with are within container notes.
I do appreciate everyone’s input and suggestions. It’s just frustrating that I’ve spent $450 on this software and it seems I hit a roadblock every time I revisit it.
Until the create link glitch is resolved—which seems the real issue here—be aware that if the issue is that ‘drilling down’ into a container in the view pane changes the text pane focus (and thus the text pane’s link park’s contents), if you drag from the text link park to the main link park, the ‘partial’ link is now parked in a location unaffected by current note focus.
Note: I’m not suggesting what follows is as quick/simple as auto-completing a [[-link (quick link) in $Text or in the text pane link well. But, until that issue is resolved, this should enable you to keep going.
We’ve selected ‘text’ in the $Text of ‘Note A’ and want to link to ‘Note B’ which is in a container (i.e. on a different map). If we select ‘A container’ to drill down, the latter takes focus and thus the parked link in the current text pane is lost. To avoid that we drag from the text pane link part to the main tab-bar link park. Like so:
