Reader should recognize comment only if the markers are separated from surrounding text with a space

[theworldjoker]

After updating to 0.13.30, comment “syntax highlighting” in the legacy editor has changed. Comments that start at the end of a word are not parsed properly, which causes parts of the text to appear commented event hough they aren’t. In the rendered view, there is no problem with the actual commenting - this just appears to be tied to the editor.

Steps to reproduce

Create a comment that starts adjacent to a word

One aspect that doesn’t trigger this bug is if you start a comment adjacent to a Markdown formatting character.

Expected result

Only the commented item is “syntax highlighted” as a comment.

Actual result

The comment syntax highlighting only covers the comment itself.

Environment

• Operating system: MacOS

• Debug info:

SYSTEM INFO:
Obsidian version: v0.13.30
Installer version: v0.13.30
Operating system: Darwin Kernel Version 19.6.0: Sun Nov 14 19:58:51 PST 2021; root:xnu-6153.141.50~1/RELEASE_X86_64 19.6.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: on
Base theme: dark
Community theme: none
Snippets enabled: 2
Safe mode: off
Plugins installed: 36
Plugins enabled: 30
1: Find unlinked files and unresolved links
2: Recent Files
3: Show Current File Path
4: Calendar
5: Periodic Notes
6: Review
7: Folder Note
8: Natural Language Dates
9: Incremental Writing
10: Readwise Official
11: Smart Typography
12: Daily Activity
13: Better PDF Plugin
14: Obsidian42 - Jump-to-Date
15: Admonition
16: Workspaces Plus
17: Sort & Permute lines
18: Footlinks
19: Advanced URI
20: Kanban
21: Templater
22: Dataview
23: Expiring Notes
24: Journey
25: Table of Contents
26: MetaEdit
27: Breadcrumbs
28: Obsidian42 - BRAT
29: Flashcards
30: Pandoc Plugin

RECOMMENDATIONS:
Custom theme: for cosmetic issues, please first try updating your theme to latest. If still not fixed, please try to make the issue happen in the help vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the help vault or disable community plugins.

[WhiteNoise]

Thanks, but that is correct. You need space. We will change the way reader interprets it.

[theworldjoker]

It is correct… since when? This was not the case prior to me reinstalling Obsidian for this update, so it is an (unexpected) change. I also could not find a reference to requiring a space in the documentation, in this forum, or on discord. It is also not mentioned in any release notes between 12.23 (works correctly) and 12.30. For an intentional syntax change that breaks existing notes, I would expect to see some mention of it .

I have hundreds of notes that used do this properly without a space. It seems backwards to break these hundreds of notes for… what purpose? I wish I understood, because eliminating this possibility now renders comments completely useless for me, and now that you’ve changed the bug from my report to “we’re going to require spaces for comments to render properly in the reader, even though they currently render just fine without a space”, it forces me to edit hundreds of notes instead of, you know, productively writing.

The core problem with requiring a space is that it renders the space in the output, if for example I have a comment linking to a note between a text and a period. Now the rendered output has a space between the word and period that I did not want, and was not necessary before.

[theworldjoker]

If this is correct, then the fact that this parses properly is wrong (no space):

_[Designing Embedded Software for Change](https://embeddedartistry.com/course/designing-embedded-systems-for-change/)_%%[[221.22 Designing Embedded Software for Change]]%%

[WhiteNoise]

Will be fixed 0.13.31