Search first

• I searched and no similar issues were found

What Happened?

Description:

I've been running into an issue when trying to use inline code blocks to reference Logseq properties. When I put a property inside an inline code block, it causes the block to be treated differently. It appears like Logseq is trying to treat the entire block as one long property. The most notable impact is the effect it has on internal links and the auto-complete functionality for open/closed brackets. It makes it hard to create internal links because the normal functionality does not apply. This issue also affects using the Enter key to separate lines into new blocks. For whatever reason, even though the property is inside backticks, Logseq still tries to interpret it as a real property. When pressing Enter, Logseq will reformat the block to match the property syntax.

References to Previous Issues:

• Open Issue: #2346 - "inline code blocks : properties:: are still parsed as properties when they are enclosed in backticks".
• Closed Issue: #1427 - "code blocks :properties: inside code blocks are interpreted as properties".

Judging by previous bug reports, this issue has been around for a while. There's an open issue from three years ago (#2346), but it hasn’t been updated since the day it was created. It is technically assigned to someone. I commented on both the open and closed issues just in case, but haven't heard back. This bug is still causing problems for me and likely for others too.

Reproduce the Bug

1. Open any page in Logseq.
2. Type a sentence that includes a property you want reference as an example. (The goal is not to invoke the property or see it's value, etc. Simply to mention the property like when documenting a process)
   ex.

   - To hide banners on specific pages, update the page's `banner::` prop to false.

3. Highlight a word in the block that isn't inside the inline code block. eg. "update" and press the open-bracket key [ twice.

result:

- To hide banners on specific pages, [[] the page's `banner::` prop to false.

4. You should see that, rather than format "update" as an internal link ([[update]]) as is expected, it will erase the text, leaving you with [[].
5. Without changing anything, hover your mouse over the block's text. You should also notice that Logseq is giving you the option to create a new property; however, the new property is just a concatenation of your entire block's text, with hyphens replacing any spaces.

Expected Behavior

- To hide banners on specific pages, [[update]] the page's `banner::` prop to false.

Inline code block behavior: Properties inside of inline code blocks or regular code blocks should be treated more or less like plain text. With the exception of any code formatting provided by markdown, no other behavior is expected from this text.

Bracket auto-complete: When working correctly, Logseq with automatically surround the highlighted word with brackets, creating an internal link.

Formatting text as property: Logseq should only format text as a property when it is defined outside of a code block

Screenshots

In the screenshot below, you can see that Logseq is giving me the option to create a new property, even though the only property syntax I have in this block is contained within an inline code block using single backticks.

Furthermore, if I try to use brackets to create a link by highlighting a word and pressing the open bracket key twice, when I click the open bracket key for the second time, it erases my text, and does not create a second closed bracket. Leaving me with "[[]".

I am able to manually type my link after this happens (by typing the page's name and adding the missing closed bracket), but I am certain this is not the intended behavior.

Desktop or Mobile Platform Information

Windows 10 Pro, Desktop App v0.10.9

Additional Context

None

Are you willing to submit a PR? If you know how to fix the bug.

• I'm willing to submit a PR (Thank you!)