Consider defining each directive

[adriaanzon]

While it's nice that you don't have to update the Caddyfile each time a new directive pops up, it makes anything you type at the beginning of the line look like a valid directive, which doesn't make syntax highlighting very helpful.

You could automate it using the output of

curl -s https://caddyserver.com/api/download-page | jq -r '.plugins[] | .Name' | sed 's/\./\n/g' | sort -u

which looks like

awslambda
cgi
cloudflare
cors
digitalocean
dns
dnsimple
dnspod
dyn
exoscale
expires
filemanager
filter
gandi
git
googlecloud
hook
http
hugo
ipfilter
jwt
linode
mailout
minify
namecheap
net
ovh
prometheus
proxyprotocol
rackspace
ratelimit
realip
rfc2136
route53
service
tls
upload
vultr

These are some more things than the directives alone, but it's a starting point.

[isobit]

I mostly made this design decision because of @mholt's recommendation. There are two major issues with enumerating the available directives:

1. Even if building the list of directives is scripted, the build script must be re-run and the plugin updated every time the list changes.
2. The "official" list of directives does not cover directives defined by users who build their own copy of Caddy with custom plugins. The Caddyfile syntax defines directives as arbitrary tokens, not by enumeration.

You have a valid point, though, and I do like the idea of automatically updating the list of directives. Perhaps there is a compromise?

[mholt]

@isobit makes some good points. Directives are "anything goes" - there's just no good reliable way for the editor to know what will actually work when the user runs Caddy. The editor would need a way to hook into the exact instance of Caddy that will be executed, because every build is different.

So I recommend highlighting words that "should be" directives based on syntax/location.