I think here the issue is more about simple queries. I hope that once the query builder is implemented, its UI will made it clear how to query for tags, page-tags or both.
I don’t think blocks and pages will be revisited at this point…
Think about pages as special blocks that can’t have content but only children blocks and that have a title; and you can reference them with just their title and not an ID.
And then add that the graph view displays pages as nodes and references as relations.
It doesn’t seem like a simple matter of queries or output templates to me.
The approach of a mapping layer between the file system and the logical domain, supposes an architectural proposal with very interesting implications, beyond this specific case.
This whole thread doesn’t deal at all with the fact that pages have a title you can use to reference them and that pages are nodes in the graph view.
Mark my words: Tana’s “everything is a block” approach will be a shoot in their own foot.
Perhaps the fact that we are dealing with two graphs, the one of the DB and the one of the graph visualization, that creates some confusion.
Regarding the “everything is a whatever” approach, I take note of your words, but I also wonder why you should say it, because I don’t know Tana, but I understand that you also think it’s a bad idea for Logseq, but I still don’t know why.
Partly due to my limitations, partly due to the fact that in your answer, this time, you don’t provide any arguments to support your statement.
This exactly is the problem with pages and what probably many new users confuse. They are different from blocks:
When tags:: mypagetag is assigned to a page - let’s also name it root block here -, I expect this tag to be inherited to all childblocks. An ordinary child block has parent/child inheritance, so it gets all parent tag/page links automatically. But this is not the case with pages, as seen in issue 1.
I expect the filter results of page tags to be consistent with the ones of ordinary block tags. Again not the case, see issue 2. Compare the findings of issue 2 with the results, when going to #myparenttag or #mychildtag and click on its filter - there will be more tags to narrow to.
Pages can also have tags and properties.
And it would be awesome to reference blocks by their title name as well! Imagine you would be able to write Grandparent/Parent/My child block to quickly reference arbitrary nested blocks - what today is possible only with page namespace.
This whole thread doesn’t deal at all with the fact that pages have a title you can use to reference them and that pages are nodes in the graph view.
According to Tienson Qin, non-page blocks do have a title - it’s the one line you see as link, when using block references.
Question: Do I miss an argument here, which justifies that pages are kept so differently, that we get confusing problems in the user interface and need to partition the application logic in both pages and blocks (aka page-tags etc.)?
Yes, pages can be persisted. But domain driven design tells us, it’s not a good idea to let core logic or user interface (queries,filtes, etc.) depend on the type of storage. It seems to me, pages are just a storage mechanism.
Concerning graph:
Page = root block, so we might think of graph widget currently as displaying all root blocks and their connections. In future, this could be even enriched with more block details.
Mark my words: Tana’s “everything is a block” approach will be a shoot in their own foot.
Don’t have a Tana account, so I cannot fully understand why even their application settings are a node. The sentence “everything is a node/block” might be ambigious on its own, so let’s keep it simple: it’s about pages vs blocks, and keep everything intuitive, consistent for users and easy to maintain/expand for devs.
I hope that once the query builder is implemented, its UI will made it clear how to query for tags, page-tags or both.
Query builder is a cool idea! But we should get the fundamentals right first.
Block content is supposed to be updated often and that would break the reference by title that you want. Currently when you update a page title, all references to it are updated. Of course we can’t do this with block content since it’s updated so often. This is why blocks have IDs to reference them.
I can’t disagree more. Apple does this with iOS by hiding the file system and now we have children that have no idea of what a file is. It’s important to keep the user aware of the file system because it’s a very powerful way to manage data independently from the application. Logseq does already a great work by reflecting its data structure (pages, blocks etc) into Markdown files.
It’s about locking users into their product. Since Logseq edits Markdown files live on the user file system, Logseq is a tool before being a product and you can’t beat standards like files and Markdown syntax with a proprietary online service.
Your concerns are more about UI/UX than Logseq’s data structure and storing mechanism.
You can’t expect such fundamental chances in Logseq at this point… on the other hand, I discussed this query builder mockup two days ago with Logseq UX designer, since it could be the next focus once whiteboards and sync are ready:
Sorry, I have the feeling we are talking a bit past each other. Let’s concentrate on the presented two issues as main point.
These issues might be more UI/UX related, but existence of things like page-tags and page-properties is an indicator for me, that page currently plays an overall bigger role in the system, which is unneeded.
I celebrate logseq to be opensource, offline-first and using plain markdown files.
In fact this is the main reason why I prefer it over Tana.
Do you have a proposal that is not about redesign Logseq fundamentals, since they are not going to change now?
Well, we should let the community vote for all needed features (as usual). And core contributors, which are actually more knowledgeable with the code base, decide if a change is too “fundamental” and out of scope.
It’s not how it works
Wow, it seems that you are saying that there is an authority that dictates what is appropriate or what is not appropriate to discuss or share. I am waiting, so, to receive the appropriate guidelines that reward me with the privilege of being part of this community, as if the code license were just a piece of paper without any kind of political implications.
In any case, I think I’d better go lurker. When I better understand how this works, I’ll see what to do.
I’m saying that using a specific problem (page-tags that doesn’t play well with simple queries) to propose such a drastic change (unifying blocks and pages) is an unjustified logical leap and it’s a waste of your time.
If you want to contribute, you have to make an effort to understand more deeply before writing.
Hmm, I personally don’t see the need for unifying pages and blocks, nor any additional benefits.
There are several plugin APIs that make it easier for a plugin developer (at least in my point of view) because there are distinctions between pages and blocks.
I personally would not vote for unifying pages and blocks at this point.
Instead of going “lurker” reply to my objections like “you can’t use the title (first line) of a block to uniquely reference it”.
Since OP can’t reply to those objections they just remarked their right to discuss whatever they want, that is a childish way to end a discussion.
@alex0 I’d suggest you calm down a bit. Your writing style has become too passive aggressive to continue conversation at this point.
You could have made some effort to comment or hint me on the concrete listed issues, e.g. if there already a bug request. By the way: this feature request evolved from other discussions, see OP bottom.
Instead you decided to speak like a single authority for the community, that feature XY is “not going to change”. And all that (please correct me otherwise) without technical contribution background on the Logseq code base according to GitHub contributers’ insight - quite arrogant.
At the end of the day, this forum is a place for discussions, right? These have been my suggestions from a non-(yet)-contributor perspective. If af the end of the day, there is common agreement to handle the two listed issues as bug request for now, I am totally fine with it. If it moves a developer to think further about this approach similar to one of the Tana app ideas, that’s cool too.
Btw. I am curious: you still haven’t given any arguments with regard to
You are the one saying that you want to discuss but you are avoiding my objections, so instead of provoking, reply to them.
We were at this:
How do you uniquely reference blocks by their “title” (first line) if:
a/very/long/path starting from uniquely titled root blocks.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:
title:: property as a special one for blocks.title:: property and render them as their titles (like pages).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.
What do you think @venture-comp @Didac ?
[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.