* "Canonical App Name" becomes "Simplified App Name"
* devscript `cask_namer` renamed to `generate_cask_token`
* doc file `CASK_NAMING_REFERENCE.md` renamed to `cask_token_reference.md`
* DSL uses `"#{token}"` for interpolation instead of `"#{title}"`
* documentation text
* backend code (variables, method, class names)
* error message text
* tests
* code comments
* Cask comments
* emphasize `tags :name`
* doc: use "vendor" consistently instead of "developer"
* doc: many man page argument descriptions were incorrect
* incidental clarifications
Many backend variables similar to `cask_name` or `cask` have
been standardized to `cask_token`, `token`, etc, resolving a long-
standing ambiguity in which variables named `cask` might contain
a Cask instance or a string token.
In many places the docs could be shortened from "Cask name" to
simply "token", which is desirable because we use the term "Cask"
in too many contexts.
* was already done, but inconsistently
* this style follows homebrew Formula
* covers user-facing messages, test titles, comments
* some related minor orthography is included, such
as the consistent spelling of our project name as
"homebrew-cask"
* grammar nits
- Show a more user-friendly error message when dealing with an option whose (mandatory) argument is missing.
- Likewise, we show a more user-friendly error message when a given option is ambiguous. Examples:
- Given `-f`, the parser successfully expands to `--fontdir`.
- Given `-c`, we fail to expand because the parser can’t tell if the user means `--caskroom` or rather `--colorpickerdir`. This exception now results in a nicer error message.
- Some commands now result in a consistent error message when a required cask name is missing.
This affects all stable commands which require one or more cask names as arguments, i. e. `cat`, `create`, `edit`, `fetch`, `info`, `install`, `uninstall`, and `zap`.
- Up to now, the commands `cat`, `create`, `edit`, and `info` used to treat any unknown option as a cask name. This commit changes that behaviour to make it consistent to the rest of the commands (like `fetch`, `install`, `uninstall`, and `zap`), who have silently discarded any unknown option in the past, and continue to do so.
Because backtick has a different meaning in the shell, and the user
may copy-and-paste such text.
Some light re-wording included as well, and a reference to "brew cask edit"
changed to "brew cask cat" for simplicity.
- add new file "cask/utils.rb" analogous to "utils.rb" in Homebrew
- define odebug and odumpcask, analogs of ohai and friends, but
which only give output when --debug is in effect
- move the debug setting from an instance variable in Cask::CLI
to a method Cask.debug, defined in "lib/cask/options.rb", which
was added in #2276. (Perhaps options.rb should be merged back
into Cask::CLI).
- sprinkle odebug statements liberally throughout the codebase
- update tests
the create command opens up an editor with template to get started
remove --create override flag from `brew cask edit`
hopefully this will be more straightforward for contributors
refs #306
Most notably, Cask.all returns an array of strings,
not of Cask instances. This makes things easier, as
well as faster, as there's no need to run map(&:to_s)
everywhere anymore.
self.path is a utility method which returns the path
of the cask from its title. There's something subtle
going in there:
- If `cask_title` is fully qualified, e.g.
"phinze-cask/alfred", it's straightforward.
- If `cask_title` is only the name, e.g.
"firefox-aurora", the name is matched from
the full list (self.all) (which isn't sorted)
and the first result is returned.
Hence, self.path with only the name is not precise.
There might be the possibility to apply heuristics
to do a better match (prefer phinze-cask, or maybe
installed casks?) but that's for another issue :-)
self.nice_listing is another utility method used
in `search` and `list`. It returns a list where
unique casks don't have a prefix, and duplicates
do. The prefix is the tap name. The list is then
sorted. For an example or two, look at the first
comment on phinze/#12.
