Edit by admin: These inital notes are split from the ziplinks what are you doing with them as requested by Eastgate, to avoid thread drift. It is no reflection on the actual discussion therein.
I’ve been part of discussions on that, and I believe given the potentially large number of solutions in linking to specific text in other notes, that the edifice could crumble. Someone will try to link to “and” and get offered 1,500 notes as possibilities. You see the risk.
I think you may have misunderstood what I meant (or I wrote it badly). I do not want to target a specific run of text in the destination note. I just want to set a good amount of text in the target. So using the current syntax, it is the text after the ‘::’ delimiters that I’d like to be longer. Like so: [[some note|some text::much more than seven words for the destination note’s text]] For the link type, I thought maybe something like backslash, so [[name|source text::destination text\linktype]].
So unless I’ve misunderstood the worry you mention–which seems right to me–is not one my request elevates.
To me, this reads as a non-sequitur. The target has to be something, and that something (here: “a good amount of text in the target”) is the target anchor. If it is not the anchor, then what role is “a good amount of text in the target” fulfilling. That’s not to be snarky, but just asking the software to guess your intent is a hard call on the developer.
At present, the extent of target anchor text is to load the page and scroll the $text pane to show the anchor. Otherwise links just load the target note in the text pane.
Also, text anchors—source or target—can’t be accessed/set via action code. Ifn a way that’s good as it offers an opportunity for us to clarify the pictured link outcomes that are in our minds eye into something that the app can encode.
With the above in mind, why> I ask no implying you shouldn’t want this, but it’s functional intent. It reads like you want on or both of the following:
While Roadmap and Browse Links can show source text anchors (or the elided parts of them) and $text can colour/underline text links, target text anchors cannot be viewed outside the TBX XML.
So, what functionality do we want for target anchors?
It may be that my sentence is unclear, even that it has an indeterminate object, but it is not a non sequitur. There is not one thing that fails to follow from another.
I have no idea how you got the parsing of my sentence that appears in your note, but evidently what I have written is seriously unclear. I am sorry about that, please disregard it. Nothing I have written relates to target anchors.
Fortunately, Eastgate appears to have understood my request as I put it to them. Namely, the text that is added or appended to a note that is the destination of the ziplink presently is presently restricted to a modest length. Eastgate have indicated that this limit will be extended in a subsequent release. When they fix that, one half of the limitations I described in my OP will have been removed.
The sole outstanding additional functionality I’d like to see from ziplinks is the ability to specify a linktype. My reply to Paul suggests one syntax by which this might be done. I have not thought what to do in the event that the type specified does not exist. I guess one could silently create a new link type or use the default type or pop up a link type dialog for clarification. I think I favour the first.
Thanks, understood.
Apologies for the disconnect! I’m just trying to help and there is clear lots of guesswork around as the wider audience gets to try a feature very recently developed. As numerous current threads show assumptions are not always matching current reality in the range of what the ziplinks feature support.
There is a confluence of two activities, one which is an expansion of the other. Ziplinks extend the old ‘quicklinks’ (aka quick links). This essentially allowed typing a trigger , a string to auto-match/complete an existing note name and to link to it. To me, that’s the ‘quick’ part.
The richer extended features play to the keyboard centric user in terms of configuring other aspects of the link, such as the links anchor text, the location of the target note (including making new notes) and adding/appending $Text. In the latter case this is currently a small amount: my _guess max only sentence and a short one at that.
Overlooked in the finger-must-not-leave-keyboard perspective is that Tinderbox is a hypertextual tool. If you create a new note, e.g. via ziplink, move the cursor in the link and press ⌘+↩†
. that sends you to the new/linked note. Type the ‘long’ new text. Now, type ⌘+’ to go back to the last note (these commands are also on the (Note menu). ITSM, that’s easier than trying to figure if one’s type too much text into a ziplink, but until the text limit is raised it’s a do-able way of adding ‘long’ new $Text via a link.
† Edit. Sadly the short cut binds only to basic links and there seems no keyboard shortcut for a cursor ‘click’. So, for now, you need at least one non-keyboard action here.
Lastly, at present, ziplinks make untyped links, i.e. of type ‘*untitled’. Action code does have codes to link and unlink code, so one can remove an untyped link and make a new one, but it’s not very easy and those methods weren’t designed for link type triage. Testing now with linkTo() if you specify a link type that does not exist it does set that link type but doesn’t add it to the doc’s list of existing link types (i.e. the latter table isn’t updated - IRC that’s a known error.)
There is currently no mechanism to specify a_target_ link anchor. Nor, even if using other methods to set one, is there any means to see what target anchors exist in a note (Roadmap doesn’t list them nor Browse Links, not link highlighting in $Text). Currently, link target anchors are no more than an affordance for scrolling $Text within a target note with a lot of $Text (i.e >1 screen).
MWRA: Is there some easy way we could refactor this (interesting, useful) discussion of setting the text of the target note into its own thread? I’d like to return to the original topic: Ziplinks: what are you doing with them!
I’ll try. Discussion is all over the place today!
Thank you Mark for mentioning this option. I knew about Go Back, but had not used cmd-return for Navigate. However, this does not appear to operate as you describe or I am not managing to get it to do it. If I make a basic link (i.e. without using a Ziplink or without having an originating text anchor) then Navigate works as described in aTBref. If I make a non-basic link, by which I mean a link with an originating text anchor, then Navigate seems to do nothing irrespective of where I place the editing (i-beam) cursor in the text pane or whether I have the note selected in the map. That is to say, Navigate seems “blind” to non-basic (text) links.
I will be very grateful if what you describe can be done, because it would be very useful to me for precisely the reasons you describe.
Tries more baroque test, with edge cases.
OK, I was wrong. Cmd+↩ seems to be tied to the notes first basic link. ‘first’ as in terms of first my order of creation (time) no alphabetical sort.
Drat, it seems my earlier test unwittingly used a note where the current note had both a basic and ziplink to the same target. This is why testing is so time consuming… 
I’ve amended my aTbRef note on this.