In short no. The ziplinks method (documented here, which has more info than app Help) is already fairly loaded and offers:
- making a text link to linking to an existing note by using the target note name
- making a new note by citing a name (or path) that does not currently exist
- optionally adding anchor text that is not the $Name of the target note
- optionally adding some text (to the end of) the target note’s $Text - for both existing or ziplink generated notes
- optionally make a backlink (from the target) by inserting a text link [sic] into the end of target note’s $Text (after any ziplinki-added text)
In the syntax
[[ ]] enclose the ziplink input. Within those brackets adding
< > enclosing (all input) denotes a desired backlink. So the syntax looks a bit like this, in aggregate where single square brackets enclose optional content (ignore the forum code trying to use syntax colouring ).
[[ [<] target path-or-name[|alt anchor text][::target note text][>] ]]
The two optional textual inputs (alt-text, target text) don’t have to both be specified if only one is used - just omit the unused one (and it’s delimiter).
If using ziplinks i’d avoid using a pipe (
|) or double-colon (
::) characters sequence in your note names or you may end up with some odd linkages. I probably now need to add these to those already described in my article on Problematic Characters for Action code in $Name and $Path. IOW, these characters aren’t illegal but you won’t get a warning if using them in action code which may [sic] mis-parse your intent.
Meanwhile, there is no action code method to change a link’s link type (though I recall myself and others making feature request for such, i.e. it should already be a known feature request).
Current (action code) functionality is to delete the link of the wrong type and make a new link of a different link type. But that’s clunky, IME prone to user error tripping on edge cases (certain characters in titles qv above) and only work with basic links as the actions have no way to select the source anchor text (which may not be unique within text).
Up until v5 there was the Paths view which got dropped in the v6 new code base as there was little evidence of its use (I think that was a fair call). So, the app at present lacks a method for link type triage at scale and other than by working in the modal [sic] note Browse Links. hat isn’t to carp though; it’s easy to flag an issue, but the fix is not necessarily obvious. I do think this is an area where the fledgling hyperbolic view could shine (with added functionality).