Is there any way to reference or link to other notes?

[fnune]

Support request

• Please tell us about your environment:

  • Jrnl version: (run jrnl -v) jrnl version v2.4.1

  • How you installed Jrnl pip install --user jrnl

  • Operating system [MacOS, Linux, Windows?]: Arch Linux 5.6.11-arch1-1

• What are you trying to do?

I'm trying to reference one not from another so that I can later follow links either in viewing mode or in a markdown export.

• What have you tried?

Reading the manual, searching the issues and the pull requests, nobody seems interested in this feature.

• Other information

I'm trying to implement a Zettelkasten using jrnl, since I like the interface. Being able to link to other notes or entries is a basic need to build a Zettelkasten.

[micahellison]

Thanks for posting this idea. Unfortunately, there's no built in functionality for this. Right now, there are two main barriers to implementing it in a markdown export:

• It seems like we'd need a unique identifier for each entry, which jrnl doesn't have. There is an old issue request for this (#519) and I've reopened it.
• Even with a unique identifier, each export format would have to be aware of these links and would have to parse it accordingly. We'd have to define what the links look like and make sure that they work in various formats.

In the viewing mode, it would be trickier, since viewing isn't interactive. I'm not sure that we'd want to go in that direction. But this sounds like a useful and feasible feature to implement for exporting eventually.

[eshrh]

Alright. I'm going to think this out here, it's probably going to get pretty messy:

So, three things need to be accomplished:

1. Provide a unique identifier for an entry, such that it is extremely unlikely that a user would type it in unintentionally.
2. Have that identifier be meaningful to both machines and humans.
3. Provide a mechanism to link entries as described by #949

For 1 and 2: A timestamp is pretty unique. Especially combined with the fact that a jrnl timestamp is surrounded by [] makes it extremely unlikely that a user would type it out by hand. Not changing this has several benefits, including less work, and less chances that things will go wrong that are built around this (all the exporters' functionalities would need to be changed).

The problem with this is that it becomes very annoying to link a specific post by hand. I imagine that a user who wants to link a post two days ago doesn't want to go back and check the exact second it was submitted at.

For 3: As @micahellison said, doing this in viewer mode sounds complicated. This is especially true because jrnl has several functions that show multiple entries at a time. I imagine that if there was only one entry it'd be trivial to match a regex and ask the user if they want to open a certain post denoted by the timestamp that was matched. When the user types for example jrnl -n 10 to read their posts surely they don't want to be asked twenty times whether they want to follow a link! Thus, I can think of another approach. Starting the journal in say --link <timestamp> opens one specific entry (perhaps adding a shortcut for the last entry), parses for a link, and asks them if they want to follow it. This sounds like a lot of work, and it sounds like it would get pretty tricky. I might try it later if someone else does not.

I don't see why markdown would be so hard. I think this should be the starting point. Markdown bookmarks are quite simple and repeated. After every title/subtitle, we just need to include a <a name="IDENTIFIER"></a> line and then we literally don't even need to change the standard markdown link which is [link text](#IDENTIFIER). Just straight up export that text. I think this is a good and very natural way to link generally. The only question is now how to answer question 2.

For now, as I said earlier, timestamp is unique enough. To solve the problem I described, I suggest that we allow for a special type of tag. Perhaps this could be @+tag that would always be used as a bookmark in place of the timestamp. This is the only reasonable solution I could think of. Things like incremental orders, hashes, and title-based approaches will not work because of the inherent changeability of jrnl.

What I envision is something like the following:

1. User writes an entry, and knows they want to reference it later. They include @+i_won_the_contest at the end of the post. This is treated BOTH as a normal tag and as a bookmark tag.
2. In the next entry, they write something like `for a more detailed explanation of the contest, see here
3. They export to markdown
4. Links work.

For now I think this problem should be limited to markdown because it's the only export that already supports links.

[eshrh]

@micahellison @wren what do you think about this?

I've done a couple of bug fixes now so I'm familiar enough with the codebase to attempt some new features.

[MinchinWeb]

I have a home-built system for referencing between entries that works for me, but may be too specific to my workflow to be generally helpful:

1. Export the journal to markdown as individual files. Files are saved with a consistent pattern: 2020-05-31_entry-name.md
2. I use the exported entries to generate a static website using Pelican. Pelican will link between entries, based on the source filename.
3. Use the two to create workable links: [Link title]({filename}2020-05-31_entry-name.md)

[micahellison]

I agree @eshrh that constraining this concern to markdown makes it a lot simpler.

The anchors sound like an elegant solution, and "YYYY-MM-DD_entry-name" should work in 99.9% of the situations and still be closer enough for the rare situation in which two entries have the same name on the same date. Adding a time could mitigate that issue, but there's something to be said about the conciseness of this slug.

Also, as I think this out, it occurs to me that in-document links are already possible with our current markdown format when used in particular markdown interpreters, such as GitHub and mkdocs, which automatically generate anchor tags from headings. For instance, in our CONTRIBUTING.MD, you can see the Table of Contents pointing to various headings. Dumping a jrnl export to one of these interpreters would have the same effect, since each entry title becomes a header, which is then turned into an anchor tag.

[guydebros]

@MinchinWeb that's a nice solution. For those who use Emacs, there's also deft mode (I don't know if such a thing exists for Vim). If jrnl can now do multiple-file stuff, you could set your jrnl directory as your deft directory. Deft plays nicely with those double-bracket [[link]] links, which you can add while creating your entry. You still have to get the filename of the entry to which you want to link, though.

[guydebros]

Hmm. Looks like someone has modified deft to better work with the zettelkasten system.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.