enforce key interpretation

[jobol]

I have keys starting with the sharp character '#' (yes I have).

So writing the mustache selector '{{#key}}' for selecting the key is just not possible.

I proposed to add an explicit character for suche issue. My C implementation offers the character colon ':' for solving that issue then '{{:#key}}' selects the value of '#key'.

That issue exists for any reserved character that can not be used for referencing values.

[jgonggrijp]

Currently, the spec is explicit that whitespace is allowed between the sigil and the key, but it is left vague whether whitespace can appear between the opening delimiter and the sigil. This leaves room for implementations to use whitespace after the delimiter as a means of disambiguation.

For example, in Wontache, you can write {{ #key}} to mean "interpolate the value in the context with the name #key". I know that a few other implementations do this as well. There are also implementations that let you control this with a pragma.

Basically, the space acts like your : in that case. Would this work for you?

[jobol]

Obviously, it would work for me if the spec says so.

But I have personnal doubt on that usage of space and would prefer to have a real character and let space be non significant.

In all cases, a clear specification of how to deal with that uncommon key clash would be good.

[jgonggrijp]

Does it only work for you if the behavior is standardized? Why would it not be sufficient if you can use an implementation that already does it?

The problem is that we cannot just specify it, because however the behavior is specified, it is always going to be a breaking change for implementations as well as users. It would require a 2.0 version bump, and while that is not necessarily a bad thing, we cannot do it very often so we would want to pool as many breaking changes as possible. That requires a lot of consensus building, so it will be slow process.

Adding to that, sacrificing a whole sigil just so that a few users can have keys that conflict with other sigils is not going to a popular proposal. Most implementers will tell you to "just don't do that".

Let's talk about that, anyway. Why can you not just start your keys with an alphanumeric character?

(Side note: the discussion feature enables you to reply directly to another comment, rather than to the opening post. Notice the double text boxes at the bottom of the page.)

[jobol]

That is an old request from me: mustache/mustache.github.com#86 is from january 2017.

I admit that normalization is slow.

I admit that not having a such weird key would be the solution but fact is that I have to deal with it.

I am the implementer of a C library for mustach and I maintain it: https://gitlab.com/jobol/mustach
I am not going to switch to an other implmentation because my code is in C.

Using space is not a good idea. Someone not aware of that convention could drop it. It also breaks the look and feel.

Anyway I am happy to see that work on mustache is not abandonned.

Also note that the C implementation also add few extensions to mustache: https://gitlab.com/jobol/mustach#extensions

[jgonggrijp]

That is an old request from me: mustache/mustache.github.com#86 is from january 2017.

Ah. I am going to close that one after responding here. Not because I disagree with the change, but because it is the wrong place for such proposals. The order is as follows:

1. (Optional) discuss the proposal here. You are already doing that.
2. (Necessary) submit a pull request to mustache/spec (i.e., this repo) with tests for the behavior you want to introduce.
3. (Necessary) only after the change has been accepted into the spec, document it in mustache/mustache/man/mustache.5.ron. This is the source file of the manpage that appears on the website.
4. (Semi-automatic) The .ron file gets compiled to HTML and will be copied to the website via the mustache/mustache.github.com repo.

You are free to jump into step 2 above at any time, but be prepared for a lot of resistance and many rounds of reviews (and potentially a final rejection at the end). Discussion over here can help to smooth out as many wrinkles as possible before you start writing tests.

One additional hurdle to anticipate is that : is also the main contender for nested templates, see #162.

I admit that not having a such weird key would be the solution but fact is that I have to deal with it.

Please clarify why you have no choice in the matter.

I am the implementer of a C library for mustach and I maintain it: https://gitlab.com/jobol/mustach I am not going to switch to an other implmentation because my code is in C.

(...)

Also note that the C implementation also add few extensions to mustache: https://gitlab.com/jobol/mustach#extensions

Nice. I invite you to share your story about mustach and its extensions (in general) in a Show and tell.

[jobol]

I am reading the discussion about dotted names or not dotted names. This current discussion might join it and many other about quoting keys or escaping characters.

I can see it is a solution: tell there is a standard escape character, say \ because it is common. So a.b is hierachical for 2 keys when a.b is one key.

[determin1st]

there are variable modifier & and path prefix . which effectively turn the rest sequence into a path:

{{.#path}}
{{&#path}}

[jobol]

Initial dot is not defined at all in the current standard. Maybe in the next?

The ampersand has a specific meaning and using it would avoid escaping.

[determin1st]

what about introducing a principle of data for template against template for data. it makes mustache language a source of authority. ye, i think principles can take own block in the manual, like

principles

logic less - bla bla bla

data for template - bla bla bla

helper helper - ...

principles

• data for template - template is more important than data, a variety sets of data may fit into single template. paths used in the template should look nice, readable and explanatory. thus, the question about escaping special characters to accommodate data should never arise - avoid template for data at all costs.

[jobol]

I understand the idea. It is valuable. Though I would prefer to not introduce such restriction.

[determin1st]

specification moves big rocks. a single : to cover one case is not enough, it is a restriction.
you need to invent the generic sigil escaping for any other case:

{{!name}} - here i want to search for !name
{{another.name}} - here i want to search another.name as a whole key
{{^name}} here i want to search for ^name
etc

there is another path - making any sigil customizable through the option to the instance, like delimiters.

[agentgt]

It seems like #181 is a better idea (by the same OP).

Regardless I think any escaping like syntax would be a 2.0 change.