Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion]: Disallow unclosed markup #34

Open
vhyrro opened this issue Jul 20, 2024 · 2 comments
Open

[Suggestion]: Disallow unclosed markup #34

vhyrro opened this issue Jul 20, 2024 · 2 comments

Comments

@vhyrro
Copy link
Member

vhyrro commented Jul 20, 2024

This suggestion has already been accepted, but it is written here on the issues so that it can be tracked.

The second (and hopefully last) revision of the Norg specification will disallow unclosed markup. This was quite an easy change and isn't as scary as it seems initially:

  1. The conditions for an opening modifier to exist are strict, this is by design. It's very difficult to unintentionally make something bold, for instance. Therefore, once the situation does arise, an error allows the user to act accordingly, for instance remedying the error by escaping the opening bold marker.
  2. Unclosed markup massively complicates grammars for various common parser generators. The amount of combinations of sequentially closed + unclosed markup that plague our test suite is substantial.

All in all, this makes the format much more predictable in its behaviour, which is what Norg has always aimed to be.

@mrossinek
Copy link
Member

All good 👍

Just leaving a note here to align with #33:
while & and $ super verbatim will have higher precedence than the backslash we must make sure that placing \& or \$ somewhere in the text still works as expected! Because with the current rules, the following is kind of annoying:

I love peanut butter & jam.

That & would result in an unclosed markup error...
So instead, one now always has to escape a standalone & or $ character... 😒

I love peanut butter \& jam.

Not sure if we can find a better solution 🤔

@vhyrro
Copy link
Member Author

vhyrro commented Aug 8, 2024

Hm, that's an interesting issue indeed. I think this will need some further considerations :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants