Nicholas,
Eliding the parts I agree with...
Nicholas D Steeves wrote:
> I suspect that the conversion to a derived major mode should be done
> before this software is suitable for a Debian stable release.
I agree making it a local minor mode, instead of a derived major mode
(derived from yaml-mode) is a weird decision.
I *guess* this is because (AIUI) ansible has three file formats:
1. yaml + jinja2
(used for playbook.yaml and inventory.yaml)
2. ini + weird magic
(used for inventory.ini, instead of newer inventory.yaml)
3. plain jinja2 templates
(e.g. httpd.conf.j2, which becomes /etc/httpd.conf)
...and the ansible-mode author wanted to add the ansible
domain-specific magic to all three.
Personally I only really care about #1, so define-derived-mode from
yaml-mode makes sense to me.
> Were you able to tell if the autocompletion and yasnippets are so
> limited as to be not useful to people who use this functionality? The
> snippets appear to be surprisingly comprehensive to me.
Sorry, I did not investigate this closely.
If you install ansible on any old system, you can run
ansible-doc --list # pick one, e.g. "copy"
ansible-doc copy
and scroll down to look at the examples.
You can see the same information here (slightly different version):
https://docs.ansible.com/ansible/latest/modules/copy_module.html#copy-module
The snippets look to me as if they are derived from these examples.
For me, alarm bells immediately went off because the emacs-ansible
snippets can get out of sync with what the actual ansible codebase
expects.
Most of the snippets seemed to only be 1 or 2 attributes anyway, something like
- name: $1
copy: dest=$2 $*
I wouldn't want to be in charge of constantly keeping those in sync with
ansible.
...having just written that, I recall that some ansible modules are
flagged with "Red Hat promises not to break backwards compatibility",
so I guess those would be OK to have snippets for.
> > It depends on packages named simply "s" and "f" (oy!), but
> > those appear to be in Debian already (elpa-s and elpa-f).
> > I installed those then did
> >
> > emacs -nw -q \
> > -l emacs-ansible/ansible.el \
> > -eval "(require 'yaml-mode)" \
> > cyber-ansible/Cyber-BCP.yaml \
> > -eval '(ansible +1)'
>
> Excellent work, are you interested in joining the Debian Emacsen team?
> It's clear you have the skills. :-) I'd be happy to answer questions
> and provide guidance if necessary.
Ehhhh, maybe. :-)
You can find me (as "twb") on #emacs on irc.freenode.net every day.
We can chat about it there.
> > ...and yeah OK, there's more color. It treats "name: xxxx" specially,
> > and it tries to recognize the embedded jinja2 {{}} {%%} crap without
> > actually resorting to using an actual jinja major mode (via mumamo or
> > mmm).
>
> This is the most interesting feature imho, eg: a lightweight jinja2
> parser, and should go in the long description. Whoever fulfills this
> RFP should verify that this functionality can catch jinja2 syntax errors.
I think I oversold that.
It looks to me like it's just a single font lock for {{}}:
(defvar ansible-playbook-font-lock
`(("\\({{\\)\\([^}]+\\)\\(}}\\)"
. #)
I would much rather have a "real" jinja2-mode be mixed into yaml-mode,
similar to how mhtml-mode handles CSS-in-HTML today.
(I realize this is a hard and unfun problem in Emacs.)
Once major gotcha: in ansible files,
the "when" clause has an implicit {{}}, where other clauses don't.
That's definitely domain-specific (i.e. ansible-only) behaviour.
So e.g.
name: eat {{animal}} for food
eat: food={{animal}}
when: animal
vars:
- animal: trout
name: >
check if {{animal}} is neither a dog not a cat
(answer is {{'dog' != animal and 'cat' != animal}}')
eat: food={{animal}}
vars: animal=trout
when:
- animal
- "'dog' != animal" # double-quotes are a workaround to avoid
- "'cat' != animal" # confusing the yaml parser - the jinja2 parser
# never sees them.
