Consider using space instead of % between amount and unit

[DusteDdk]

the {AMOUNT%UNIT} syntax is a bit hard on the eyes, you could match for a space instead, in javascript, the following would return an array where index 1 is the amount and index 2 is the unit, this does not support amounds with spaces in them, which may be an issue.

/{(\S) (.*)}/

[dubadub]

This a very common feedback and I think we need to address this on priority.

I suggest replacing % with *. It looks better for eyes (just one single item to read, less space on on the screen) and also makes more sense as its' often used as multiplication symbol and here we multiply quantity to one standard unit of quantity. If community sees that it makes difference (better for eyes) we can go with that breaking change. This will also require revisiting approach to servings.

I though about using space as an implicit separator and keeping also explicit separator in cases when space doesn't work:

Place @bacon strips{1 kg} on a baking sheet and glaze with @syrup{1 / 2*tbsp}.

But I don't know how to handle cases when we want quantity to keep the space and signal parser to not split by quantity and units. Here's an artificial example:

Add @courgette{1 / 2}...

Something like that?

Add @courgette{1 / 2*}...

[DusteDdk]

I think * is better, less dense. I think reading 1/2 is easier to read than 1 / 2, but that's up to personal tastes.

[dubadub]

@DusteDdk I'll keep the issue open until we make this change or decide to not do one.

[vborovikov]

The scanner can eat characters until the first letter in the stream and then the parser will treat accumulated characters as a number or a fraction and handle the rest of the stream as a measurement unit. I can't think of a measurement unit which doesn't start with a letter.

[chrbala]

Mixed numbers may be desired in some cases. e.g. {4 1/2*cups}

[dubadub]

So I did a bit of comparison between % and * and it looks almost the same when syntax highlighted.

Percent:

Asterisk:

Overall, I don't think it deserves introducing a breaking change.

Does anybody have any other idea?

[aspiers]

I don't see the need for any extra punctuation; it's quite easy to build a parser (and EBNF) which can handle all the obvious ways that a human would write it, e.g. https://regex101.com/r/D3KDJy/1

Admittedly that's not gonna be perfect, but OTOH it took me about 3 minutes to write, so I don't think it would be hard to come up with something robust.

In general, I would suggest taking a leaf out of Markdown's book as an overall design principle:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Markdown became wildly popular because of this, and I believe that similarly, the closer cooklang is to natural (i.e. human) recipe language, the more attractive it will be for users.

[dnlzro]

Also, using an asterisk to separate amount and unit would conflict with the proposed serving size/ingredient scaling syntax (which I think should stay the same, since * makes sense as a multiplication symbol).