cheat/configs/conf.yml
Chris Allen Lane 91f0d02de2
v3.3.0 (#525)
* feat: directory-scoped cheatpaths

`cheat` now searches for a `.cheat` directory in the current working
directory. If found, that directory is (temporarily) appended to the slice
of cheatpaths.

* makefile wip

* fix: appeases linter

Appeases linter (`go vet`) by adding quotation marks to YAML struct
tags.

* chore: modifies .gitignore

Adds `tag` to `.gitignore`

* feat: adds Makefile

Adds a `Makefile` for managing build-related tasks.

* chore: documents directory-local paths

Adds documentation regarding the new directory-local cheatpath
functionality.

* chore: updates dependencies

* chore: bumps version to 3.3.0

* chore: updates bin scripts

- Removes `build_release.sh`
- Places deprecation notice in `build_devel.sh`, as its purpose has been
  superceded by the `Makefile`.
2020-01-20 12:34:48 -05:00

65 lines
2.5 KiB
YAML

---
# The editor to use with 'cheat -e <sheet>'. Defaults to $EDITOR or $VISUAL.
editor: vim
# Should 'cheat' always colorize output?
colorize: true
# Which 'chroma' colorscheme should be applied to the output?
# Options are available here:
# https://github.com/alecthomas/chroma/tree/master/styles
style: monokai
# Which 'chroma' "formatter" should be applied?
# One of: "terminal", "terminal256", "terminal16m"
formatter: terminal16m
# The paths at which cheatsheets are available. Tags associated with a cheatpath
# are automatically attached to all cheatsheets residing on that path.
#
# Whenever cheatsheets share the same title (like 'tar'), the most local
# cheatsheets (those which come later in this file) take precedent over the
# less local sheets. This allows you to create your own "overides" for
# "upstream" cheatsheets.
#
# But what if you want to view the "upstream" cheatsheets instead of your own?
# Cheatsheets may be filtered via 'cheat -t <tag>' in combination with other
# commands. So, if you want to view the 'tar' cheatsheet that is tagged as
# 'community' rather than your own, you can use: cheat tar -t community
cheatpaths:
# Paths that come earlier are considered to be the most "global", and will
# thus be overridden by more local cheatsheets. That being the case, you
# should probably list community cheatsheets first.
#
# Note that the paths and tags listed below are just examples. You may freely
# change them to suit your needs.
- name: community
path: ~/.dotfiles/cheat/community
tags: [ community ]
readonly: true
# Maybe your company or department maintains a repository of cheatsheets as
# well. It's probably sensible to list those second.
- name: work
path: ~/.dotfiles/cheat/work
tags: [ work ]
readonly: false
# If you have personalized cheatsheets, list them last. They will take
# precedence over the more global cheatsheets.
- name: personal
path: ~/.dotfiles/cheat/personal
tags: [ personal ]
readonly: false
# While it requires no specific configuration here, it's also worth noting
# that 'cheat' will automatically append directories named '.cheat' within
# the current working directory to the 'cheatpath'. This can be very useful
# if you'd like to closely associate cheatsheets with, for example, a
# directory containing source code.
#
# Such "directory-scoped" cheatsheets will be treated as the most "local"
# cheatsheets, and will override less "local" cheatsheets. Likewise,
# directory-scoped cheatsheets will always be editable ('readonly: false').