Sorry, I wasn't in my right mind when I said
> The script shouldn't be sourced on every single invocation of _aws. While it may not hurt performance much, I find the idea of slipping bashcompinit initialization code into compsys runtime code just for the sake of saving one line of manual configuration objectionable on principle. There's also filesystem access here which could be very slow in certain circumstances.
In fact, `complete -C aws_completer aws` invokes `compdef '_bash_complete -C aws_completer' aws`, so when it's done `aws`'s completion would be bound to `_bash_complete -C aws_completer`; so the initialization is done only once as opposed to what I said.
Therefore, what I would do is to ask the upstream the add the standard `#compdef aws` comment to the top of `aws_zsh_completer.sh`. It doesn't affect the sourcing workflow they currently recommend, but adding that means we could simply
```rb
zsh_completion.install "bin/aws_zsh_completer.sh" => "_aws"
```
i.e. no change to the current formula. Then `_aws` would be autoloaded by compinit, and its contents (basically `autoload -Uz bashcompinit; bashcompinit; complete -C aws_completer aws`) would be run the first time someone attempts to complete `aws`.
There is one problem though. The `_aws` function quits right after `complete -C aws_completer aws`, so it doesn't actually provide any completions the first time it's invoked; which means the first time you press tab nothing happens, and only when you press tab again — this time `aws`'s completion is bound to `_bash_complete -C aws_completer` — would you get results. To work around the problem, I'd recommend adding
```zsh
_complete aws 2>/dev/null
```
to the end of `aws_zsh_completer.sh`. I'm suppressing stderr to avoid the "... can only be called from completion function" error message when `aws_zsh_completer.sh` is sourced (for the other workflow).
> aws/aws-cli#2708
Two things recommended above: the `#compdef` comment, and `_complete aws 2>/dev/null` at the end.
In addition,
> [[ $ZSH_VERSION < 5.0.3 ]]
is not robust. If fails with 10.0.0, for instance. Use `is-at-least`:
```zsh
autoload -Uz is-at-least
if ! is-at-least 5.0.3; then
: # blah blah
fi
```
Okay, I thought `LANG` is set by lanuchd for all processes, but I inspected a few (with `ps eww`) and apparently I was wrong. Anyway, my `/usr/local/bin/fish`, run in either Terminal.app or iTerm 2 (non-login and run directly), always picks up `LANG` from somewhere and it shows up on the command line. Interestingly, Emacs.app when launched as an app doesn't have `LANG` on the command line, but `LANG` does show up in Emacs's `initial-environment`; and it is the only difference from the environment shown by `ps eww`.
The script shouldn't be sourced on every single invocation of `_aws`. While it may not hurt performance much, I find the idea of slipping bashcompinit *initialization* code into compsys *runtime* code just for the sake of saving one line of manual configuration objectionable on principle. There's also filesystem access here which could be very slow in certain circumstances.
Also, they unconditionally override the entirety of `_bash_complete` to work around a fairly ancient bug that's been fixed in Zsh 5.0.3 in 2013; granted upstream `_bash_complete` hasn't changed since then, but apparently it's not best practice...
I'd recommend just putting
```zsh
autoload -Uz bashcompinit; bashcompinit; complete -C aws_completer aws
```
in caveats.
I find this questionable.
Reproduction:
1. I cannot reproduce the problem in windowed Emacs.
LC_ALL=C LANG=C /Applications/Emacs.app/Contents/MacOS/Emacs -Q
I can paste Chinese text in here just fine.
2. I can sort of reproduce in non-windowed Emacs.
LC_ALL=C LANG=C emacs -nw -Q
When I try to paste Chinese text (with debug trace enabled) I get
```
Debugger entered--Lisp error: (wrong-type-argument char-or-string-p 134217828)
xterm--pasted-text()
xterm-paste()
funcall-interactively(xterm-paste)
call-interactively(xterm-paste nil nil)
command-execute(xterm-paste)
```
3. With a non-UTF-8 locale that supports Chinese, e.g., `zh.GBK`, pasting again works just fine.
LC_ALL=zh_CN.GBK LANG=zh_CN.GBK emacs -nw -Q
Thoughts
- Is there a problem when you use the POSIX locale? Sure, probably.
- However, `LANG` is set by the system by default — just try to start `/bin/sh` unbootstrapped and look into `env`; and the default factory `LANG` is probably not `C`. If your locale is `C`, it's most likely your own misconfiguration.
- Emacs works fine with reasonable locales like `zh.GBK`.
Add Soft U2F v0.0.8
===================
https://github.com/github/SoftU2F
https://githubengineering.com/soft-u2f/
---
After making all changes to the cask:
- [x] `brew cask audit --download {{cask_file}}` is error-free.
- [x] `brew cask style --fix {{cask_file}}` reports no offenses.
- [x] The commit message includes the cask’s name and version.
Additionally, if **adding a new cask**:
- [x] Named the cask according to the [token reference].
- [x] `brew cask install {{cask_file}}` worked successfully.
- [x] `brew cask uninstall {{cask_file}}` worked successfully.
- [x] Checked there are no [open pull requests] for the same cask.
- [x] Checked the cask was not already refused in [closed issues].
- [x] Checked the cask is submitted to [the correct repo].
[token reference]: https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/token_reference.md
[open pull requests]: https://github.com/caskroom/homebrew-cask/pulls
[closed issues]: https://github.com/caskroom/homebrew-cask/issues?q=is%3Aissue+is%3Aclosed
[the correct repo]: https://github.com/caskroom/homebrew-cask/blob/master/doc/development/adding_a_cask.md#finding-a-home-for-your-cask
[version-checksum]: https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/sha256.md#updating-the-sha256