> why is this kind of "function" loading used for things like promptinit, compinit, and colors?
Yeah that's a good point. One reason I can think of is that people expect to use stock functionalities without knowing where the files are installed to; those are implementation details to some extent. External packages, on the other hand, are fully controlled by you. An alternative approach (that could be built in) is something like `zmodload`, where a bunch of parameters and functions (not just the initializer) are available as soon as you load a module. (I'm only talking about the intended behavior here; actual zsh modules are a different breed.) IMO that's much more elegant. Prezto, for instance, has `pmodload` that works like this (sourcing a bunch of init scripts and loading a directory of functions), and its kinship to `zmodload` is obvious. `antigen bundle` (`-antigen-load`) basically works this way, too.
Also, when a function is named like `*init` it's much more obvious that it's an initializer which isn't intended to be called afterwards. Which is true for both `promptinit` and `compinit`.
Still, the great majority of functions in `$prefix/share/zsh/functions` are meant to be functions.
Similar to https://github.com/Homebrew/homebrew-core/pull/7793#issuecomment-266573598, `antigen.zsh` isn't a function definition; it's an init script with configuration statements and function definitions that should be sourced once. The difference from the `zsh-autosuggestions` case is that here your autoloaded `antigen` "function" will replace itself with an actual `antigen` upon first execution, which arguably makes it even more confusing. (`autoload -Uz antigen && antigen help` doesn't work, `autoload -Uz antigen && antigen && antigen help` works.) Again, 👎
`zsh-autosuggestions` isn't meant to be a function, so you're polluting the global namespace, and less experienced users might be tricked into thing it's a function that should be called repeatedly. Not sure it's the best idea.
Bot's toast. There's something wrong with dep parsing, resulting in `homebrew/science/opencv` being looked for for no reason on 10.11 and 10.10, and `homebrew/dupes/tcl-tk` on 10.12.
Also, CLT on 10.12 seems to be missing since yesterday (compare https://bot.brew.sh/job/Homebrew%20Core/13055/version=sierra/testReport/brew-test-bot/sierra/config/ and https://bot.brew.sh/job/Homebrew%20Core/13056/version=sierra/testReport/brew-test-bot/sierra/config/). Not good because python3 bottle can't be poured now. What's going on?
mpv: build HTML man page
========================
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
mpv's man page is gigantic (479K), and at this length an HTML version is more user friendly (IMHO). The `--enable-html-build` configure option adds only one file, `share/doc/mpv/mpv.html` (716K). There's no extra dep, since we're already depending on `docutils` to build `mpv.1`.
This is probably not worth a revision; a bottle rebuild is enough.
> Does that mean that it's impossible to detect that emacs depends through a non-default option on imagemagick and the latter is updated?
ImageMagick is updated all the time: https://github.com/Homebrew/homebrew-core/pulls?utf8=%E2%9C%93&q=is%3Apr%20imagemagick. Most of them are ABI-compatible updates.
> whether imagemagick upgrades should include emacs revision bumps?
Don't think so.
This ABI-breaking-dep-upgrade-breaks-formula-compiled-with-options problem has been there since I started using brew years ago. IMO the best we could do is issue a warning and encourage a reinstall when some linkage is broken where it wasn't pre-upgrade.
Well, `--with-imagemagick` is not related to `--with-cocoa`... Here's a list of things you can do when you compile with IM suppport: https://www.emacswiki.org/emacs/ImageMagick. You can simply drop `--with-imagemagick` if you don't need those features.
Links to previous/next day, month, or year
==========================================
Previous and next links could look like
<img width="832" alt="screen shot 2016-12-12 at 12 01 14 am" src="https://cloud.githubusercontent.com/assets/4149852/21088578/436adb16-bffe-11e6-9800-8fce6cb5630e.png">
where there's no link when the previous/next day (month, or year) isn't there.
The code to achieve the effect above:
```html
<body>
<h1><a href="../../../" class="undecorated">GHC</a> <a href="../../" class="undecorated">2016</a>-<a href="../" class="undecorated">12</a>-12</h1>
<span class="left">1 comment.</span>
<span class="right">
<a href="/gharchive/2016/12/11/">previous</a>
next
</span>
<div style="clear: both"></div>
<hr>
<div id="v1KID">
<a href="#v1KID"><time datetime="2016-12-12 01:35:41">2016-12-12 01:35:41</time></a>, <a target="_blank" href="https://git.io/v1KID">https://git.io/v1KID</a>
<pre>Revision a bump of revdeps because ABI compatibility has been broken and the dylib versions have been bumped.</pre>
</div>
<hr>
</body>
```