Ziplinks inside note titles

[rald]

Is there a reason, why one can not create ziplinks while editing the title of a note?
Or asking a different way: Why can I not create ziplinks whilst working in the outliner view?

Context:
When brainstorming, I prefer using the outline view, to be able to collapse and resort later. Using the notes text body feels too inflexible at that point, because what I write there can not be chopped into draggable pieces on the fly.
Ziplinks seem to be targeted at quick capturing, brainstorming, jotting down. So my assumption was, that naturally, they would be available when editing in the outline view – because I use the outline for that kind of process.

Would be happy to find out, if this has been considered at some point

Update, after the first feedback/discussion:
I want to create basic links that are outgoing from a note, by using [[ ]] syntax, whilst editing its title ($Name). If the [[note i want to link to]] is not existing, I want it to be created.
This is similar to the way ziplinks work in the textbody of notes ($Text), in terms of the workflow.

A first solution has been posted. It could be refined to allow putting the [[ ]] anywhere, not just onto the end of $Name, and also to possibly remove the brackets from $Name, after the link (or note and link) are created.

[mwra (Mark Anderson)]

@rald

Ziplinks seem to be targeted at quick capturing, brainstorming, jotting down.

I’m not sure I remember it that way. The original request was a faster way for a touch-typist [sic] to be able to enter text-links. The hare having been set running there was co-incidence with text-based entry of links. The latter is common from those stepping up from having used any of the many wiki+Markdown-based PKMs^† around at present. The latter, web style, can only make links by embedding them (web style) into an article. This creates the impression this is the only way links are made and thus increases interest in a type-only link entry method. I don’t recall discussion of speed, other than the touch-typist having to take their hands off the keyboard.

Thus as so often, a suggestion led to a feature that took a difference course. Currently, it seems most popular with those for whom making a link involves typing something in double brackets [[…]], as that is how they perceive linking happening (i.e. like in a wiki-based system). There’s no right/wrong in that, just differing degrees of breadth of knowledge of linking methods.

@rald

Ziplinks seem to be targeted at quick capturing, brainstorming, jotting down. So my assumption was

A lot of PKM have ended up with a wiki+Markdown mechanism, mainly I’m guessing by copying existing apps. This is not how Tinderbox works. The ‘zip’ linking method, aka ‘ziplinks’ in Tinderbox mimics this wiki-style. But note:

• the process creates a text link. There is no such thing in Tinderbox as a ‘ziplink’, only a text link that was made via typed input. Howsoever created, all text links are just text links. Text links all have text anchors, in the text ($Text) of a note. Tinderbox, unlike wiki-based PKM/processes allows linking to/from notes (basic links) or form/to text of notes (text links, including zip-created links.

In Outline view the labels you see are the title of the note ($Name) which is a separate piece of the note’s data. So is the idea that typing in a note title makes a basic link to another note, or that it adds a text link to the $Text?

Given that, the idea suggested is possible (anything is potentially possible) is not entirely practical. It’s a fair amount of engineering for a sub-set of users, mainly for the reason of making Tinderbox run against its gears so as to be like a wiki PKM. I see the convenience: the user doesn’t need to learn to use Tinderbox in any depth. What I don’t understand is why use Tinderbox and not use the power it has to offer. Using it like a wiki strikes me like buying a racing car and never leaving first gear. But I’m not assuming I’m ‘right’, I’m just missing the value of this.

@rald

Edit: I guess one could get the behaviour I desire, by making Tinderbox copy the note title into the notes body automatically?

Probably. Easier is to make the note, press Return (to exit title edit), then Opt+Tab to set focus to the new note’s $Text. so the fast entry tempo is:

• Return to make a new note
• type title
• Return to close edit
• Opt+Tab to set focus in current note’s $Text.
• Use zip method to add text link(s)
• Opt+Tab to set focus back in view pane^‡, current note selected
• Return to start next note
• etc.

†. This isn’t throwing shade at an unnamed app, or apps. Rather, I’m pointing up the fact that a lot of PKMs at the moment draw from the wiki model, which I find more meagre in terms of richness of linking. The wiki is a hypertext based on the Web concept. A hypertextual weakness of the Web design is links are embedded in text of a note; the richer hypertext notion of a linkbase (links stored separately from articles/page) is out of their reach. Tinderbox does use a link base allowing richer linking. Making it run like a wiki seems a retrograde step.

‡. The Opt+Tab cycle is actually View pane focus (any view type) → selected note $Text focus → current note’s Displayed Attributes table (if any!) → view pane focus. As new notes don’t, by default have Displayed Attributes, the above holds true. If Displayed Attributes are present, e.g. a parent container is setting a prototype that has Displayed Attributes then the three-way cycle apples.

[rald]

@mwra

So is the idea that typing in a note title makes a basic link to another note

Yes, exactly that was my idea.
The purpose I think this feature would serve me is:

• whilst typing, capturing that something is “a thing in itself, that deserves its own note” (create new note, if the [[note I link to]] does not exist yet)
• already linking to that new note, to capture in what context I created it
• doing both of the above, without having to leave the line I am typing in (it’s equally about flow and not being interrupted as much as it is about speed)

I see it as the complement to the ziplinks that are already present. Those do the exact same as creating a normal text links (as you pointed out): Create a $Text to note connection.
Similiarly, my “title-ziplinks” would do the exact same as a basic link: Create a note-to-note connection.
In both cases you simply eliminate the need to leave the line of text one is typing in and the distraction of doing anything but typing.

Hope that clarifies

Why do you think that this would make TBX run against its gears? Is there any reason against having hyperlinks (that function like the ones in the $Text) inside the $Name of a note (apart from it being work that maybe just very few users would appreciate)?

Edit: I guess the last question is of very fundamental character. It may be something where it would be interesting to hear some thoughts from Mark Bernstein – but I am hesitant to @ him on my first day on the Forum (although having played with TBX demo repeatedly in more than 4 years…)

[brookter (David Bertenshaw)]

Ok… This is a very quick and dirty approach to what I think is being asked for. It assumes that:

1. the zip links are written into the title within double square brackets, and the zip link always comes at the end of the note: Note name [[ziplink]]. There can only be one link per $Name as it stands.

2. That the main notes are in the container “Notes” and the zip links in “Ziplink notes”.

3. That you don’t care very much about error checking (at this stage…)

Create an agent with the following query:

inside("Notes") & $Name.contains("(.*) \[\[(.*)\]\]");

This looks for the [[]] pattern and splits the note’s name into two temporary variables ($1 for the ‘real’ name of the source note, $2 for the zip link name.)

Then give it the $OnAdd (Action) of:

create("/Ziplink notes",$2); createLink($Name,"/Ziplink notes/" + $2);

This creates a new note with the name of the ziplink, and creates a link between the original note and this new one.

Obviously, you could improve this in a lot of ways (e.g. use $1 to rename the source without the link and so on, add a third capture $3 to get ‘after link’ parts of the name and so on.) And it needs a lot of work on edge cases and error trapping…

But as it stands, it allows you to add a ziplink to the title and afterwards be able to use the normal links navigation methods.

And I’m not an expert, so this may not be a good idea at all …

[satikusala (Michael Becker)]

@rald

Is there any reason against having hyperlinks (that function like the ones in the $Text) inside the $Name of a note (apart from it working that maybe just very few users would appreciate)?

My immediate reaction is that you’d be mixing the structure of a hyperlink with the $Name of the note, which down the road, could have any number of complications in action code and export code operations. Also, if you wanted a hyperlink associated with a note, you could just use the $URL attribute or a user-generated $URL attribute. Also, when hearing 'hyperlink what comes to mind is linking to an external reference, note an internal note.

As for supporting the Ziplink operation in the $Name attribute, this might not be as far-fetched as one might think, given the recent implementation of # and @ parting in the $Name attribute. I could envision @eastgate implementing the Ziplink method similarly to these methods. Note, however, given the above statement RE hyperlinking, I don’t see it being practical to have the text in the note name clickable like it is in $Text when a text link is made, IMO $Name should remain pure text; rather, I would see this operation enabling a more traditional linkTo() operation form the note that has focus to the note that is being linked to.

[rald]

@satikusala

Also, when hearing 'hyperlink what comes to mind is linking to an external reference, note an internal note.

Sorry – I guess I should have written basic link instead of hyperlink. I am not particularly interested in linking to external references outside of TBX from the notes $Name.

@satikusala

I don’t see it being practical to have the text in the note name clickable like it is in $Text when a text link is made, IMO $Name should remain pure text; rather, I would see this operation enabling a more traditional linkTo() operation form the note that has focus to the note that is being linked to.

Yes, I can see that point. Making the [[ ]] from within $Name create and link notes, but not end up with a clickable blue link in the $Name would be a good compromise, if otherwise the implementation leads to lots of errors further down the line.
Actually, I would not even mind it in that case, if the [[ ]] get automatically removed again as I press Return to exit editing $Name. That way, you’d get the uninterrupted flow I would love to see and no clutter in the $Name.

[brookter (David Bertenshaw)]

@rald

Actually, I would not even mind it in that case, if the [] get automatically removed again as I press Return to exit editing $Name. That way, you’d get the uninterrupted flow I would love to see and no clutter in the $Name

That’s why the non-link part of the name is captured in the Query I gave - alll you’d need to do is add something like $Name = $1 to the action code at the end and it will strip the link out automatically once the linked note has been created. Or you coukd strip the brackets and leave the link name, depending on your requirements.

[satikusala (Michael Becker)]

Yes, this could be done with an action code, but I suspect that there will be some unintended consequences down the road.

[mwra (Mark Anderson)]

@rald

Yes, I can see that point. Making the [] from within $Name create and link notes, but not end up with a clickable blue link in the $Name would be a good compromise, if otherwise the implementation leads to lots of errors further down the line.

But there are no ‘clickable blue links’ in a title ($Name). Again, that is misunderstanding Tinderbox as being a Web/wiki. Without an intention of a better/worse judgement, Tinderbox is a hypertextual tool and Web/wiki functionality is a subset of that functionality; being different is not worse but it is genuinely not the same. Some Web behaviour, like embedding links in the article text/code is so exactly because of the limitations of being a sub-set of hypertext functionality. That doesn’t mean it doesn’t work, but it does mean thinking everything works like a wiki isn’t helpful to understanding Tinderbox.

If zip-method mark-up in a note title ($Name) were parsed for during $Name creation/edit and the result made into a Tinderbox basic link, that does make more sense. Whether that is ‘just’ a case of running the existing in-text zip-markup detection on leaving $Name edit state I’ve no idea. On limitation is that there couldn’t be support for the anchor text part of current zip method syntax as you can’t have links embedded in title nor do basic links have an anchor. But apart from that, I’d envisage the zip method potentially working in either context.

So I think someone with the need should restate this idea, now intent has clarified, as wanting to be able to create a basic type link from a note using zip-method syntax when editing $Name, the zip-mark-up being evaluated to a link and removed from the resulting $Name string in the process. Some care in scheduling is needed as, for instance, it might need to occur before $name is read for use in Display Expression, etc.

[rald]

@mwra

restate this idea, now intent has clarified, as wanting to be able to create a basic type link from a note using zip-method syntax when editing $Name, the zip-mark-up being evaluated to a link and removed from the resulting $Name string in the process.

Yes, I updated the original post accordingly.

@mwra

Whether that is ‘just’ a case of running the existing in-text zip-markup detection

Very nice to have would of course be the pop-up showing search results for [[what you already typed…, which one gets in the ziplink feature in $Text.
This however goes beyond, what I could do myself in TBX as a user, right?

@mwra

But there are no ‘clickable blue links’ in a title ($Name)

Of course there isn’t – but is there a reason to that? I’m fine with just taking “there just isn’t” as an answer, but I am curious. Looking at outliner tools, there is no clear distinction between a title and other text nested under that title. Thus one gets to use them in exactly the same way. I think that can be nice, as one doesn’t need to be aware of context and how to operate the machine in the current context so much. I’m just guessing that there is an actual reasoning/framework behind why TBX is choosing not to go that route. Again: just curious

[satikusala (Michael Becker)]

@rald

but is there a reason to that

Most other tools are designed to be a wiki; they’re names are built around the idea of linking. Yes, TBX has linked, but it is much more sophisticated. The other tools don’t have action or export codes, i.e., you can’t run transformations on the text. As noted above, I suspect there would be a tremendous of unnecessary edge cases and complexities (especially in UI) to deal with if the names themselves were links. This complexity is unnecessary once the affordance of Tinderbox are learned.

[rald]

Sorry, if I was being a pain – honestly. I just thought, that through the answer to that question, I might get more of a grasp of the nature of the distinction between a note and it’s title in TBX.
That’s why I was fishing for a reason in terms of why you’d never want it. I get that in terms of practicality it might create issues, but building a program as complex as TBX already demonstrates that someone here is not afraid of building stuff that might be a little tricky to build ;).
Hence, I thought there is a reason to not even ever want that feature. Only one to reveal the answer is @eastgate I guess.

[mwra (Mark Anderson)]

@rald

This however goes beyond, what I could do myself in TBX as a user, right?

Correct, but you could try @brookter’s idea above.

@rald

Looking at outliner tools, there is no clear distinction between…

I think that’s the issue - assuming all apps work/are designed the same way, and then working back from that. I don’t write that to be argumentative, but simply to point out how the line of argument doesn’t help understand the problem. Outlining pre-dates the Web. Engelbart’s NLS was doing in the mid-60s, thirty years before the Web and web-page clicky links.

But, I think this matters little because if Tinderbox’s developer can/is willing to parse note titles for wiki-style link code and make basic links from that, then I think your original idea is do-able and the problem is resolved.

HTH

[eastgate]

Is there a reason, why one can not create ziplinks while editing the title of a note?

I, too, assumed that you wanted links to be embedded in the title. That would pose some interesting problems, because the $Name of the note is not just a visual embellishment: it’s also the way that notes refer to each other. A note would have to specify the exactly link used by another note; that’s not a very attractive proposition.

Instead, you’re asking to create basic links while typing the title of a note.

That’s not a bad idea. But do keep in mind that you can easily create a note in outline view and then link it to other notes with its link widget.