Skip to content

Resolve links relative to notebook dir#646

Open
WhyNotHugo wants to merge 1 commit into
zk-org:devfrom
WhyNotHugo:relative-links
Open

Resolve links relative to notebook dir#646
WhyNotHugo wants to merge 1 commit into
zk-org:devfrom
WhyNotHugo:relative-links

Conversation

@WhyNotHugo

Copy link
Copy Markdown
Contributor

Reproduces the bug where running the following outside the notebook causes the path to be resolved against the current working directory instead of the notebook directory:

zk list --notebook-dir=/path/to/notebook --linked-by inbox/note.md

When running commands like such as the following:

    zk list --notebook-dir=/path/to/notebook --linked-by inbox/note.md

The path is resolved relative to the current working directory.

If the current working directory is not the notebook directory of a
child of it, resolve the link relative to the notebook root.
@WhyNotHugo WhyNotHugo requested a review from tjex March 17, 2026 17:04
@WhyNotHugo WhyNotHugo changed the title Test that links resolve relative to notebook dir Resolve links relative to notebook dir Mar 17, 2026
@tjex

tjex commented Mar 28, 2026

Copy link
Copy Markdown
Member

Sorry, had a lot to catch up on here and overlooked that you requested a review! Will look tomorrow. Thanks, as always for the efforts here 🙏

@tjex

tjex commented Mar 29, 2026

Copy link
Copy Markdown
Member

@WhyNotHugo I'm getting a relative path to the cwd with a build from dev and your pr.

Strangely though, the build from dev returns all notes in my notebook, while your pr returns just the links... So something else is at play there.

But on the note of relative paths to cwd instead of notebook dir. Is this in fact a bug? I myself would expect that the paths should be returned relative to the cwd if I was executing the command outside the notebook. Arguably its a bit redundant as there is the --format {{path}} option.

@WhyNotHugo

Copy link
Copy Markdown
Contributor Author

I think paths should be relative to cwd only if they point to a path inside the notebook. Otherwise, they should be relative to the notebook root.

A relative path that points outside the notebook makes no sense, but it's very convenient to use relative-to-notebook-root from any location.

@tjex

tjex commented Mar 31, 2026

Copy link
Copy Markdown
Member

But by definition, paths will always point to a path inside a notebook as zk is only ever indexing notes inside a notebook?... I don't understand how any command would return paths outside of a notebook.

Are you perhaps meaning that paths should only be relative to cwd, if the user is executing the command inside a notebook. While if they execute a command outside the notebook, then the paths should be relative to the notebook root?

@WhyNotHugo

WhyNotHugo commented Mar 31, 2026 via email

Copy link
Copy Markdown
Contributor Author

@WhyNotHugo

WhyNotHugo commented Mar 31, 2026 via email

Copy link
Copy Markdown
Contributor Author

@tjex

tjex commented Jun 7, 2026

Copy link
Copy Markdown
Member

@WhyNotHugo Coming back to this again hit some other problem?

Tried both with HEAD and this PR.

Seem's like I can't point to a note that isn't at the root of the notebook.

~/wikis/burn/notebook
$ -> ls foo
x-hh8v.md

~/wikis/burn/notebook
$ -> zk list --linked-by=foo/x-hh8v.md 
zk: error: could not find notes at: foo/x-hh8v.md

~/wikis/burn/notebook
$ -> zk list --notebook-dir=/home/tjex/wikis/burn/notebook --linked-by ./foo/x-hh8v.md
zk: error: could not find notes at: foo/x-hh8v.md

~
$ -> zk list --notebook-dir=/home/tjex/wikis/burn/notebook --linked-by ./foo/x-hh8v.md
zk: error: could not find notes at: foo/x-hh8v.md

Here pointing to a file at the root of the notebook.

~
$ -> zk list --notebook-dir=/home/tjex/wikis/burn/notebook --linked-by ./2lp4.md
Chicken ... 7 months ago
foo ... 11 months ago
test title ... 3 weeks ago

~/wikis/burn/notebook
$ -> zk list --linked-by ./2lp4.md 
Chicken ... 7 months ago
foo ... 11 months ago
test title ... 3 weeks ago

I remember that there was some work being done on the hrefs logic (that was a suboptimal, because the function just returned the first instance of a filename match, even if that file existed in a different directory, mentioned here #684 (comment)). Not sure if something got merged related to this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants