Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

link to Note Block #108

Open
meichthys opened this issue May 9, 2024 · 2 comments
Open

link to Note Block #108

meichthys opened this issue May 9, 2024 · 2 comments
Labels
ported-issues Feature requests ported from zadam/trilium

Comments

@meichthys
Copy link
Contributor

zadam/trilium#1021

@meichthys
Copy link
Contributor Author

Relevant comment on CKEditor issue:
ckeditor/ckeditor5#1944 (comment)

This is still probably not worth investigating until CKEditor officially supports it, but i wanted to comment here for reference anyway.

@maphew
Copy link
Contributor

maphew commented Oct 30, 2024

Extracts from the original thread which I think are most relevant, and some thoughts on them:

A (perhaps not perfect, but good) idea could be to limit links to headers. A link would be created from existing headers, and then when the link is followed, the front-end could dynamically evaluate the current headers into a slug and see if any of them match the link provided. If none match, a pop-up notice could be shown to the user that the link is out of date and suggest they fix it (and then just leave the view at top of the note, as normally done).

I think this is similar to how a lot of web tools work for markdown headers. Anchors are automatically created from headers in a slug style (i.e. "This is a header" would become an anchor #this-is-a-header).

I think this is an excellent idea.

What about duplicate heading matches? Would we just link to the first one in the document?

Seems reasonable.

...maybe append the slug with -2, -3, etc.?

This could work, but I would refrain because it means something has to keep track of the "as written" vs "as linked" and I'm not sure the added work and maintenance would be worth it.

The problem with the auto-generated anchors is that they are extremely fragile - a simple rewording/typo will break the link. IMHO a much better solution is to explicitly create an anchor which will be stable, but that needs some CKEditor support.

Yes easily broken, but the page or note part of the link could still work, so a person would be in the vicinity of the broken link if not at actually at it. For example of a header of Objective was pluralised to Objectives a link ../foobaz-note#objective could still carry you to ../Foobaz-note. Not perfect, but still valuable. Meaning: I don't think waiting for CKEditor support is a necessity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ported-issues Feature requests ported from zadam/trilium
Projects
None yet
Development

No branches or pull requests

3 participants