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 <j...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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 <hec...@gmail.com> 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.