From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/23374 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Frederik Hartmann Newsgroups: gmane.text.pandoc Subject: Re: Can't access keys containing spaces in pandoc Date: Wed, 4 Sep 2019 01:39:55 -0700 (PDT) Message-ID: <35a9acd1-dff5-4529-9abb-d8f9fc87bce4@googlegroups.com> References: <92055fd0-049b-4943-a51a-2eb0905b59ca@googlegroups.com> <5E6256F2-6354-43F9-9A49-2328471A9D2B@gmail.com> <68fbd484-0729-4ee2-a7a2-0846cd0bbd28@googlegroups.com> <7c15c170-1b08-4274-b24e-280b4585c0c6@googlegroups.com> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2205_807628193.1567586395497" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="124015"; mail-complaints-to="usenet@blaine.gmane.org" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBC3JHXELZMMBBXHQXXVQKGQELY7QUEQ-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Wed Sep 04 10:39:59 2019 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane.org Original-Received: from mail-ot1-f57.google.com ([209.85.210.57]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i5Qpa-000W44-MR for gtp-pandoc-discuss@m.gmane.org; Wed, 04 Sep 2019 10:39:58 +0200 Original-Received: by mail-ot1-f57.google.com with SMTP id k22sf12061052otn.12 for ; Wed, 04 Sep 2019 01:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=vc/Yd9zoW0Cbc6r6utoQw1p2CKYvRpw/dVco4rtDU4s=; b=scxcTYmN88r+dXdD49SJqcwv9RzAaWGgc8gqwhXAZYMUSddkA0Yu6905eCJLgPTIsG lENJRbmx+vFoINB01P93ob88nLLI2reyL8oMEgzkqPtvKNg9JugJepM+++NLwa5Nf5Gu beyR/LCrTWMbFVRj6lz0GdLWMcol8J/VPiwT16k5x8IzkHjWD8ZK5Wm68TDfUhjcEbQT xjVKMjvK+CpH4lK0zMSpVRdLQG6TKZpvbnO3synC4LNaLxi5COoPusIX3npcCen3HKgZ u4rcibqpOqRpDBAMM8rCns9QfdH0jpGAus8jX4nyXxEcR+I8TKVe7XK36ePFNdrAZLnA KupQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=vc/Yd9zoW0Cbc6r6utoQw1p2CKYvRpw/dVco4rtDU4s=; b=RZ5icpEWMNlRKzfMgwqK5DNFf+M7CDVKzUEtzb8MDsW2nASiwhJirdTYJfiDUoGXK1 5KxFExEYthLlSPfv4OQ0v3567KPmXtPCZ1ovZb11ytT9OubBz5IVE3MzF/N+tE3eilyQ UVaXIsYwtJQjmniRvDfEUeuL0Chg2zgMZxA7F4eQwIJdpuSXAm3IGCaieQWVilC5oXUo ZFzNmgoRGejuumTU4O2QM9gO40fiCGGP08n53zWyqdBLNsc0NWi4y+gg1xhpLplmpuY/ DpmD2BL/VajSqFb7f4Kfy3aHa8tOfQ/rtvkgvShJIC/E8xiK9u/JO4h2aqy9s/O12hEI qGTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=vc/Yd9zoW0Cbc6r6utoQw1p2CKYvRpw/dVco4rtDU4s=; b=Q2bw/k8yUJa6dFCDt7NhTpsQT+poLPRMfPj6yWBsIioCNcB9vT+qi4gNBT1EEIQ2XH 4fiGKqs6QLdB4cOgfmZZfs8J21XSeh2Xy2sHM4f3UewtLRO9GcHWPLsgCEpOk12zKQ3z K1KpSLdazmIVc6RQVP7LlL+VPG/YQgqVGfkmy5Ir2bNO6NDbvU49Rg5yfYijkJJn06Fb 7Sar1BH3qqIqyeEN9OESGokpc1vuLmbgdUzthVnspg8yJ7Uh7oLEKlsQgEyQ/lUs4rqC tBVFFGdNifn67DuxQ4FrHw9wigGIQmc+LV/1ekrbEVHdkpElzZXGa3HHSVPF6GkrMn5L yknA== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: APjAAAVSdIVk8H55iByesRgesJ+3AbZIe1qPJpbhChD/+Y+CxckWIvyB 7s7ubWEdVzljCAzbS8/1dAk= X-Google-Smtp-Source: APXvYqw2NK3Mma1TF6rrrJgT7j0vLrj1QoOxQU6XbUvcywLZ46atuVYA6kkNbBrH6zFgUbd7AY4wMg== X-Received: by 2002:aca:3754:: with SMTP id e81mr2573447oia.67.1567586397314; Wed, 04 Sep 2019 01:39:57 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a9d:482:: with SMTP id 2ls216733otm.14.gmail; Wed, 04 Sep 2019 01:39:56 -0700 (PDT) X-Received: by 2002:a05:6830:1ac5:: with SMTP id r5mr23727678otc.338.1567586396147; Wed, 04 Sep 2019 01:39:56 -0700 (PDT) In-Reply-To: X-Original-Sender: hecknar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.org gmane.text.pandoc:23374 Archived-At: ------=_Part_2205_807628193.1567586395497 Content-Type: multipart/alternative; boundary="----=_Part_2206_59749887.1567586395497" ------=_Part_2206_59749887.1567586395497 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_2206_59749887.1567586395497 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that at the end of the day, everything might depen= d on how the current internal implementation of the template engine is.>From an end user perspective


$this= .is.a.stupid."name with $, .=C2=A0 and spaces"$ might actually be= great and more generic than simply replacing spaces with _.
I th= ink allowing spaces or special characters without quoting them might be unw= ise and this would bring us extremely close to allowing everything yaml sup= ports.


Am Mittwoch, 4. September 2019 07:34:20 UTC+2 schr= ieb 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. =C2=A0This would mean allowing things like
>
> $this is a long variable name$
>
> in a template. =C2=A0I think this kind of thing makes it less clea= r
> 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. =C2=A0In 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 b= e used as template=20
>> input.
>>
>> Thanks a lot though.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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.co= m.
------=_Part_2206_59749887.1567586395497-- ------=_Part_2205_807628193.1567586395497--