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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.