Clarify that curved quotes have no "unconstrained" versions

[andrewcarver]

In the User Manual,

• a table in sec. 40.2 shows what "quote" formatting marks there are;
• secs. 12.2,3 give a thorough discussion of when to use unconstrained quotes--but not, which such quote marks are available;
• sec. 22.2 gives a thorough discussion of using both single and curved quotation marks--but it makes no mention of any "unconstrained" version.

This constituting pretty much what's said on the topic, the overall impression the reader gets from this is that there are unconstrained versions available for all the "quote" marks. The reader finds out only by experimenting, and/or the hard way, if at all, that there are no unconstrained versions for single or double curved quotes.

Now, I'm not sure whether AsciiDoctor's lack of such versions qualifies as a "bug". But I am sure that as long as such versions are missing, the reader needs to know. And, maybe, we might even warn them that the S will likely HTF whenever they try to use the standard curved-quote notations in places that require unconstrained versions. (But also, we could remind them that, worst case, they can use the predefined attributes for these marks: Appendix A.3.)

[andrewcarver]

Or, rather than advising them to memorize arcane predefined attributes, here's a fix that would commonly work, which looks clunky but feels, to me, more natural:

—pass:q["`hello`"]

[andrewcarver]

I suggest that it would be very sensible to follow the example of the AsciiDoc User Guide ( http://asciidoc.org/asciidoc.css-embedded.html#_unconstrained_quotes ) and put in our section on "Unconstrained quotes" ( http://asciidoctor.org/docs/user-manual/#unconstrained-quotes ) a clear statement of exactly which "quotes" (including formatting marks) have unconstrained versions; and, of what those versions consist.

[andrewcarver]

In retrospect, I see that one big part of the problem is the BASH-y, Perl-y use of the term "quote"--to mean, more or less, "quote-like operator". If that is indeed the sense in which the term is used in most AsciiDoc/tor contexts, then those would-be users (like me) who hit the topic with not a sufficient background in Linux / Perl are bound to be confused--unlesss this usage be explained to them--not realizing that the one sort of "quote-like things" OMITTED from the meaning of "quotes" is.... quotes!

An addition of some clarification on that would no doubt be helpful to such would-be users. But that doesn't mitigate, really, the need for clarification of the contexts in which curly quotes work, and the contexts in which they don't work. Indeed, the topic of "quotes" is even more convoluted than I indicated in prior comments.

After experimenting with various combinations, I came up with this as a rule of thumb: "Bold works OK when surrounding other quotes, and with curly-quotes in any order—​but italic does not, unless unconstrained when surrounded by curly-quotes, or else surrounding an inline pass macro or an unconstrained version." Yet that's about as clear as mud--even to me. Would that all "quotes" just worked--or, at least, all obeyed the same set of rules (of where they work and where they don't). Until then, I must work on finding a clearer guideline than that, just to feel like I know how to use the syntax.

I apologize that this "Issue" has blown up far beyond what I intended, so much that it's hard to know even what it is, now. But, still it's about "quotes", in the broadest sense (which includes even those things most people know as "quotes"--e.g., "curly quotes"); and, it still is a yearning for better explanation(s) of the rules concerning them.

[andrewcarver]

For all that it's worth ;) , I did reach, I think, a more intelligible, and more complete, form of the guideline I was after:

Bold works OK when surrounding other (non-quote) ‘quotes’, and with curly-quotes in any order—​but italic does not, unless, when surrounded by curly-quotes, it is unconstrained or surrounded by the inline pass:q macro; or, when surrounding other ‘quotes’, the latter are unconstrained or in an inline pass:q macro.

However, as full disclosure: I tested only combinations involving mixtures of bold, italic, and curly quotes; and did not include more than two of these kinds in any combination. So, things might be even hairier if we bring other 'quote' marks into the tests.

[andrewcarver]

P.S. When it comes to coding up solutions to these "quote" wrinkles, it MIGHT not be "either-or" :|

Are you familiar with "recursive" regular expressions? ( http://www.regular-expressions.info/recurse.html ) I've used them; they are AWESOME. And maybe they offer a middle, more easily achievable way between the routes you mentioned at the end of 12.4:

"This ['formatting edge-cases'] situation may improve in the future when Asciidoctor is switched to using a parsing expression grammar for inline formatting instead of the current regular expression-based strategy. "

[mojavelinux]

I agree that recursive regexp is a good option to consider. Thanks for pointing that out.