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.
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: https://www.shoantel.com/proj/acm-ht/2020/index.html. 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:
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.
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.
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.
'(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…’
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.