If the rule is maximally simple, along the lines of `s/[^-A-Za-z0-9]+/_/g`, perhaps followed by `s/^_+|_+$//g` I think conversion between key text and variable name would be easily grasped by anyone. In practice Unicode support would be desirable — even in Icelandic it's moderatly easy to come up with a whole phrase which contains only one or two ASCII letters — and combining marks are essential in some languages, so it's probably safer to replace all sequences of space and ASCII punctuation with underscores or hyphens: `s/[\s\pZ\p{PosixPunct}]+/-/g` — I can easily provide a list of the Unicode code points which match that regex — to get results which are intelligible practically always irrespective of language. It's hardly reasonable to expect that you will get distinct identifiers from `1 (a)` and `1 [a]`. Den ons 4 sep. 2019 10:40Frederik Hartmann skrev: > I think that at the end of the day, everything might depend on how the > current internal implementation of the template engine is. > From an end user perspective > > > $this.is.a.stupid."name with $, . and spaces"$ might actually be great > and more generic than simply replacing spaces with _. > I think allowing spaces or special characters without quoting them might > be unwise and this would bring us extremely close to allowing everything > yaml supports. > > > Am Mittwoch, 4. September 2019 07:34:20 UTC+2 schrieb jiewuza: >> >> >> This issue came up from yaml, so first of all I would like to make sure: >> >> Are we going to just support spaces or all the valid yaml thing >> (https://yaml.org/spec/1.2/spec.html#id2770814) >> >> >> And from the user's point of view, I prefer the former. Because the >> naming is consistent, and it is easier for users to customize templates >> without bearing any rules in mind. >> >> >> John MacFarlane writes: >> >> > It's something we could think about. >> > >> > There are two possible approaches here. >> > >> > 1. Modify doctemplates (our templating engine) to allow spaces in >> > variables. This would mean allowing things like >> > >> > $this is a long variable name$ >> > >> > in a template. I think this kind of thing makes it less clear >> > where the variables are, but it shouldn't pose any problem in >> principle. >> > >> > 2. Modify pandoc so that, when metadata is used to populate >> > template variables, spaces are automatically replaced by >> > underscores. In this case you'd use >> > >> > $this_is_a_long_variable_name$ >> > >> > in your template. >> > >> > Comments (from anyone) are welcome. >> > >> > Frederik Hartmann writes: >> > >> >> That's really not the answer I'd have hoped to hear... >> >> >> >> Do you know if a PR fixing this might be getting accepted? >> >> It's really limiting when perfectly valid yaml can't be used as >> template >> >> input. >> >> >> >> Thanks a lot though. >> >> -- > You received this message because you are subscribed to the Google Groups > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit > https://groups.google.com/d/msgid/pandoc-discuss/35a9acd1-dff5-4529-9abb-d8f9fc87bce4%40googlegroups.com > > . > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhABoO0-K25joAELumEzTOQe4ukkCDemFfONgWN%2B-dLBSA%40mail.gmail.com.