Is there a way to edit a zip link that already exists (for example, to correct it)?
Not that Iāve found.
There is no such thing as a āzip linkā. The term refers to the input method. The result of the method is always an untyped text link. That isnāt to be pedantic but the means of creation is immaterial to how the link is subsequently edited. The ācodeā you typed in to use the ziplinks method disappears once the text link is made.
I believe that since the addition of the ziplinks link-creation method that if a link uses the target noteās name as the link anchor text, if the target noteās title ($Name) is changed the anchor text of all such inbound links have their anchor text updated.
Once a basic or text link is made you canāt manually change the target note (or note text), you need to delete and remake the link.
What aspect(s) of the text link are you trying to alter. Generally Browse Links is the first port of call (noting that the dialog only shows outbound links so you need to edit links from the source end).
An aside: Given the powerful export functions of TB (that I am excitedly tinkering with at the mo), it would be nice if the ziplink chrome (i.e. [[ ]]) didnāt disappear forever. Given all the programs that are meaningfully using these brackets (including friends of TB that have done so for some time (e.g. Devonthink and Scrivener), it could be very powerful to be able to retain that link indicator elsewhere.
But isnāt that the tail wagging the dog. The [[ metaphor may be common but mainly in simpler apps. I rarely use the target note name as the link anchor soāwhile well versed in wiki mark-upāIām unconvinced. The main benefactors are touch-typists and those who prefer to use Tinderbox without properly learning how it works. I see the convenience for those who come from [[ based apps but Iām unconvinced it has significant worth within the app.
A separate issue is the ability to support exporting to [[ based systems. That does have more value. One of Tinderboxās hidden upsides is overcoming the glaring inadequacies of import/export in many simple annotation apps.
Itās funny how itās always a case of āwhy canāt Tinderbox be like [some simpler less capable app]ā and not the other way around. I guess itās why I do more an more in Tinderbox, as lighter tools tend to lack flexibility. On a separate axis the interrelationship with āeverything-bucketsā (no disrespect!) like DEVONthink and reference managers (e.g. Bookends) is important and Tinderbox continues to progress in those areas.
The underlying point is these conveniences come with a cost. Using a a feature I once learned and forcing everything else to use that means extra mappings build into the app (which have to be maintained as the other āfeatureā matures outside Tinderbox) plus I donāt learn. Sure, I can hammer in screws using a chisel, but whereās the gain?
My 2Ā¢, based on long experience of Tinderbox. Iām sure others will differ.
Speaking for myself, I am often wishing other apps were more like TB, but maybe Iām reserving those complaints for other app forums. 
TBās power is unparalleled in a bunch of ways that matter to me. But itās such a learning curve at every turn and sometimes I need simpler apps for a better experience or view. No app is a silver bullet, and TB already plays really well with some great software. As more and more software comes to use [[ ]] Iād like to port those links over to play in many spaces, have many views.
An example: excited by the Ziplink feature, I created a robust QDA solution in TB, would not have been possible anywhere else and Iām glad I did. But I thought that hyperbolic view would really serve me and it (currently) is useless for my purposes. Maybe Iām missing something, but I couldnāt figure out anyway to see all this data Iād linked. It was a huge disappointment and a lot of work to figure out what to do.
I ended up exporting to Obsidian just to get an exploratory view. Iād rather it be TB, but thatās not where itās at right now. I would have saved a lot of time if those brackets had been retained.
1 Like
Amen! The hyperbolic view issue is known, my research docs look similar in this view. However, the view is still in early days and, ironically, was coming along nicely until everyone demanded focus on ziplinks as being more important (and that just for a different way of doing an available taskāmaking links!).
More generally, these sort of graph displays are not mature yet (IMO) as they have mainly developed focusing on niches like social/affinity network data with inherent (hidden) design assumptions that donāt map so well to other domains. Obsidianās view looks nice and is a basic force directed graph, but in tinkering with such displays, Iām unclear as to whether Iām seeing real connections (other than those I put there). Incidentally thatās not a canard at Obsidian but a reflection on force-directed diagrams.
Once/if hyperbolic view can filter (out) by link type or link distance (# of links _between source/dest.) I think it will be come much more powerful. It also means reflecting on use of long note titles (something Iāve long moved away from) as it makes for a busy UI. Challenging to develop, I donāt doubt. Your screen grab shows just how much data the view must deal with (and in limited space)āI have similar images.
You answer rather reinforces my sense that making [[ type mark-up easily ingested/exported makes sense but it aside for the speed-of-typed-input of the ziplinks method it doesnāt add much to Tinderbox itself, in terms of linking.
Always like it when I get an āAmen!ā from @mwra.
I have similar concerns as you do with the force-directed diagrams (and a bunch of the other algorithmically generated network displays). I donāt want to see the algorithm at work, and it feels thatās mostly what we get. Also, I want to be able to manipulate and add, something TB does so well.
Hopefully hyperbolic will get some sorting soon. Iāll jump right on it!
I agree with this, at least for the uses Iām imagining. However, having TB play well with others (especially when I want something it canāt/doesnāt want/will never do) makes TB more valuable to me.
Same here, as with the right export code (i.e. some assembly required you can export all sort of of formats. From brief recall: HTML, XML, MD, R/YAML (Bookdown), DOT, TSV, CSV, node/edge tables, JSON, RSS and others Iāve forgotten.
Funnily enough, given the comparative youth of many viz tools it can be incredibly hard to find out the data the viz tools want. I can make it in Tinderbox, if I only know what it was. Sadly the tools still tend to assume you want to compile your own and things like data formats are too obvious to be worth noting.
But hereās research in Tinderbox, exported as node/edge tablesā , imported into Gephi and exported to HTML, showing a conferences in-conference citations over some 30 years: ACM Hypertext in-conference Citations 1987-2020. The surprising thing in that experiment was the final website has loads of data about each item therein, >995 of which has travelled all the way through from the source TBX.
Hereās other research exported as TSV from Tinderbox, this time to Aeon Timeline v2 showing the Wikipedia bot ecosystem: https://www.shoantel.com/proj/bot-at/aeontimeline.html. Again experimental but hopefully it encourages a few more to experiment with more than just making long-form ātextā docs.
ā . Making note/link tables are a task that is perhaps too complex for many to try and might benefit from some action/export functions to extract some of the necessary data.
Mark - many thanks for the examples of exporting from Tinderbox and the good uses that feature can be put to. Iād be particularly interested in the export to Aeon Timeline 2 - but more generally, where can I learn more about writing export templates for e.g. Aeon? And (as an idea if it doesnāt exist yet): might a repository of example files be helpful in de-steepening Tinderboxās learning curve in that respect?
As my research file is open the the Aeon Timeline export templates were these below. IIRC, Aeon Timeline accepts CSV or TSV and in this case I used CSV. THe 'envelope template use by the container (or agent) is this (I named is āat-csvā):
Start Date, End Date, Title, Edit Count, User Page
^children("at-csv-item")^
The per-item template āat-csv-itemā uses this code:
^value($FirstApproved.format("l"))^,^value($LastEdit.format("l"))^,^value($Name)^,^value($EditCount)^,^value($URL+"|"+$BRFAURL+"|"+$CountURL+"|"+$SULURL)^
Save the exported file with a ā.csvā extension.
As you will see I used several user attributes at the Tinderbox end. Also before import, in Aeon Timeline 2 make any new Aeon Timeline properties (i.e. fields) needed for the import. Then use the import in Aeon Timeline as per the appās documentations.
The last data column the data with all the URLS is a kludge as Aeon Timeline doesnāt (IIRC) allow import of data like URLs, images, etc. So, I imported all the URLs as a ā|ā-concatenated string and then edited the Aeon Timeline fileās source XML to correctly insert the data as as multiple URLs for each item.
Once done, I then exported the web-page as you see above. Note Aeon Timeline ex[ported the data and JavaScript in obfuscated form so you need to export the data from Aeon Timeline rather than just swap out the data file in the exported HTML/JS pages.
Note. Itās not clear if the Aeon Timeline v2 web export will change or be retained in future versions so if upgrading when v3 arrives donāt reflexively delete v2 as you might still needed it for making web timelines.
Many thanks - I will try that with great interest! And I am astonished how few lines of code that requires. Great!
Tinderbox export is very flexible! For tabular export like this you simply need a container (note or agent) whose template sets the header row and than all child items must contain all the per row info. even then the rows can use (via offset references) values form other notes (e.g. to calculate prices, times, intervals, etc.).
@satikusalaās demos are also showing some quite powerful variations on this.
I should have been more specific. I donāt actually care about the links in this context, but with the mechanism that allows them to be specified. I was merely wondering if there were a way to make a correction (which apparently there is not). Iām finding that with I cannot use the tab-key replacement if I want to specify an alternate name to be displayed (via ā|some nameā). If I press tab to complete the name ā or the last segment in a path ā they zip link is completed before I have the chance to enter the alternate name. For example, given the path /Config/Documentation/TbxWorkingDirectory, when creating a zip link and typing [[/Config/DocTABKEY and followed by TbxWorkTABKEY, the zip link automatically completes before I have a chance to enter |SomeOtherName]], resulting in a name inserted into $Text that I do not want (TbxWorkingDirectory instead of SomeOtherName). Hence my desire to edit the zip link name.
@BeckTench āAn asideā¦ā ā I agree!
Actually, itās not some other app as you assume; itās to regularize the text so as to make the link easier to recognize for post export processing.
Tinderbox has a lot of accidental complexity [1,2] ā which is not uncommon among applications that offer wide ranging flexibility (this generally includes all programming and so-called āscriptingā languages). (As a programming languages guy (I taught basic and advanced compilers and language design for years as a academic) all scripting languages are programming languages; the difference is largely in their scope of use ā but I digress). The method for manually creating links is part of that accidental complexity, and the zip link mechanism reduces it. In terms of bang for the buck, shifting focus from hyperbolic view to improving zip links makes sense. Not everybody will immediately benefit from hyperbolic links whereas everybody that has to create links will benefit immediately with improvements in zip links. My two cents.
1 Like
On the original question: āCan you edit a Ziplinkā, (and following on from Markās point about simply renaming the target note), it may be worth pointing out that thereās a simple shortcut sequence to facilitate this.
- In the source note, clink on the link[^1]. Youāll be taken to the target note.
- Cmd-shift-enter to rename the target note. It doesnāt matter if youāre in the Text Pane or not.
-
Cmd-
'(single quote) to Note > Go Back to the original, where the text of the Ziplink has changed to reflect the target noteās new name.
This works with any text link (i.e. with ones made manually or with Foot/Endnotes). Not quite as simple as right-click > Edit link, but itās only one extra stage.
Obviously, if you want to do more than just correct the spelling of the target note name, it wonāt work, but the shortcuts may be useful for someoneā¦
[^1]: āClink on the linkā was originally a typo, but it has a certain ring to it. From now on I shall use the verb āto clinkā: āI just clinked and was taken to this websiteā¦ā
1 Like
Can you expand? I hope youāre not suggesting $Text be littered with [[ characters. If it must be, please let it be a non-default option for $Text (and/or for export).
If people need more post-creation editing of links, Iād much rather see this done via browse links or a new pop-u/dialog than polluting the $Text with mark-up not all users need. I emphasise the latter (in my community hat) as we all sit a bit close to our own immediate workflow leading to suggestions that donāt help other users. this is a toolbox that different users employ in different ways. Just because other (recent) apps use inline mediawiki-derived markup isnāt a strong argument for forcing all Tinderbox users to endure it.
For me, totally the opposite.
IMO, totally the opposite. Iāve happily linked in Tinderbox for >14 years without ziplinks and donāt use them now (too fiddly). However, Iāve been waiting forāand held back by the absence ofāhyperbolic view for the same length of time. You can make links by other means today; you canāt do the analysis a (more complete) hyperbolic can offer. Thus Iād argue it is more needed. I repeat the point different users have different needs. Though I donāt use ziplinks personally Iām happy to test, document and explain them.
BTW, I have a request for supporting one part use case on the Backstage. Rather than manually typing in an anchor for the piped name of a ziplink action anchor Iād like to reference an attribute. That way I can change the link name by adjusting the attribute.
Anyway, there is always brute force, just delete the link and re-create it.