Skip to content
This repository has been archived by the owner on May 25, 2019. It is now read-only.

Ansible functions #28

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Ansible functions #28

wants to merge 2 commits into from

Conversation

benjifisher
Copy link
Contributor

This needs thorough testing, but I think it solves #2. The first commit reorganizes parts of the jinja syntax file, but should have no effect at all on the highlighting. The second commit uses the syntax cluster defined in the first commit to get the desired effect, highlighting "foo bar" in when: foo bar the same way it is highlighted in "yaml string {{ foo bar }}".

Note that #26 currently breaks some test cases, so that should probably be resolved before this is considered.

@chase
Copy link
Owner

chase commented Dec 1, 2014

#26 should be resolved by #27, but I'd like you to go over it to see if I missed any parts of the pointless redundancy between yamlScalar and yamlMapping you mentioned before I merge it with master.

@chase chase mentioned this pull request Dec 21, 2014
Add this cluster, then replace a bunch of
containedin=jinjaVarBlock,jinjaNested clauses with
contains=@jinjaNestedElement on the jinjaVarBlock and jinjaNested syntax
groups.
These replace the jinja variants for mappings where the key is one of
the Ansible keywords when, changed_when, or with_*. The ansibleVarBlock
item can contain exactly the same things as the jinjaVarBlock element,
namely the @jinjaNestedElement syntax cluster.
@benjifisher
Copy link
Contributor Author

I was testing this and noticed that a lot of the syntax highlighting was messed up. Then I realized that the problem was coming from 8050b3f, which we have since reverted.

So I rebased this branch onto master. In part, I was curious to see how GitHub would treat a rebase on a pending PR. Somewhat to my surprise, it updated the PR automatically. As I write this, the two commits were "added" 22 days ago, but "committed" about 15 minutes ago.

I think that this patch works well: it fixes #2 and does not seem to cause any other problems. I would like another pair of eyes on it before I merge.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants