Nelo Mitranim

Hmm. Even though I still don't understand the intent behind "styling built-in types differently from user-defined types", I don't have weighty arguments against it. What really weirds me out is...

Haha good catch about `unsafe` being part of the spec. Totally forgot this bit. Not sure how we want to handle this, though. Following a recent discussion: [[1]](https://github.com/sublimehq/Packages/pull/1662#issuecomment-444515101), [[2]](https://github.com/sublimehq/Packages/pull/1662#issuecomment-445159220), we...

Should be mostly addressed by #1825. Doesn't include support for `unsafe`, which seems slightly unrelated and a ridiculously rare edge case. If still relevant, feel free to nag me into...

Still looking into this and scratching my head. There are difficulties. Waiting for a revelation while working on other issues.

This happens when the user passes only `gow` flags, without subsequent arguments and flags for the underlying executable such as `go` (in other words, without a subcommand for the subprocess)....

Currently it requires an additional script. Something like: ```sh touch go.sh chmod +x go.sh ``` Content of `go.sh`: ```sh #!/bin/sh go generate && go $@ ``` Usage: ```sh gow -g=./go.sh...

Today we'd be adding support for `go generate`, tomorrow for another subcommand, and so on. Having a flag in `gow` for every subcommand in `go` is not a good API...

Please clarify the intended behavior of `gow -g=./...`. This flag currenty defines the first argument passed to `exec.Command`.

If we really wanted multi-command support, the CLI interface could look like this: ```sh gow -c -v -- generate -- run . ``` Argument terminator could be configurable: ```sh gow...

This is a good reminder that all tools should be written as a library first, with a tiny CLI-adapter module second. Sooner or later, someone will want to use a...