-
Notifications
You must be signed in to change notification settings - Fork 494
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
Associate context with a string #5
Comments
We have discussed to support the following syntax: I have been thinking about how to implementent htis and I think this brings some problems as well. What if the string or the description contains I am tending to think that it would be better/easier to allow a way to scape the This proposal is easy to parse:
@williballenthin @mr-tz what do you think? Do you have a better idea to deal with |
I think there's an edge case here:
what happens if the string should contain the literal |
what if we enabled
im not sure if this is legal, but might be more readable:
|
Hm, interesting. For consistency doing it the same way for all features would be good. If the parsing becomes to annoying or the syntax to cumbersome, this string / context (description) could work well:
|
that looks pretty good to me. i still like the shorthand |
In that case I'd say we go with |
Maybe we never have a rule with an I have another proposal. What about splitting using the last |
from offline decision: for all features but string, continue to support inline description using therefore, for all features, including string, also support the second form is the only way to describe a string. for other features, its use is discouraged, unless the description is long. |
@Ana06
@mr-tz
@williballenthin
The text was updated successfully, but these errors were encountered: