You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current function in Logseq 0.10.9: Logseq 0.10.9 does display the hierarchy information in both the block edit view and the block rendered view, but as part of the page title.
Current function in Logseq DB: The documentation for namespaces in Logseq DB states that links inserted to a node that is in a hierarchy will no longer display the hierarchy, only the name of the specific child referenced. This is the case in both the block edit view and the block rendered view.
Workaround: I was informed that I can hover on the link to display the node's hierarchy.
Proposed change: My feedback here is to adjust the display so that the in-line link to a node will display its hierarchy in both block edit view and block rendered view. Including the hierarchy data in-line will serve as an immediate way to disambiguate between otherwise identical node titles. It is important that it display the hierarchy in both the block edit view and the block rendered view because in rendered view I need to know what the complete context of the link is while reading and in editing view I need to know what the complete context is while I'm writing. Perhaps this indicates that there should be syntax associated with the page chains created in hierarchies.
Use case: As an example of its usefulness, I have created a page [[John Smith/Local house painter]] and [[John Smith/Architect]] to disambiguate between the two individuals sharing the same name. If I am writing something like "Today in class I learned about [[John Smith/Architect]]" then the in-line output in the current version of Logseq DB will be "Today in class I learned about [[Architect]]" which is not immediately understandable when reading the sentence. It would be helpful if it instead displayed something like "Today in class I learned about John Smith>[[Architect]]" in the rendered view. I would also like to see this in the edit view, maybe something like Today in class I learned about [[John Smith]]>[[Architect]] or Today in class I learned about [[John Smith/Architect]] could work as the syntax shown in the edit view.
Reproduce the Bug
In a block create a node [[Physics Work/Ch. 1]]
Expected Behavior
The inserted node should give an indication of the page hierarchy on sight both in the block rendered view and the block edit view. Instead it inserts a link to [[Ch. 1]] both in the block rendered view and block edit view which does not give any immediate information about the hierarchy position of the link.
Screenshots
No response
Browser, Desktop or Mobile Platform Information
OS: NixOS Unstable
Browser: Version 130.0.6723.69 (Official Build, ungoogled-chromium) (64-bit)
Logseq: 0.10.10 b250e26 at test.logseq.com
Additional Context
In the process of playing with the new functionality I stumbled across #165. The behavior described in this present issue is visible in the video recording included with #165.
Are you willing to submit a PR? If you know how to fix the bug.
I'm willing to submit a PR (Thank you!)
The text was updated successfully, but these errors were encountered:
Search first
What Happened?
Per @logseq-cldwalker's suggestion, I'm filing this issue to follow up on the feedback given in #7 and explored in the feedback thread on Discord.
Current function in Logseq 0.10.9: Logseq 0.10.9 does display the hierarchy information in both the block edit view and the block rendered view, but as part of the page title.
Current function in Logseq DB: The documentation for namespaces in Logseq DB states that links inserted to a node that is in a hierarchy will no longer display the hierarchy, only the name of the specific child referenced. This is the case in both the block edit view and the block rendered view.
Workaround: I was informed that I can hover on the link to display the node's hierarchy.
Proposed change: My feedback here is to adjust the display so that the in-line link to a node will display its hierarchy in both block edit view and block rendered view. Including the hierarchy data in-line will serve as an immediate way to disambiguate between otherwise identical node titles. It is important that it display the hierarchy in both the block edit view and the block rendered view because in rendered view I need to know what the complete context of the link is while reading and in editing view I need to know what the complete context is while I'm writing. Perhaps this indicates that there should be syntax associated with the page chains created in hierarchies.
Use case: As an example of its usefulness, I have created a page [[John Smith/Local house painter]] and [[John Smith/Architect]] to disambiguate between the two individuals sharing the same name. If I am writing something like "Today in class I learned about [[John Smith/Architect]]" then the in-line output in the current version of Logseq DB will be "Today in class I learned about [[Architect]]" which is not immediately understandable when reading the sentence. It would be helpful if it instead displayed something like "Today in class I learned about John Smith>[[Architect]]" in the rendered view. I would also like to see this in the edit view, maybe something like
Today in class I learned about [[John Smith]]>[[Architect]]
orToday in class I learned about [[John Smith/Architect]]
could work as the syntax shown in the edit view.Reproduce the Bug
Expected Behavior
The inserted node should give an indication of the page hierarchy on sight both in the block rendered view and the block edit view. Instead it inserts a link to [[Ch. 1]] both in the block rendered view and block edit view which does not give any immediate information about the hierarchy position of the link.
Screenshots
No response
Browser, Desktop or Mobile Platform Information
OS: NixOS Unstable
Browser: Version 130.0.6723.69 (Official Build, ungoogled-chromium) (64-bit)
Logseq: 0.10.10 b250e26 at test.logseq.com
Additional Context
In the process of playing with the new functionality I stumbled across #165. The behavior described in this present issue is visible in the video recording included with #165.
Are you willing to submit a PR? If you know how to fix the bug.
The text was updated successfully, but these errors were encountered: