but Logseq and its plugins use this format to store metadata that are hidden to the user by default, like:
collapsed:: true
id:: 1234-5677-9012
that are introduced respectively for collapsed and referenced blocks.
Logseq hides by default some of these properties and from config.edn the user can manually hide more properties.
I’m proposing to define a standard that could be adopted by other apps like Obsidian for example, where displaying Logseq metadata like id:: doesn’t make sense.
The standard is inspired by hidden files and folders in Unix: a dot (.) before the file name.
So Logseq could use dotted properties for its own metadata:
.collapsed:: true
.id:: 1234-5677-9012
And so could do plugins and other applications: dotted properties that are supposed to be hidden from the user and the usual properties that the user is supposed to see and edit.
Then there could be some way in Logseq UI to take a look at hidden properties for a block, to make the user aware of what’s happening under the hood, debug and eventually edit those properties.
I think this is an excellent idea. And I’d like to add one thing.
What I would add in the UI
I find it very annoying when there is no hint in the interface when hidden items are present. Even when there is a setting to make all properties visible. When problem solving it’s possible it just doesn’t occur to me that existing hidden items might be the cause. Therefore I would be in favour of a subtle hint in the interface that makes clear that there are hidden properties, but that isn’t in the way. For example:
Or alternatively:
The triple dots or triangle would indicate that there are hidden properties present. Clicking the dots would reveal them only while the properties for that block:
Notes about this:
A setting/keyboard shortcut to reveal all hidden properties would still be a must to prevent frantically clicking around when creating a query
Even though it introduces more complexity, I would be sympathetic towards the argument that system properties that are hidden need to look different from hidden properties created by the user. We cannot expect new users to know all system properties. Using .. or something like it would do.
Edit/reflection after writing this comment:
It comes across as odd not to use indented blocks for hidden properties. After all, blocks working perfectly well for hiding things from view. Allowing the user to add a child block under the page properties with additional hidden properties. I am not too confident though how this would work for blocks.
A pitfall that must be avoided is cluttering editing mode with too many elements, Like Tiddlywiki. I love Tiddlywiki and all its features, but simply cannot use it for writing. This is because of the cluttered editing mode.
Why I think @alex0 ’ proposal is already excellent
A specific type of usage of Logseq doesn’t require looking at hidden properties. Therefore, they should be hidden so that they don’t hinder thinking or productivity.
However, when the user does need to see hidden properties or know where they are, requiring the user to open notes with another text editor is breaks the experience. In Gnome I find being able to hit ctrl + h to hide and unhide dotfiles and hidden items quite often and I find it very conventient. Dotfiles are essential, but you don’t want them to be in the way.
Thank you, this is exactly what I meant with my last paragraph.
About the UI to show hidden properties I’m not sure what it should look like. Your proposal depends on a block having non-hidden properties.
You should keep in mind that blocks with hidden properties would be very common because of properties like collapse::, so maybe the option to show hidden properties for a block should be in that block context menu.
Good point. A setting like “Show hint of hidden properties when a block or page already has existing non-hidden properties” has too many conditions.
Context menu and commands, yes. I think it makes sense then to destinguish between hidden properties and system-required properties. To avoid needing to do this to a bunch of blocks when looking for something it’d probably be a good idea to have the following commands available:
“Toggle view all hidden properties”
“Toggle view system properties”
Whichspecific properties are system properties can be defined in config.edn.
I would like it to be much simpler by using child-blocks. You for instance have a properties block an multiple blocks beneath with all properties. The only change that needs to be made is to have all child-blocks of the first block behave like page-properties. No matter how deeply they are nested. And tags of course also the same.
