In new syntax mode, stars may be wrongly interpreted as limits of strong

[jnavila]

example simple document:

= Test

Glob patterns are like simplified regular expressions that shells use.
An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9).
You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on.

[mojavelinux]

As with #3548, this is as designed. The backticks apply monospace without changing anything else about how the text is parsed. The parser sees the matching asterisks and forms a bold span. If you indent for the asterisk in the monospaced text to be formatted literally, you need to indicate that.

`+a/**/z+` would match `a/z`

See https://asciidoctor.org/docs/migration/#migration-scenarios

We're well aware that matches for formatting really shouldn't jump outside of the nesting level. But that can only be solved when #61 is addressed, and that requires a specification discussion because it will change the syntax rules.

[mojavelinux]

To be complete, you can also use [x-]a/**/z to activate the combined monospace + literal formatting type. It's just another way of writing it.

[mojavelinux]

And to be fair, this syntax isn't really new. It was introduced in 2014.

[jnavila]

I was more or less expecting the star to be interpreted as formating only when at word boundary. But, I can agree that rules can change.

[mojavelinux]

Constrained formatting is not just a word boundary. It's the inverse. It's when it's not a word character. This is covered in the docs: "The “around” is defined by the fact that word characters do not appear immediately outside the enclosing marks."

See https://asciidoctor.org/docs/user-manual/#constrained-quotes

I'm not saying that it's ideal. But that is what the rules for constrained formatting have always been. And my hope is that we can discuss that in the spec and make it work in a more intuitive way.

[jnavila]

I understand your point, but you still need to have a word character on one side:

• [non-word-char]*[word-char] for an opening sequence
• [word-char]*[non-word-char] for a closing sequence.

In the case here, the star is surrounded by two non-word-chars (the parenthesis), hence my expectation.

[mojavelinux]

Those just aren't the rules. It's not that it is bound by two non-words. It's that it is not bound by word characters. I know the rule seems esoteric, but that's how it has been defined since the very beginning of AsciiDoc. (And hence why I'm saying it needs to be rethought in the spec).

[mojavelinux]

that's how it has been defined since the very beginning of AsciiDoc

I know this because Asciidoctor uses the same regexp that was in AsciiDoc Python. (The difference is that backticks aren't a literal passthrough anymore, so the parsing is like the backticks aren't there). If you take away the backticks, you'd see it does the same thing.

[jnavila]

OK. Thanks for the explanation. Time to sharpen the regex for mass refactoring then

[mojavelinux]

One way to think of is that punctuation are essentially treated like spaces. I know the docs aren't super clear about this, so that's also room for improvement.