Support links to non existent notes

[skbolton]

A portion of one of my notebooks is reserved as a dev notebook where I store snippets and things I want to remember. What I'll often do is link to a note like [[sql]]. I usually don't create these "topic" notes but instead use them as something to query on. Or in Obsidian they still show up in the graph views even though they don't exist.

I tried to take my existing notebook and make it work with zk but one issue has occurred. When I do something like zk list --link-to=sql I get errors because the sql path doesn't exist. At first I was hoping it could still find the notes that link to that non existent note. I can always go through and create these "topic" notes but I think then I just have notes that litter my search results when I am doing --match queries or other non relational lookups.

I can always change my workflows or listen to feedback on different ways of doing things, interested in your thoughts on this.

[mickael-menu]

Yes that's definitely a use case I'd like to support with zk.

We could fairly easily match the path parameter to an existing link href but I think this deserves a more systematic approach to be usable with other (and future) zk features. Maybe introducing a kind of "virtual note" visible in the index but not on the file system? Let me know if you have some ideas and where you think virtual notes should appear.

I don't want to rush this feature to make sure it's well thought out, so in the meantime I can think of two ways to address your issue:

• Using topic #tags instead of wiki-links and filter with zk list --tag sql (that's what I'm using right now)
• I could implement --grep quickly to filter notes with zk list --grep [[sql]], until the real support is implemented
  • Not yet sure about the naming of --grep, any feedback is welcome

[mickael-menu]

@skbolton I added a new option --exact-match instead of --grep. You can use it with --match to search for terms including special characters. In your case:

$ zk list --exact-match --match "[[sql]]"
$ zk list -em "[[sql]]"

And with this zk alias you can make it simpler to use:

[alias]
list-wl = 'zk list --exact-match --match "[[$*]]"'

$ zk list-wl sql
$ zk list-wl Page with spaces

Pre-built binaries:

• zk-v0.3.0-8-g083c0da-linux-amd64.tar.gz
• zk-v0.3.0-8-g083c0da-linux-arm64.tar.gz
• zk-v0.3.0-8-g083c0da-linux-i386.tar.gz
• zk-v0.3.0-8-g083c0da-macos-x86_64.zip

[skbolton]

Cool that is perfect. I meant to come back to this thread and say that a --grep option would be perfect to do the search as you showed, but that works equally as well.

[skbolton]

Do you need to specify --exact-match and --match or can the search term be passed to --exact-match?

[mickael-menu]

You need to pass both flags, --exact-match is just a boolean switch. Let me know if you have an idea to make this less ambiguous.

You can combine them nicely with the short names: zk list -em [[sql]]

[skbolton]

ah okay I was confused that -em was the short switches for --exact-match and --match. I thought it was just for --exact-match. I wonder if in order to avoid that ambiguity the long form of the switch being --exact might be more clear? Seeing -em made me think that --exact-match could take the search term.

[mickael-menu]

Ha yes, I can see how that can be ambiguous with -em. At the same time in the --help output it should be clear so I'm not sure it will be a problem in practice (until I suggest to use -em 😄) . These flags are shared by several commands so I prefer to keep it explicit, as --exact could apply to several things.

[bezmi]

I have been playing around with generating a nice graph view from the --graph output. It would be nice to have the "virtual" or "ghost" notes as you've described be a part of the graph output. I use virtual notes to mark notes that obviously need to be written (eventually) whereas tags are used as a convenient way to connect abstract ideas like "music", "art", "movies", "fluid simulation", etc.

My current hacky approach:

1. Use the emanote path format instead of the standard wiki one: link-format = "[{{filename}}]"
2. create the ./virtual directory and add a new empty note there: ./virtual/doesnt-exist.md
3. link to this note as needed via [[doesnt-exist]].
4. If I wish to turn this into a "real" note, I just move it to any non-virtual directory and rebuild the index. The links are preserved as they don't depend on the path.
5. for the purposes of graphing, I just check to see if the "path" entry contains the virtual directory and plot it as so.

This method works okay for my use-case. It is important for me that there is a clear distinction in convenience between simple tags and the virtual notes. I like that creating a virtual note is an explicit action, as it is like signing a contract with myself to revisit this area in future.

I think this system could be made a lot less tedious with the following implementation:

a virtual.yaml or json file in the .zk directory, which keeps track of virtual notes. These could be created via the lsp in the editor, or from the command-line. Then when we want to turn this into a real note, we use another command to create the file. This would rely on some refactoring capability to re-write links so it works with all link formats, not just the filename type ones that I'm using.

[skbolton]

I have started to play around with logseq and this is one of their features that I am really enjoying. I would love to see how this would feel in zk.

In logseq you can link to any page and it will let you navigate to it. You can usually tell that it doesn't exist because there won't be any content for the page itself. But logseq will generate a backlinks section of references that point to it and transclude those blocks into view.

I have contemplated making an extension for zk-nvim that would open a sidebar when you go to a note in a notebook. This sidebar would show links and references to the current note. If zk allowed you to create "ghost" notes and even run link-to queries about references pointing to the ghost note then the sidebar could still work. This sidebar could even possibly render out some of the content notes that are linking to the current note.