Associate context with a string about capa

[mr-tz]

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:

- string: everything and anything
  description: my description

- number: 16
  description: a good number

[Ana06]

We have discussed to support the following syntax:
- string: "'This program cannot be run in DOS mode.' = MS-DOS stub message"

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 ' or "?

I am tending to think that it would be better/easier to allow a way to scape the =, for example \= or to only support it in regular expressions.

This proposal is easy to parse:

value, symbol = s.split(' = ', 1)
value.replace('\=', '=')

@williballenthin @mr-tz what do you think? Do you have a better idea to deal with ' or "?

[williballenthin]

I think there's an edge case here:

value.replace('\=', '=')

what happens if the string should contain the literal \=?

[williballenthin]

what if we enabled string to also be a sequence of two elements, like:

- string:
  - This program can't be run in DOS mode
  - MS-DOS stub message

im not sure if this is legal, but might be more readable:

- string: This program can't be run in DOS mode
  - MS-DOS stub message

[williballenthin]

[williballenthin]

that looks pretty good to me.

i still like the shorthand 16 = a good number, but it doesn't work in some cases (strings). we could do our best, and then use the linter to warn/fail when a term is ambiguous?

[mr-tz]

In that case I'd say we go with 17 = also a good number for all features until someone break it with a good use-case 😃

[Ana06]

@williballenthin

what happens if the string should contain the literal =?

\\=, escaping the =

Maybe we never have a rule with an = in a string. I don't think that it is worthwhile to complicate the syntax for all features just for this case.

I have another proposal. What about splitting using the last = surrounded by spaces? which means that all characters (including =) are allowed in the string, but = surrounded by spaces is not allowed in the description. I can't come up with any case where a description should have an =. I could add a linter which complains if there are more than one and the type is not string (and maybe a warning for string).

[williballenthin]

from offline decision:

for all features but string, continue to support inline description using =. for string, the parsing is too complex to be worth it right now.

therefore, for all features, including string, also support description:.

the second form is the only way to describe a string. for other features, its use is discouraged, unless the description is long.