Variable: erc-settings

erc-settings is a customizable variable defined in erc-settings.el.gz.

Value

nil

Documentation

A match-condition alist for setting ERC's user options locally.

This "meta option" provides a means of specifying buffer-local values for other user options. It does this by setting an option's variable locally in server and target buffers. If a local binding already exists for a variable, ERC leaves it alone. Alist members should be of the form (MATCHCOND . BINDINGS), where BINDINGS is a list of assignments like (VAR VAL . FLAGS).

MATCHCOND works like a buffer-match-p condition, only tailored slightly to meet ERC's unique requirements. The boolean operators and, or, and not remain unchanged, as do strings, which ERC treats as regexps to be matched against a buffer's name. For servers, this name is usually a dialed TCP address while connecting and a network (ID) once connected. Query and channel buffers normally share their target's name, possibly suffixed by a disambiguating "@" + identifier. If MATCHCOND is a function, ERC assumes it's a predicate that takes no arguments and runs in the candidate ERC buffer. As for key-value cons-cell conditions, ERC ignores all traditional ones defined by buffer-match-p, like derived-mode and major-mode, instead preferring to define its own: (network . NETWORK), where NETWORK is a symbol returned by the function erc-network(var)/erc-network(fun); (id . ID), where ID is a user-provided symbol as described by the Info node (erc) Network Identifier; (target . TARGET), where TARGET, if non-nil, is the channel name or query nick; and (name . NAME), which matches a buffer's NAME, as a string.

In BINDINGS, each member's VAR is the symbol of a user option or variable to which ERC assigns the sexp VAL locally in the current buffer. When FLAGS contains the keyword :eval, ERC evaluates VAL as a Lisp form and assigns the result to VAR. Each entry in BINDINGS should appear in order of decreasing match specificity and increasing generality because even though ERC applies all matching entries, it skips subsequent ones for which a local binding already exists.

See Info node (erc) Settings for a friendlier description of the DSL and Info node (erc) Settings Examples for example usage.

This variable was added, or its default value changed, in ERC version
5.7.

Source Code

;; Defined in /usr/src/emacs/lisp/erc/erc-settings.el.gz
(defcustom erc-settings ()
  "A match-condition alist for setting ERC's user options locally.

This \"meta option\" provides a means of specifying buffer-local values
for other user options.  It does this by setting an option's variable
locally in server and target buffers.  If a local binding already exists
for a variable, ERC leaves it alone.  Alist members should be of the
form (MATCHCOND . BINDINGS), where BINDINGS is a list of assignments
like (VAR VAL . FLAGS).

MATCHCOND works like a `buffer-match-p' condition, only tailored
slightly to meet ERC's unique requirements.  The boolean operators
`and', `or', and `not' remain unchanged, as do strings, which ERC treats
as regexps to be matched against a buffer's name.  For servers, this
name is usually a dialed TCP address while connecting and a network (ID)
once connected.  Query and channel buffers normally share their target's
name, possibly suffixed by a disambiguating \"@\" + identifier.  If
MATCHCOND is a function, ERC assumes it's a predicate that takes no
arguments and runs in the candidate ERC buffer.  As for key-value
cons-cell conditions, ERC ignores all traditional ones defined by
`buffer-match-p', like `derived-mode' and `major-mode', instead
preferring to define its own: (network . NETWORK), where NETWORK is a
symbol returned by the function `erc-network'; (id . ID), where ID is a
user-provided symbol as described by the Info node `(erc) Network
Identifier'; (target . TARGET), where TARGET, if non-nil, is the channel
name or query nick; and (name . NAME), which matches a buffer's NAME, as
a string.

In BINDINGS, each member's VAR is the symbol of a user option or
variable to which ERC assigns the sexp VAL locally in the current
buffer.  When FLAGS contains the keyword :eval, ERC evaluates VAL as a
Lisp form and assigns the result to VAR.  Each entry in BINDINGS should
appear in order of decreasing match specificity and increasing
generality because even though ERC applies all matching entries, it
skips subsequent ones for which a local binding already exists.

See Info node `(erc) Settings' for a friendlier description of the DSL
and Info node `(erc) Settings Examples' for example usage."
  :package-version '(ERC . "5.7")
  :type (let* ((flags '(set :tag "Flags"
                            (const :tag "Prefer custom-set (advanced)" :custom)
                            (const :tag "Evaluate form" :eval)))
               (setting `(cons :tag "Binding assignment"
                               (variable :tag "Option/variable")
                               (cons :tag "Value" sexp ,flags))))
          `(alist :key-type erc--buffer-match :value-type (repeat ,setting))))