Not consciously, really.
It is just that I never intended to give blocks a title ID. My idea has been: if pages and blocks are treated the same, we could reuse some nice block features as we now have with pages (e.g. when referencing blocks, we might type the root name, then let children autocomplete, reuse something like tree hierarchy for pages etc.). Take these as brain farts. Again: my main concern is still with the two issues in OP.
Sorry, if writing has not been explicit enough and causing misunderstanding.
There is no way around technical IDs for block (I guess they currently use UUIDs). Likelyhood for same block title name is quite high, so we cannot enforce constraints here. It just doesnât make sense.
We still can keep [[ ]] syntax for link/tag reference of a root block (which in the end is persisted as markdown file to file system) to provide reference by title and (()) for non-root blocks - everything same as before.
Alternatively, one could internally assign UUIDs to every block including current pages and use just one syntax like [[ ]] for everything, but that probably is more work.
What IMO is important: in the user interface pages and blocks should be treated the same. Remove extra page-tags and page-property and just use uniform operations for blocks, so we can query and filter all the same way. E.g. tags:: might return all block references, regardless at the top/root. Let the reference filter include top tags::, all following same block rules - I meant this by âunifyâ.
Someone with more technical background would need to judge, if this has consequences on an implementation layer (domain, persistence), I am still quite new to Logseq. I could imagine, a page is involved a bit deeper due to existence of aforementioned page-tags and page-property.
About the original issue, why donât just ask for simple queries to look at page-tags too when looking for a reference?
Simple queries are already an abstraction with user-friendly niceties and they already mix pages and blocks in their results.
So your suggestion would be an additional shrewdness that maybe the developers didnât think about.
About âunify pages and blocksâ I donât see how it is related to the issue above.
I suggest you to ask for something like âsmooth out differences between pages and blocksâ, that is something that could make sense.
But in this effort of smoothing out differences I donât see room for changing the references methods, i.e. namespace(s) of pages and IDs for blocks.
I think you should specify what you are trying to accomplish as end-user before proposing a change like âunify pages and blocksâ that for me it sounds like a technical solution without a motivation: exactly the opposite of what we should discuss in this forum i.e. starting from end-user needs to eventually arrive to technical proposals.
From a discussion on Discord about Tanaâs âeverything is a blockâ approach I think we have some ideas.
Issue: in Logseq pages are at the same time the âroot blocksâ and nodes in the graph, plus they have additional UIs like filtering references. When we want to create a node, we are forced to create a page and so a new âroot blockâ.
Solution:
Treat the title:: property as a special one for blocks.
When referencing a block (still using its ID) provide an option to display its title instead of its content so that it looks like a page reference.
Provide an option in the graph view (like âdisplay journal pagesâ that we have now) to also display blocks that have a title:: property and render them as their titles (like pages).
Provide the UI needed to fill the gap between pages and blocks, for example filter references of a certain block.
I know that you can already consider the first line of a block as its title but it could get in the way i.e. you may not want every single block to be treated like a node/page. So letâs make it optional by requiring an explicit title:: property.
Thanks @Joe_Smoe for testing Tana and provide useful insights.
[Edit] possible workflow to reference a block by its title:
Start a page reference by typing [[
Together with pages also blocks with titles are presented as options
Choose a block with title from the dropdown menu
The block is reference with some kind of syntax, for example:
- This is a reference to [title::](((1234-5678-90123)))
and rendered like a link to that block but replacing title:: with its actual value:
- This is a reference to Title of the Block.
At the moment you can already create a link to a block with custom text with [text](((ID))) but with the above syntax we wouldnât need to manually update âtextâ because it would be dynamically rendered by looking at title:: value.
That sounds really cool! Thanks for the effort @alex0 .
I see one potential issue for newcomers: block-references have always been started by (()) and page references [[]]. Now with the change [[]] is page or block, (()) block-only. It might be harder to remember, which syntax you actually need to use.
Two possibilities:
Stay with this approach and update documentation properly, like in keyboard shortcuts section of Logseq
Change to one main syntax [[]] and keep (()) for backwards-compatibility as block-only
Ad 2) This would be my preference. [[]] might list entries filtered by auto-complete and first prioritized by pages, then blocks with ::title, then ordinary blocks.
Should I still create bug reports for the two described issues in OP
#1: Simple queries should look at page-tags too when looking for a reference
#2: Fix inconsistencies with link reference filter between page and block
This is an issue in general, in my opinion Logseq needs an all-encompassing menu (maybe triggered by @ since most people are used to it from social networks) from where you can select everything: pages, blocks, commands, templates etc. Then the right syntax, that being [[]] or (()), appears.
To reference the value of the property of a block, why not:
Let the user find the block using @
Instead of pressing Enter to insert a reference to it, the UI indicates that entry has sub-options
The user use up-down arrows to navigate the dropdown menu (like now) and right-left arrows for sub-options
The user press â to see the properties of the selected block and browse them with up-down keys
The user press Enter to select the property and the following syntax appear:
[key::](((ID)))
that since itâs a standard Markdown link it would be rendered as key:: in other editors, but in Logseq, when the block is unfocused, it would be rendered as value, where âvalueâ is the value of the key of the specified block.
This could be useful in many scenarios, not only with title::, for example to render something like status:: Active or counter:: 48.
Same with pages but the syntax used would be:
[key::]([[Title]])
Iâd report them because maybe they could be easily fixed soon. About the #2 though, I think it could be obsolete in future since when I explained to the designer the idea to re-use the future query builder UI for those filters he welcomed the idea.
That all are very good ideas, I feel the need they are organized in an updated roadmap.
Also high on my wishlist: âObject typesâ (donât know if there is an official term) to express, some block/page is an instance of another reference and inherits all property declarations. Example: [[Person]] has properties age::, name::, [[Author]] has property books:: and extends [[Person]]. [[Don Joe]] is [[Author]], and has properties books:: XY, age: 45, name: Don Joe.
Then being able to render this quickly as table, canban card layout etc. If I remember correctly, these are calleld âSuper tagsâ in Tana.
At least there are enough ideas to spend the $4.1 million effortless . I feel encouraged to start learning ClojureâŚ
âProperties 2.0â (initial code in enhance-properties branch, it includes cardinality, type, range and description for properties, it could be preparatory inheriting properties you just asked)
Query builder
Make the UI/UX more consistent
Yeah itâs what Tana calls âsupertagsâ (bad name and bad idea to use hashtags to assign them, in my opinion).
This is a common concept in Object Oriented Programming, they are called âclassesâ, the ones that inherit are called âsubclasses ofâ and the inverse relation is âsuperclass ofâ.
Different ways to render query results is something the team is interested in too, as far as I can tell.
I principally agree on most of these arguments. Despite being a heavy and dedicated user for a long time now, Iâm still having issues discriminating between pages & blocks.
Removing this has the potential to simplify most of the use case scenarios. Not sure what we will lose though? ie: The graph only shows pagesâŚ
Thanks for the write-up @alex0.
Personally I would like to see some performance improvements for the graph first, (main reason why I currently use it rarely). It seems to cause high CPU idle load.
I think this is exactly not what you want. Now you add another type of âblockâ. If you add the the title:: properties you are in fact creating a third type.
pages (which do have an extracted title:: property (filename)
block with title (which do have the explicit title::property)
block without title (no title:: property at all)
What would be the gain in that except complexity? And yes I read about the ability to have blocks with title in the graph view. Not an extremely big advantage in my book with the possibility we currently already have to create a page from a block and automatically reference it. That is in fact what you want and what you already can do.
I thought the goal was to simplify and make everything work as much the same as can be ⌠lose the tags vs page-tags and properties vs page-properties and the inability to show pagename when searching for properties (at least in simple queries).
For me the title of a page is like a first block in that page and every page can have only 1 first block and 1 only. If that structure would be used in files you in fact have only blocks?
You also mention in this discussion that it is not doable to see the path to blocks that have the same name. But I would really love that. Look at Trilium Notes that have cloned notes that can be shown in multiple places/pages. References does that but I would like to see all pathâs for blocks with a certain name.
I am technically not very experienced but in most cases I think less options instead of more is the way to go. Rather a simple setup that can be used complex instead of a complex setup that can be use simple.
At the moment pages are âroot blocksâ, so they canât be organized in the structure blocks have thanks to indented lists.
In Logseq you have a network of pages, connected together by references made in their children blocks; in addition each page has a tree of children blocks, so another structure that is not linked to the former.
At the moment if I want to add a node to the network above, I need to create a page i.e. a Markdown file.
Iâm saying it would be useful to let us define new nodes of that network using blocks, so that they can be organized hierarchically in a single page using indented lists.
Letâs say I have books and authors but I donât want a page/Markdown file for each of them; instead I want all of them to be stored in Books.md but still retaining the feature of pages:
Books.md
- title:: Alice
id:: 1234
- title:: Title of a book
author:: ((1234))
as you can see I can organize nodes using an indented list.
The point is not only appearing in Graph View, but also use queries where I can look for âAliceâ as author (at the moment queries canât handle block references; Edit: you can use "((...))" in queries, but I would like if this was better supported, for example in future Query Builder).
This is basically the difference between Tanaâs ânodesâ and Logseqâs blocks & pages.
But if you change the title of a page, links to that page are broken. With a neutral/persistent ID You do not have to rewrite the anchor links referring to the page, or using a redirection system to keep track of every link text change.
As the original poster said, the filesystem persistence layer is leaking into the UX.
When descriptive titles and references are conflated, page titles seem more suited for standardized keywords and terms, not for title texts subject to change.
In which cases are wikilinks preferable? For editing content in plain text editors?
The point of Wikidata is also that you assign an ID to a concept, then you can describe the concept with labels in multiple languages. This reminded me of the alias feature in Logseq.