@tienson recently informed me that pages are soon going to get alphanumeric IDs just like blocks have. This will affect the ideas below, but let me put my current thinking out there so others closer to the code can help sort through these complicated issues.
We need to figure out the right way to talk about links and embedding. The current language is confusing. This will be important in figuring out how to describe current behavior, request new features, and fix bugs. Bear with me in the below text because I will be using terms that are currently being used in multiple ways, so when I say “link” I may mean something different than you have in your mind. But do correct any conceptual mistakes I make.
There are three types of connections between plaintext references in a block and target content outside of that block. A link connects a plaintext reference in one block to target content outside that block in some way. The link has two parts: a display (what shows in the rendered block) and a reference (the target of the link). The reference has both a unique ID (UUID) and what I’ll call "target content’, or just “content” for short, which is just whatever is in the page or block that is named by the UUID.
The link can currently be shown in three ways in a rendered block:
- what is displayed: text formatted as a link; reference content is shown only when the link is clicked and the user is taken to the content - this currently includes both Markdown links (page, block, and web) and page links
- what is displayed: reference content from another location, formatted to indicate that the content is being transcluded from the another location - this currently includes what we are currently calling “block references”, which already has a different meaning in the glossary—there, a block reference = a block UUID, not a UUID inside
(( ))—but this type of transclusion can’t currently be done for Logseq pages; I don’t know if it can be done for files or web pages but people will want it for images at least
- what is displayed: what I’ll call an “embed frame” that has a distinct background color; reference content is shown inside the embed frame - this is what we are calling an embed (block, page, or YouTube)
So there are three combinations of display/content, but we don’t have 3 distinct ways of talking about them, and we also currently have some inconsistencies:
- what we are calling page titles = page IDs, but what we are calling block titles = text beginning block content up until the first line break
- page links put page IDs in
( )without the page ref syntax of
[[ ]], block links put block IDs in
( )with the block ref syntax of
- block IDs inside
(( ))display block content, but pages inside
[[ ]]display the page title as text that links to the page
One idea that will require editing the current glossary and usage is to refer to page titles and block UUIDs as IDs, internal links to pages and blocks as “references”/refs, and Markdown links to Logseq pages, blocks, external web pages, and files as “links”. This would mean:
page IDs = page titles, block IDs = block UUID codes
page refs =
[[page ID]], block refs =
- page refs (change from current term “page links”) display styled page IDs, clicking navigates the user to the page target
- block refs (continue current use of term) display styled content of the block target
page links =
[link text](page ID), block links =
[link text](((block ID))), file links =
[link text]([[file://path/file.md]]), web links =
Obviously, adding alphanumeric page IDs would mean that page titles could not be page IDs, so we would have to rethink this. Comments welcome!