aboutsummaryrefslogtreecommitdiffstats
path: root/site-lisp/use-package-2.4.6/use-package.texi
diff options
context:
space:
mode:
authorAstounds <kirito@disroot.org>2026-08-07 16:18:49 -0500
committerAstounds <kirito@disroot.org>2026-08-07 16:18:49 -0500
commit79e04842d239770fbe86bcfa60c693480a6b60cc (patch)
tree24006eab643de7333e24ab80f96ac032766ddeb9 /site-lisp/use-package-2.4.6/use-package.texi
parente90e5cfbc6ca58c26a91a6b449b017b1102069be (diff)
downloademacs-personal-79e04842d239770fbe86bcfa60c693480a6b60cc.tar.lz
emacs-personal-79e04842d239770fbe86bcfa60c693480a6b60cc.tar.xz
emacs-personal-79e04842d239770fbe86bcfa60c693480a6b60cc.zip
test
Diffstat (limited to 'site-lisp/use-package-2.4.6/use-package.texi')
-rw-r--r--site-lisp/use-package-2.4.6/use-package.texi2232
1 files changed, 2232 insertions, 0 deletions
diff --git a/site-lisp/use-package-2.4.6/use-package.texi b/site-lisp/use-package-2.4.6/use-package.texi
new file mode 100644
index 0000000..da3deb0
--- /dev/null
+++ b/site-lisp/use-package-2.4.6/use-package.texi
@@ -0,0 +1,2232 @@
+\input texinfo @c -*- texinfo -*-
+@c %**start of header
+@setfilename ../../info/use-package.info
+@settitle use-package User Manual
+@set USEP_VER 2.4.5
+@set USEP_DIST as distributed with Emacs @value{EMACSVER}
+@include docstyle.texi
+@syncodeindex vr cp
+@syncodeindex fn cp
+@include emacsver.texi
+@c %**end of header
+
+@copying
+This manual is for use-package @value{USEP_VER} @value{USEP_DIST}.
+
+Copyright @copyright{} 2022--2024 Free Software Foundation, Inc.
+
+@quotation
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, with the Front-Cover Texts being ``A GNU Manual'',
+and with the Back-Cover Texts as in (a) below. A copy of the license
+is included in the section entitled ``GNU Free Documentation License''.
+
+(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
+modify this GNU manual.''
+@end quotation
+@end copying
+
+@dircategory Emacs misc features
+@direntry
+* use-package: (use-package). Declarative package configuration for Emacs.
+@end direntry
+
+@finalout
+@titlepage
+@title use-package User Manual
+@subtitle for version USEP_VER
+@author John Wiegley & Stefan Kangas
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@top use-package User Manual
+
+The @code{use-package} macro allows you to set up package
+customization in your init file in a declarative way. It takes care
+of many things for you that would otherwise require a lot of
+repetitive boilerplate code. It can help with common customization,
+such as binding keys, setting up hooks, customizing user options and
+faces, autoloading, and more. It also helps you keep Emacs startup
+fast, even when you use many (even hundreds) of packages.
+
+Note that use-package is not a package manager. Although use-package
+does have the useful capability to interface with the Emacs package
+manager, its primary purpose is help with the configuration and
+loading of packages, not with managing their download, upgrades, and
+installation.
+
+@insertcopying
+
+@menu
+* Basic Concepts:: Basic concepts of use-package.
+* Getting Started:: A gentle introduction to use-package.
+* Loading Packages:: How and when packages are loaded.
+* Configuring Packages:: Package configuration keywords.
+* Installing packages:: Ensuring packages are available.
+* Byte-compiling:: Byte-compiling your init file.
+* Troubleshooting:: What to do when there's trouble.
+
+Appendices
+* Keyword extensions:: Adding new use-package keywords.
+* History:: History and acknowledgments.
+* GNU Free Documentation License:: The license for this manual.
+
+Index
+* Index::
+@end menu
+@end ifnottex
+
+@c ----------------------------------------------------------------------------
+@node Basic Concepts
+@chapter Basic Concepts
+
+use-package provides the @code{use-package} macro, that simplifies the
+customization and use of packages in Emacs. It was created for a few
+basic reasons, each of which drove the design. Understanding these
+reasons may help make some of those decisions clearer:
+
+@cindex reasons for developing use-package
+@enumerate
+@item
+Allow gathering all the configuration details of a package into one
+place, making it easier to copy, disable, or move it elsewhere in the
+init file.
+
+@item
+Reduce duplication and repetitive boilerplate, capturing several
+common practices as mere keywords both easy and intuitive to use.
+
+@item
+Make startup time of Emacs as short as possible, without sacrificing
+the quantity of add-on packages used.
+
+@item
+Ensure that errors encountered during startup disable only the
+package(s) raising the error(s), and as little else as possible,
+leaving Emacs as close to fully functional as possible.
+
+@item
+Allow byte-compiling your init file, so that any warnings or errors
+you see at startup are meaningful. In this way, even if
+byte-compilation is not used for speed (see item 3 above), it can
+still be used as a sanity check.
+@end enumerate
+
+It is worth noting that use-package is not intended to replace the
+standard customization command @w{@kbd{M-x customize}} (@pxref{Easy
+Customization,,, emacs, GNU Emacs Manual}). On the contrary, it is
+designed to work together with it, for things that Customize cannot
+do.
+
+@c ----------------------------------------------------------------------------
+@node Getting Started
+@chapter Getting Started
+@cindex quick-start instructions
+
+This chapter provides instructions and examples for quickly getting
+started with use-package. In this manual, we say that each call to
+the @code{use-package} macro in your init file is a @dfn{declaration},
+to highlight the declarative nature of its syntax.
+
+To unconditionally load a package named @samp{foo}, add the following
+declaration to your init file:
+
+@lisp
+(use-package foo)
+@end lisp
+
+@noindent
+This declaration is equivalent to using @code{require} (@pxref{Named
+Features,,, elisp, GNU Emacs Lisp Reference Manual}), with some
+use-package specific error handling added in. Just like
+@code{require}, it needs the package @samp{foo} to be installed and
+available via your @code{load-path} (@pxref{Installing packages}).
+
+To evaluate some Lisp @emph{before} the @samp{foo} package is loaded,
+use the @code{:init} keyword:
+
+@lisp
+@group
+(use-package foo
+ :init
+ (setq foo-variable t))
+@end group
+@end lisp
+
+Similarly, @code{:config} can be used to execute code @emph{after} a
+package is loaded. In cases where loading is done lazily
+(@pxref{Loading Packages}), this execution is deferred until after the
+loading actually occurs. As you might expect, you can use
+@code{:init} and @code{:config} together:
+
+@lisp
+@group
+(use-package foo
+ :init
+ (setq foo-variable t)
+ :config
+ (foo-mode 1))
+@end group
+@end lisp
+
+The above declarations will load the @samp{foo} package immediately. In
+most cases, this is not necessary or desirable, as that will slow down
+Emacs startup. Instead, you should try to set things up so that
+packages are only loaded when they are actually needed (this is known as
+``autoloading''). If you have installed a package from @acronym{GNU}
+@acronym{ELPA} that provides its own autoloads, it is often enough to
+say:
+
+@lisp
+@group
+(use-package foo
+ :defer t)
+@end group
+@end lisp
+
+@noindent
+This will avoid loading the package. Now, when you run any autoloaded
+command, the package @samp{foo} is loaded automatically. (Which
+commands from a package are marked to auto-load by default is the
+decision of the package authors.)
+
+In some cases, you might need or want to provide your own autoloads.
+The more complex example below autoloads the commands
+@code{isearch-moccur} and @code{isearch-all} from the package
+@file{color-moccur.el}, and binds keys both globally and in
+@code{isearch-mode-map}. When one of these two commands are used, the
+package will be loaded. At that point, @code{moccur-edit} is also loaded,
+to allow editing of the @code{moccur} buffer.
+
+@lisp
+@group
+(use-package color-moccur
+ :commands (isearch-moccur isearch-all)
+ :bind (("M-s O" . moccur)
+ :map isearch-mode-map
+ ("M-o" . isearch-moccur)
+ ("M-O" . isearch-moccur-all))
+ :init
+ (setq isearch-lazy-highlight t)
+ :config
+ (use-package moccur-edit))
+@end group
+@end lisp
+
+Some packages will suggest ready-made @code{use-package} declarations
+that you can use. Where possible, it is a good idea to copy them, and
+use that as a starting point.
+
+That should be enough to get you started!
+
+@c ----------------------------------------------------------------------------
+@node Loading Packages
+@chapter Loading Packages
+@cindex loading packages with use-package
+
+Before use-package can load an Emacs Lisp package, it must be
+available in a directory on your @code{load-path}. When you install
+packages using the built-in @code{install-package} command, it will do
+this automatically for you. Packages shipped with Emacs (built-in
+packages) are always available.
+
+Some packages have more than one library. In those cases, you might
+need more than one @code{use-package} declaration to make sure the
+package is properly loaded. For complex configurations, you might
+also need more than one declaration for a package with the same name.
+
+use-package can interface with @samp{package.el} to install packages
+on Emacs start. @xref{Installing packages}, for details.
+
+@menu
+* Loading basics:: How and when packages are loaded.
+* Deferring loading:: Loading packages later.
+* Forcing loading:: Loading packages immediately.
+* Conditional loading:: Loading packages conditionally.
+* Loading sequentially:: Loading packages in sequence.
+* The @code{emacs} package:: Customizing built-in variables.
+* Load dependencies:: Don't load without dependencies.
+* Manual installation:: Loading manually installed packages.
+@end menu
+
+@node Loading basics
+@section How and when use-package loads packages
+
+The call to the @code{use-package} macro will load a package either
+immediately, or when the package is first used (via autoloading). In the
+simplest case, a @code{use-package} declaration loads a package when
+it is evaluated.@footnote{This happens both at run-time and at
+compile-time. @xref{Byte-compiling}.} If the declaration is in your
+init file, this happens automatically each time Emacs is started.
+
+For example, the declaration below immediately loads the library
+@code{foo}, just like @code{require} would:
+
+@lisp
+(use-package foo)
+@end lisp
+
+@noindent
+If the library @samp{foo} is not available in your @code{load-path},
+the declaration logs a warning to the @samp{*Messages*} buffer.
+
+@cindex package vs library
+@c So, confusingly, (use-package foo) actually means to use the
+@c _library_ foo.el, not all of the _package_ foo's libraries?
+@c Should this be explicitly explained here?
+Note that a ``package'' is different from an Emacs Lisp ``library''.
+The above declaration tells use-package to load the @emph{library}
+@file{foo.el}, which in the overwhelming majority of cases also
+resides in a @emph{package} named @code{foo}. But the package
+@code{foo} might also contain a library named @file{foo-extra.el}. If
+that library is not loaded automatically, you will need a separate
+@code{use-package} declaration to make sure that it is loaded when
+needed. This manual will often use the terms ``package'' and
+``library'' interchangeably, as this distinction does not usually
+matter, but you should keep it in mind for the cases when it does.
+
+The details of how and when you should load a package might differ
+from one package to another. When in doubt, refer to the package
+documentation for details.
+
+@node Deferring loading
+@section Deferring package loading
+@cindex deferring loading of package
+
+@cindex autoloading packages
+@cindex loading lazily
+@cindex lazy loading of packages
+In the examples we have seen so far, use-package loads packages every
+time you start Emacs, even if that package is never used. That will
+make starting Emacs slower. use-package therefore allows setting
+things up in such a way that packages are only loaded when some of the
+package's commands is first used (either with @kbd{M-x} or via some key
+binding). This is based on autoloading, a full description of which
+is outside the scope of this manual. @xref{Autoload,,, elisp, GNU
+Emacs Lisp Reference Manual}, for the full story.
+
+@cindex triggers, for loading packages
+Some @code{use-package} keywords provide autoload @dfn{triggers} that
+cause a package to be loaded when certain events occur. For example,
+the @code{:hook} keyword sets up a trigger that fires when the
+specified hook is run, and then loads the package automatically. The
+other trigger keywords, all of which are described later in this
+manual, are @code{:commands}, @code{:bind}, @code{:bind*},
+@code{:bind-keymap}, @code{:bind-keymap*}, @code{:mode}, and
+@code{:interpreter}.
+
+@subheading The @code{:defer} keyword
+
+@findex :defer
+If you did not specify any autoloading keyword, use-package will fall
+back to loading the package immediately (typically when Emacs is
+starting up). This can be overridden using the @code{:defer} keyword.
+It takes one boolean argument: a non-@code{nil} value means to stop
+this package from being immediately loaded. Here is an example of
+using @code{:defer} to postpone loading the package @samp{foo}:
+
+@lisp
+@group
+(use-package foo
+ :defer t)
+@end group
+@end lisp
+
+Using @code{:defer t} by itself like this is rarely useful.
+Typically, you would only use it together with a keyword like
+@code{:config} (@pxref{Lisp Configuration}), or @code{:ensure}
+(@pxref{Installing packages}).
+
+@subheading Defer loading until idle for N seconds
+
+@findex :defer@r{, with a numeric argument}
+You can also give a numeric argument @var{n} to @w{@code{:defer}} to
+specify that a package should be loaded (if it hasn't already) after
+Emacs has been idle for @var{n} seconds. For example, use the
+following to make use-package load @samp{foo} after 30 seconds of idle
+time:
+
+@lisp
+@group
+(use-package foo
+ :defer 30)
+@end group
+@end lisp
+
+@subheading When to use @code{:defer}
+
+When using autoloading keywords, there is no need to also use
+@code{:defer}. It doesn't hurt to add it in this case, perhaps for
+extra clarity, but it is redundant.
+
+You should use @code{:defer} to force deferred loading, in cases when
+use-package isn't creating any autoloads for you. For example, you
+might know that some other package will already do something to cause
+your package to load at the appropriate time. This is usually the
+case when you install a package using @code{package-install}, as
+packages installed in this way normally always have their own
+autoloads already set up.
+
+@subheading Making @w{@code{:defer t}} the default
+
+@cindex defer loading by default
+@cindex lazy loading by default
+@vindex use-package-always-defer
+If you customize the user option @code{use-package-always-defer} to
+non-@code{nil}, the @code{use-package} macro will behave as if
+@w{@code{:defer t}} is always specified. This can be overridden for
+individual declarations using either @w{@code{:defer nil}} or
+@w{@code{:demand t}} (@pxref{Forcing loading}).
+
+@node Forcing loading
+@section Forcing package to load immediately
+@cindex forcing immediate loading
+
+@findex :demand
+The presence of autoloading trigger keywords can be overridden using
+@code{:demand t}, which forces the package to load immediately. Thus,
+even if you use an autoloading keyword such as @code{:bind}
+(@pxref{Key bindings}), adding @code{:demand} will force loading to
+occur immediately. It will also avoid creating an autoload for the
+bound key, as it would be redundant.
+
+If you specify both @w{@code{:demand t}} and @w{@code{:defer t}}, the
+@code{:defer} keyword will take precedence.
+
+@node Conditional loading
+@section Loading packages conditionally
+@cindex conditional loading
+@cindex loading conditions
+
+@findex :if
+@findex :when
+@findex :unless
+The @code{:if}, @code{:when}, and @code{:unless} keywords predicates
+the loading and initialization of packages. They all accept one
+argument, an Emacs Lisp form that is evaluated at run-time.
+
+If the argument of the @code{:if} keyword evaluates to non-@code{nil},
+the package will be loaded and initialized. The @code{:when} keyword
+is provided as an alias for @code{:if}. Finally, the @code{:unless}
+keyword is the inverse of @code{:if}, such that @w{@code{:unless foo}}
+means the same thing as @w{@code{:if (not foo)}}.
+
+For example, if you only want to load @samp{foo} in graphical Emacs
+sessions, you could use the following:
+
+@lisp
+@group
+(use-package foo
+ :if (display-graphic-p))
+@end group
+@end lisp
+
+@subheading Some common use cases
+
+Here are some common cases for conditional loading, and how to achieve
+them.
+
+@c FIXME: Too many redundant examples? E.g., why do we need both an
+@c example for system-type and window-system? or both of the last 2
+@c examples?
+@itemize
+
+@item
+Operating system
+
+The following example loads a package only on GNU/Linux. See the
+docstring of @code{system-type} for other valid values.
+
+@lisp
+:if (eq system-type 'gnu/linux)
+@end lisp
+
+@item
+Window system
+
+The example below loads a package only on macOS and X@. See the
+docstring of @code{window-system} for valid values.
+
+@lisp
+:if (memq window-system '(ns x))
+@end lisp
+
+@item
+Installed package
+
+The following example loads a package only when the @samp{foo} package
+is installed.
+
+@lisp
+:if (package-installed-p 'foo)
+@end lisp
+
+@item
+Libraries in @code{load-path}
+
+The example below loads a package only when @file{foo.el} is available
+in your @code{load-path} (for example, if you installed that file
+manually):
+
+@lisp
+:if (locate-library "foo.el")
+@end lisp
+@end itemize
+
+@subheading Making conditional loading affect @code{:preface} and @code{:ensure}
+
+@cindex conditional loading before @code{:preface} or @code{:ensure}
+If you need to make a use-package form conditional so that the condition
+occurs before even @code{:ensure} (@pxref{Install package}) or
+@code{:preface} (@pxref{Preface keyword}), use @code{when}
+around the @code{use-package} form itself. For example:
+
+@lisp
+@group
+(when (memq window-system '(mac ns))
+ (use-package foo
+ :ensure t))
+@end group
+@end lisp
+
+@node Loading sequentially
+@section Loading packages in sequence
+@cindex loading a package after other packages
+
+@findex :after
+Sometimes it only makes sense to configure a package after another one
+has been loaded, because certain variables or functions are not in
+scope until that time. This can be achieved with the @code{:after}
+keyword, which allows a fairly rich description of the exact
+conditions when loading should occur. The @code{:after} keyword takes
+as argument either a symbol indicating the package name, a list of
+such symbols, or a list of selectors (see below).
+
+Here is an example of using the @acronym{GNU} @acronym{ELPA} packages
+@file{hydra}, @file{ivy}, and @file{ivy-hydra}. Note that
+@file{ivy-hydra} will always be loaded last:
+
+@lisp
+(use-package hydra)
+
+(use-package ivy)
+
+@group
+(use-package ivy-hydra
+ :after (ivy hydra))
+@end group
+@end lisp
+
+In this case, because the declarations are evaluated in the order they
+occur, the use of @code{:after} is not strictly necessary. However,
+if @samp{hydra} and @samp{ivy} were to be autoloaded, using
+@code{:after} guarantees that @samp{ivy-hydra} is not loaded until it
+is actually needed. By using @code{:after}, the above code will also
+work even if the order of the declaration changes. This means that
+moving things around in your init file is less likely to break things.
+
+@subheading Using @code{:after} selectors
+
+@findex :all@r{, (with @code{:after})}
+@findex :any@r{, (with @code{:after})}
+@cindex list of selectors, for @code{:after}
+The @code{:after} keyword also accepts a list of selectors. By
+default, @w{@code{:after (foo bar)}} is the same as @w{@code{:after
+(:all foo bar)}}, meaning that loading of the given package will not happen
+until both @code{foo} and @code{bar} have been loaded. Here are some
+of the other possibilities:
+
+@verbatim
+:after (foo bar)
+:after (:all foo bar)
+:after (:any foo bar)
+:after (:all (:any foo bar) (:any baz quux))
+:after (:any (:all foo bar) (:all baz quux))
+@end verbatim
+
+When you nest selectors, such as in @w{@code{(:any (:all foo bar)
+(:all baz quux))}}, it means that the package will be loaded when
+either both @code{foo} and @code{bar} have been loaded, or when both
+@code{baz} and @code{quux} have been loaded.
+
+@cindex @code{use-package-always-defer}, with @code{:after}
+Pay attention when setting @code{use-package-always-defer} to a
+non-@code{nil} value, and also using the @code{:after} keyword. In
+that case, you will need to specify how the declared package is to be
+loaded: for example, by some @code{:bind} (@pxref{Global
+keybindings}). If you are not using one of the keywords that
+registers autoloads, such as @code{:bind} or @code{:hook}
+(@pxref{Hooks}), and your package manager does not provide autoloads,
+it is possible that your package will never be loaded if you do not
+add @code{:demand t} to those declarations.
+
+@node The @code{emacs} package
+@section Customizing built-in variables
+@cindex customizing built-in variables
+
+Some users want to put all their customizations in use-package
+declarations, even for variables, hooks, and options that are always
+available, without loading any package.@footnote{In other words, they
+are either preloaded in Emacs or defined in Emacs's C sources.}
+
+For that purpose, you can use the no-op @samp{emacs} package:
+
+@lisp
+@group
+(use-package emacs
+ :init
+ (setq custom-file "~/.emacs.d/emacs-custom.el")
+ (load custom-file)
+ (setq frame-title-format "%b")
+ :custom
+ (use-short-answers t))
+@end group
+@end lisp
+
+This declaration takes advantage of the fact that @w{@code{(featurep
+'emacs)}} always returns true, and has no special meaning beyond that.
+It simply provides a way to organize your customizations, without
+loading anything.
+
+@node Load dependencies
+@section Prevent loading if dependencies are missing
+@cindex prevent loading package if dependencies are missing
+
+@findex :requires
+While the @code{:after} keyword delays loading until the dependencies
+are loaded, the somewhat simpler @code{:requires} keyword @emph{never}
+loads the package if the dependencies are not available when the
+@code{use-package} declaration is evaluated. In this context,
+``available'' means that @code{foo} is available if @w{@code{(featurep
+'foo)}} evaluates to a non-@code{nil} value. For example:
+
+@lisp
+@group
+(use-package abbrev
+ :requires foo)
+@end group
+@end lisp
+
+@noindent
+This is the same as:
+
+@lisp
+@group
+(use-package abbrev
+ :if (featurep 'foo))
+@end group
+@end lisp
+
+As a convenience, a list of such packages may be specified:
+
+@lisp
+@group
+(use-package abbrev
+ :requires (foo bar baz))
+@end group
+@end lisp
+
+For more complex logic, such as that supported by @code{:after},
+simply use @code{:if} and the appropriate Lisp expression.
+
+@node Manual installation
+@section Manually installed package
+
+When installing packages manually, without Emacs's built-in package
+manager (@file{package.el}), it will obviously not help you set up
+autoloads or add it to your @code{load-path}. You must do it
+yourself. However, use-package makes this more convenient.
+
+@menu
+* Load path:: Using a custom @code{load-path}.
+* Manual autoloads:: Setting up autoloads manually.
+@end menu
+
+@node Load path
+@subsection Setting a custom @code{load-path}
+@cindex custom @code{load-path} for loading a package
+@cindex @code{load-path}, add directories for loading a package
+
+When installing packages manually, you must make sure its libraries
+are available on your @code{load-path}. @xref{Lisp Libraries,,,
+emacs, GNU Emacs Manual}, for more details about package loading.
+
+@findex :load-path
+The @code{:load-path} keyword provides a convenient way to add
+directories to your load path. It takes as argument a symbol, a
+function, a string or a list of strings. If a directory is specified
+as a relative file name, it is expanded relative to
+@code{user-emacs-directory}.
+
+For example:
+
+@lisp
+@group
+(use-package org
+ :load-path "site-lisp/org/lisp/"
+ :commands org-mode)
+@end group
+@end lisp
+
+When using a symbol or a function to provide a dynamically generated
+list of directories, you must inform the byte-compiler of this
+definition, so that the value is available at byte-compilation time.
+This is done by using the special form @code{eval-and-compile} (as
+opposed to @code{eval-when-compile}, @pxref{Eval During Compile,,,
+elisp, GNU Emacs Lisp Reference Manual}). Furthermore, this value is
+fixed to the value it had during compilation. If the operation is
+costly, you do not have to repeat it again on each startup. For
+example:
+
+@lisp
+@group
+(eval-and-compile
+ (defun ess-site-load-path ()
+ (shell-command-to-string "find ~ -path ess/lisp")))
+@end group
+
+@group
+(use-package ess-site
+ :load-path (lambda () (list (ess-site-load-path)))
+ :commands R)
+@end group
+@end lisp
+
+@node Manual autoloads
+@subsection Setting up autoloads manually
+
+Packages often document how to set up its autoloads when it is being
+manually installed. If it does, follow those instructions.
+Otherwise, you might want to set them up manually.
+
+@cindex autoloads for packages, setting up manually
+@cindex package autoloads, setting up manually
+
+@findex :commands
+@findex :autoload
+To autoload an interactive command, use the @code{:commands} keyword,
+which takes either a symbol or a list of symbols as its argument. It
+creates autoloads for those commands (which defers loading of the
+module until those commands are used).
+
+The @code{:autoload} keyword takes the same arguments as
+@code{:commands}, but is used to autoload non-interactive functions.
+Here is an example:
+
+@lisp
+@group
+(use-package org-crypt
+ :autoload org-crypt-use-before-save-magic)
+@end group
+@end lisp
+
+@c ----------------------------------------------------------------------------
+@node Configuring Packages
+@chapter Configuring Packages
+@cindex configure packages using @code{use-package}
+@cindex customize package configuration
+
+This chapter describes the various keywords provided by
+@code{use-package} that help you configure packages.
+
+@menu
+* Lisp Configuration:: Using Lisp to configure packages.
+* Key bindings:: Making your own keybindings.
+* Hooks:: Adding functions to hooks.
+* Modes and interpreters:: Enabling modes automatically.
+* Magic handlers:: Using regexps to enable modes.
+* User options:: Setting user options.
+* Faces:: Customizing faces.
+* Hiding minor modes:: Tidying up the mode line.
+@end menu
+
+@node Lisp Configuration
+@section Using Lisp code for configuring packages
+@cindex configure package using Lisp forms
+
+The most general way to add customizations are the @code{:preface},
+@code{:init}, and @code{:config} keywords. They all accept one or
+more Emacs Lisp forms, up to the next keyword, that are evaluated in
+order. This lets you add arbitrary Lisp code to your
+@code{use-package} declarations.
+
+The only difference between these keywords is when they are evaluated.
+
+@menu
+* Preface keyword:: Evaluate code before anything else.
+* Init keyword:: Evaluate code before loading package.
+* Config keyword:: Evaluate code after loading package.
+* Best practices:: When to use @code{:config}, @code{:init}, and @code{:preface}.
+@end menu
+
+@node Preface keyword
+@subsection @code{:preface} is evaluated first
+
+@findex :preface
+The @code{:preface} section is evaluated before anything else, except
+@code{:disabled} and @code{:ensure}. It can be used to establish
+function and variable definitions that will:
+
+@enumerate
+@item
+Make the byte-compiler happy: it will not complain about functions
+whose definitions are unknown.
+
+@item
+Define functions and variables that will be used in an @code{:if}
+test.
+@end enumerate
+
+Note that whatever is specified within @code{:preface} is evaluated
+both at load time and at byte-compilation time, in order to ensure
+that definitions are seen by both the Lisp evaluator and the
+byte-compiler. Therefore, you should avoid having any side-effects in
+your @code{:preface} forms, and restrict them to symbol declarations
+and definitions.
+
+@node Init keyword
+@subsection @code{:init} is evaluated before loading package
+
+@findex :init
+The @code{:init} section is evaluated just before the package is
+loaded. Note that the @code{:init} form is run unconditionally --
+even if the package happens to not exist on your system. You must
+therefore remember to restrict @code{:init} code to what would succeed
+either way; put the rest in the @code{:config} section. @code{:init}
+also always happens before package load, whether @code{:config} has
+been deferred or not.
+
+@node Config keyword
+@subsection @code{:config} is evaluated after loading package
+
+@findex :config
+The @code{:config} section is evaluated after the package has been
+loaded. If the package is loaded immediately, this happens
+immediately after that, but if loading is done lazily (@pxref{Loading
+Packages}), this is deferred until after the package has been loaded.
+
+In general, you should keep @code{:init} forms as simple and quick as
+possible, and put as much as you can get away with into the
+@code{:config} section. That way, deferred loading can help your
+Emacs start as quickly as possible.
+
+@node Best practices
+@subsection When to use @code{:preface}, @code{:config} and @code{:init}?
+@cindex tips for using @code{:preface}, @code{:config}, @code{:init}
+
+Where possible, it is better to avoid @code{:preface}, @code{:config}
+and @code{:init}. Instead, prefer autoloading keywords such as
+@code{:bind} (@pxref{Key bindings}), @code{:hook} (@pxref{Hooks}), and
+@code{:mode} (@pxref{Modes and interpreters}), as they will take care
+of setting up autoloads for you without any need for boilerplate code.
+For example, consider the following declaration:
+
+@lisp
+@group
+(use-package foo
+ :init
+ (add-hook 'some-hook 'foo-mode))
+@end group
+@end lisp
+
+@noindent
+This has two problems. First, it will unconditionally load the
+package @samp{foo} on startup, which will make things slower. You can
+fix this by adding @w{@code{:defer t}}:
+
+@lisp
+@group
+(use-package foo
+ :defer t
+ :init
+ (add-hook 'some-hook 'foo-mode))
+@end group
+@end lisp
+
+@noindent
+This is better, as @samp{foo} is now only loaded when it is actually
+needed (that is, when the hook @samp{some-hook} is run).
+
+The second problem is that there is a lot of boilerplate that you have
+to write. In this case, it might not be so bad, but avoiding that was
+what use-package was made to allow. The better option in this case is
+therefore to use @code{:hook} (@pxref{Hooks}), which also implies
+@w{@code{:defer t}}. The above is thereby reduced down to:
+
+@lisp
+@group
+(use-package foo
+ :hook some-hook)
+@end group
+@end lisp
+
+Now use-package will set up autoloading for you, and your Emacs
+startup time will not suffer one bit.
+
+@node Key bindings
+@section Key bindings
+
+@cindex binding keys for package commands
+@cindex key bindings for package commands
+One common thing to do when loading a package is to bind keys to
+commands within that module. Without use-package, this would be done
+using a combination of @code{keymap-local-set},
+@code{keymap-global-set} and various autoloads. With use-package, you
+can simplify this using the @code{:bind} keyword, as described in this
+section.
+
+@menu
+* Global keybindings:: Bindings you can use anywhere.
+* Binding in keymaps:: Bindings for particular modes.
+* Binding to a keymap:: Binding a key to a keymap.
+* Binding to repeat-maps:: Binding repeating keys.
+* Displaying keybindings:: Displaying personal key bindings.
+@end menu
+
+@node Global keybindings
+@subsection Global keybindings
+@cindex global keybindings
+
+@findex :bind
+To bind keys globally, the @code{:bind} keyword takes as its argument
+either a single cons or a list of conses. Each cons has the form
+@w{@code{(@var{key} . @var{command})}}, where @var{key} is a string
+indicating the key to bind, and @var{command} is the name of a command
+(a symbol). The syntax for the keys is similar to the syntax used by
+the @code{kbd} function (see @ref{Init Rebinding,,, emacs, GNU Emacs
+Manual}, for more information).
+
+@subheading Using @code{:bind} with a single cons
+
+Here is an example of using a single cons:
+
+@lisp
+@group
+(use-package ace-jump-mode
+ :bind ("C-." . ace-jump-mode))
+@end group
+@end lisp
+
+@noindent
+This does two things: first, it creates an autoload for the
+@code{ace-jump-mode} command and defers loading of the
+@code{ace-jump-mode} package until you actually use it. Second, it
+binds the key @code{C-.} to that command globally.
+
+@subheading Using @code{:bind} with a list of conses
+
+Here is an example of using @code{:bind} with a list of conses:
+
+@lisp
+@group
+(use-package hi-lock
+ :bind (("M-o l" . highlight-lines-matching-regexp)
+ ("M-o r" . highlight-regexp)
+ ("M-o w" . highlight-phrase)))
+@end group
+@end lisp
+
+@noindent
+This binds the three key sequences to the corresponding commands.
+
+@subheading Using special keys
+@cindex binding function keys with @code{:bind}
+@cindex @code{:bind}, and function keys
+
+@c FIXME: TAB vs [tab] -- is letter-case important? In general, these
+@c are two different keys: one is an ASCII character, the other a
+@c function key on GUI frames.
+Inside key strings, special keys like @kbd{TAB} or @kbd{F1}--@kbd{F12}
+have to be written inside angle brackets, e.g., @code{"C-<up>"}.
+@c FIXME: ``Some combinations''? which ones?
+Standalone special keys (and some combinations) can be written in
+square brackets, e.g.@ @code{[tab]} instead of @code{"<tab>"}.
+
+Examples:
+
+@lisp
+@group
+(use-package helm
+ :bind (("M-x" . helm-M-x)
+ ("M-<f5>" . helm-find-files)
+ ([f10] . helm-buffers-list)
+ ([S-f10] . helm-recentf)))
+@end group
+@end lisp
+
+@subheading Remapping commands
+@cindex remapping commands with @code{:bind}
+@cindex @code{:bind}, and remapping of commands
+
+Remapping of commands with @code{:bind} and @code{bind-key} works as
+expected, because when the binding is a vector, it is passed straight
+to @code{define-key}. @xref{Remapping Commands,,, elisp, GNU Emacs
+Lisp Reference Manual}, for more information about command remapping.
+For example, the following declaration will rebind
+@code{fill-paragraph} (bound to @kbd{M-q} by default) to
+@code{unfill-toggle}:
+
+@lisp
+@group
+(use-package unfill
+ :bind ([remap fill-paragraph] . unfill-toggle))
+@end group
+@end lisp
+
+@c FIXME: Should the below be an Appendix?
+@subheading What @code{:bind} does behind the scenes
+@cindex @code{:bind}, internals
+
+To understand what @code{:bind} does behind the scenes, it might be
+useful to consider an example:
+
+@lisp
+@group
+(use-package ace-jump-mode
+ :bind ("C-." . ace-jump-mode))
+@end group
+@end lisp
+
+@noindent
+This could be expressed in a much more verbose way with the
+@code{:commands} and @code{:init} keywords:
+
+@lisp
+@group
+(use-package ace-jump-mode
+ :commands ace-jump-mode
+ :init
+ (bind-key "C-." 'ace-jump-mode))
+@end group
+@end lisp
+
+@noindent
+Without using even the @code{:commands} keyword, we could also write
+the above like so:
+
+@lisp
+@group
+(use-package ace-jump-mode
+ :defer t
+ :init
+ (autoload 'ace-jump-mode "ace-jump-mode" nil t)
+ (bind-key "C-." 'ace-jump-mode))
+@end group
+@end lisp
+
+Although these three forms are all equivalent, the first form is
+usually the best, as it will save some typing.
+
+@node Binding in keymaps
+@subsection Key bindings in local keymaps
+@cindex local keybindings
+
+@findex :map@r{, inside} :bind
+Slightly different from binding a key to a keymap, is binding a key
+@emph{within} a local keymap that only exists after the package is
+loaded. @code{use-package} supports this with a @code{:map} modifier,
+taking the local keymap to bind to:
+
+@lisp
+@group
+(use-package helm
+ :bind (:map helm-command-map
+ ("C-c h" . helm-execute-persistent-action)))
+@end group
+@end lisp
+
+@noindent
+The effect of this is to wait until @code{helm} has loaded, and then
+to bind the key sequence @kbd{C-c h} to
+@code{helm-execute-persistent-action} within Helm's local keymap,
+@code{helm-command-map}.
+
+Multiple uses of @code{:map} may be specified. Any binding occurring
+before the first use of @code{:map} are applied to the global keymap:
+
+@lisp
+@group
+(use-package term
+ :bind (("C-c t" . term)
+ :map term-mode-map
+ ("M-p" . term-send-up)
+ ("M-n" . term-send-down)
+ :map term-raw-map
+ ("M-o" . other-window)
+ ("M-p" . term-send-up)
+ ("M-n" . term-send-down)))
+@end group
+@end lisp
+
+@node Binding to a keymap
+@subsection Binding to keymaps
+@cindex binding keys to keymaps
+
+@findex :bind-keymap
+Normally @code{:bind} expects that commands are functions that will be
+autoloaded from the given package. However, this does not work if one of
+those commands is actually a keymap, since keymaps are not functions,
+and cannot be autoloaded using the built-in @code{autoload} function.
+
+To handle this case, @code{use-package} offers a special, limited
+variant of @code{:bind} called @code{:bind-keymap}. The only difference
+is that the ``commands'' bound to by @code{:bind-keymap} must be keymaps
+defined in the package, rather than interactive functions. This is handled
+behind the scenes by generating custom code that loads the package
+containing the keymap, and then re-executes your keypress after the
+first load, to reinterpret that keypress as a prefix key.
+
+For example:
+
+@lisp
+@group
+(use-package foo
+ :bind-keymap ("C-c p" . foo-command-map))
+@end group
+@end lisp
+
+@node Binding to repeat-maps
+@subsection Binding to repeat-maps
+@cindex keybinding for @code{repeat-mode} keymaps
+
+@findex :repeat-map@r{, inside} :bind
+@cindex @code{repeat-mode} and use-package, using
+A special case of binding within a local keymap is when that keymap is
+used by @code{repeat-mode} (@pxref{Repeating,,, emacs, GNU Emacs
+Manual}). These keymaps are usually defined specifically for
+this. Using the @code{:repeat-map} keyword, and passing it a name for
+the map it defines, will bind all the following keys inside that map, and
+(by default) set the @code{repeat-map} property of each bound command
+to that map.
+
+The following example creates a keymap called
+@code{git-gutter+-repeat-map}, makes four bindings in it, then sets
+the @code{repeat-map} property of each bound command
+(@code{git-gutter+-next-hunk}, @code{git-gutter+-previous-hunk},
+@code{git-gutter+-stage-hunks}, and @code{git-gutter+-revert-hunk}) to
+that keymap.
+
+@lisp
+@group
+(use-package git-gutter+
+ :bind
+ (:repeat-map git-gutter+-repeat-map
+ ("n" . git-gutter+-next-hunk)
+ ("p" . git-gutter+-previous-hunk)
+ ("s" . git-gutter+-stage-hunks)
+ ("r" . git-gutter+-revert-hunk)))
+@end group
+@end lisp
+
+@findex :exit@r{, inside} :repeat-map@r{ and} :bind
+@cindex binding commands used at end of repeat series
+Specifying @code{:exit} inside the scope of @code{:repeat-map} will
+prevent the @code{repeat-map} property from being set, so that the command
+can be used from within the repeat map, but after using it the repeat
+map will no longer be available. This is useful for commands often used
+at the end of a series of repeated commands. Example:
+
+@lisp
+@group
+(use-package git-gutter+
+ :bind
+ (:repeat-map my/git-gutter+-repeat-map
+ ("n" . git-gutter+-next-hunk)
+ ("p" . git-gutter+-previous-hunk)
+ ("s" . git-gutter+-stage-hunks)
+ ("r" . git-gutter+-revert-hunk)
+ :exit
+ ("c" . magit-commit-create)
+ ("C" . magit-commit)
+ ("b" . magit-blame)))
+@end group
+@end lisp
+
+@findex :continue@r{, inside} :repeat-map@r{ and} :bind
+Specifying @code{:continue} @emph{forces} setting the
+@code{repeat-map} property (just like @emph{not} specifying
+@code{:exit}), so the above snippet is equivalent to:
+
+@lisp
+@group
+(use-package git-gutter+
+ :bind
+ (:repeat-map my/git-gutter+-repeat-map
+ :exit
+ ("c" . magit-commit-create)
+ ("C" . magit-commit)
+ ("b" . magit-blame)
+ :continue
+ ("n" . git-gutter+-next-hunk)
+ ("p" . git-gutter+-previous-hunk)
+ ("s" . git-gutter+-stage-hunks)
+ ("r" . git-gutter+-revert-hunk)))
+@end group
+@end lisp
+
+@node Displaying keybindings
+@subsection Displaying personal keybindings
+@cindex display your keybindings
+
+@findex describe-personal-keybindings
+The @code{:bind} keyword uses the @code{bind-keys} macro from the
+@samp{bind-key.el} library to set up keybindings. It keeps track of
+all keybindings you make, so that you can display them separately from
+the default keybindings.
+
+Use @w{@kbd{M-x describe-personal-keybindings}} to see all
+keybindings you've set using either the @code{:bind} keyword or the
+@code{bind-keys} macro.
+
+@node Hooks
+@section Hooks
+
+@cindex hooks
+@findex :hook
+The @code{:hook} keyword allows adding functions to hooks. It takes
+@c FIXME: The actual forms accepted by :hook are different, see below!
+one argument of the form @var{hooks}, specifying one or more functions
+to add to one or more hooks. For the purposes of @code{:hook}, the
+name of hook variables should always exclude the @samp{-hook} suffix.
+It is appended automatically for you, to save some typing.
+
+For example, consider the following @code{use-package} declaration
+that sets up autoloads for @code{company-mode} from the @samp{company}
+package, and adds @samp{company-mode} to @code{prog-mode-hook}:
+
+@lisp
+@group
+(use-package company
+ :commands company-mode
+ :init
+ (add-hook 'prog-mode-hook #'company-mode))
+@end group
+@end lisp
+
+Using @code{:hook}, this can be simplified to:
+
+@lisp
+@group
+(use-package company
+ :hook (prog-mode . company-mode))
+@end group
+@end lisp
+
+Here, @code{:hook} will automatically set up autoloads for the
+@code{company-mode} command, so there is no need to use
+@code{:commands}.
+
+The @code{:hook} keyword will also assume that the name of the
+function you want to add is the same as the package name with
+@samp{-mode} appended to it. Taking this into account, you can
+simplify the above to the equivalent:
+
+@lisp
+@group
+(use-package company
+ :hook prog-mode)
+@end group
+@end lisp
+
+@cindex multiple hooks
+You can also provide a list of hooks. When multiple hooks should be
+applied, the following examples are all equivalent:
+
+@lisp
+@group
+(use-package company
+ :hook (prog-mode text-mode))
+@end group
+
+@group
+(use-package company
+ :hook ((prog-mode text-mode) . company-mode))
+@end group
+
+@group
+(use-package company
+ :hook ((prog-mode . company-mode)
+ (text-mode . company-mode)))
+@end group
+
+@group
+(use-package company
+ :commands company-mode
+ :init
+ (add-hook 'prog-mode-hook #'company-mode)
+ (add-hook 'text-mode-hook #'company-mode))
+@end group
+@end lisp
+
+One common mistake when using @code{:hook} is to forget to omit the
+@samp{-hook} suffix, which, as already explained, is appended
+automatically. Therefore, the following will not work, as it attempts
+to add a function to non-existent @code{prog-mode-hook-hook}:
+
+@lisp
+@group
+;; DOES NOT WORK
+(use-package ace-jump-mode
+ :hook (prog-mode-hook . ace-jump-mode))
+@end group
+@end lisp
+
+@vindex use-package-hook-name-suffix
+If you do not like this behavior, you can customize the user option
+@code{use-package-hook-name-suffix} to @code{nil}. The value of this
+variable is @samp{"-hook"} by default.
+
+The use of @code{:hook}, as with @code{:bind}, @code{:mode},
+@code{:interpreter}, etc., causes the functions being hooked to
+implicitly be read as @code{:commands}. This means that they will
+establish interactive @code{autoload} definitions for that module, if
+not already defined as functions), and so @code{:defer t} is also
+implied by @code{:hook}.
+
+@node Modes and interpreters
+@section Modes and interpreters
+@cindex @code{auto-mode-alist} customization
+@cindex @code{interpreter-mode-alist} customization
+@cindex setting up major modes
+
+@findex :mode
+@findex :interpreter
+Similar to @code{:bind}, you can use @code{:mode} and
+@code{:interpreter} to establish a deferred binding within the
+@code{auto-mode-alist} and @code{interpreter-mode-alist} variables
+(@pxref{Auto Major Mode,,, elisp, GNU Emacs Lisp Reference Manual}).
+The specifier to either keyword can be a cons cell, a list of cons
+cells, or a string or regexp.
+
+The following example reproduces the default @code{ruby-mode}
+configuration, exactly as it is in Emacs out-of-the-box. That mode is
+enabled automatically when a file whose name matches the regexp
+@code{"\\.rb\\'"} (a file with the @file{.rb} extension), or when the
+first line of the file (known as the ``shebang'') matches the string
+@code{"ruby"}:
+
+@lisp
+@group
+(use-package ruby-mode
+ :mode "\\.rb\\'"
+ :interpreter "ruby")
+@end group
+@end lisp
+
+The default @code{python-mode} configuration can be reproduced using
+the declaration below. Note that the package that should be loaded
+differs from the mode name in this case, so we must use a cons:
+
+@lisp
+@group
+;; The package is "python" but the mode is "python-mode":
+(use-package python
+ :mode ("\\.py\\'" . python-mode)
+ :interpreter ("python" . python-mode))
+@end group
+@end lisp
+
+Both the @code{:mode} and @code{:interpreter} keywords also accept a
+list of regexps:
+
+@lisp
+@group
+(use-package foo
+ ;; Equivalent to "\\(ba[rz]\\)\\'":
+ :mode ("\\.bar\\'" "\\.baz\\'")
+ ;; Equivalent to "\\(foo[ab]\\)":
+ :interpreter ("fooa" "foob"))
+@end group
+@end lisp
+
+@node Magic handlers
+@section Magic handlers
+@cindex @code{magic-mode-alist} customization
+
+@findex :magic
+@findex :magic-fallback
+Similar to @code{:mode} and @code{:interpreter}, you can also use
+@code{:magic} and @code{:magic-fallback} to cause certain function to
+be run if the beginning of a file matches a given regular expression,
+as if these regular expressions were added to @code{magic-mode-alist}
+and @code{magic-fallback-mode-alist} (@pxref{Auto Major Mode,,, elisp,
+GNU Emacs Lisp Reference Manual}). The difference between
+@code{:magic} and @code{:magic-fallback}, is that the latter has a
+lower priority than @code{:mode}.
+
+Here is an example:
+
+@lisp
+@group
+(use-package pdf-tools
+ :magic ("%PDF" . pdf-view-mode)
+ :config
+ (pdf-tools-install :no-query))
+@end group
+@end lisp
+
+This registers an autoloaded command for @code{pdf-view-mode}, defers
+loading of @code{pdf-tools}, and runs @code{pdf-view-mode} if the
+beginning of a buffer matches the string @code{"%PDF"}.
+
+@node User options
+@section User options
+@cindex customization of variables
+@cindex variable customizations
+@cindex user options, setting
+
+@findex :custom
+In Emacs, you normally set customizable variables (user options) using
+the @code{M-x customize} interface (@pxref{Easy Customization,,,
+emacs, GNU Emacs Manual}). We recommend this method for most users.
+However, it is also possible to set them in your @code{use-package}
+declarations by using the @code{:custom} keyword.
+
+@lisp
+@group
+(use-package comint
+ :defer t
+ :custom
+ (comint-buffer-maximum-size 20000 "Increase comint buffer size.")
+ (comint-prompt-read-only t "Make the prompt read only."))
+@end group
+@end lisp
+
+This is better than using @code{setq} in a @code{:config} block, as
+customizable variables might have some code associated with it that
+Emacs will execute when you assign values to them. (In Emacs 29 and
+later, there is also the new @code{setopt} macro that does this for
+you.)
+
+Note that the values customized using @code{:custom} are @emph{not}
+saved in the standard Emacs @code{custom-file} (@pxref{Saving
+Customizations,,, emacs, GNU Emacs Manual}). You should therefore set
+each user option using either the @code{:custom} keyword @emph{or}
+@w{@kbd{M-x customize-option}} command; the latter will save
+customized values in the Emacs @code{custom-file}. Do not use both
+for the same variable, as this risks having conflicting values in your
+use-package declaration and your @code{custom-file}, which can lead to
+problems that are both tricky and tedious to debug.
+
+@node Faces
+@section Faces
+@cindex faces, setting
+@cindex customization of faces
+
+@findex :custom-face
+The @code{:custom-face} keyword allows customization of package's
+faces. Example:
+
+@lisp
+@group
+(use-package eruby-mode
+ :custom-face
+ (eruby-standard-face ((t (:slant italic)))))
+@end group
+
+@group
+(use-package example
+ :custom-face
+ (example-1-face ((t (:foreground "LightPink"))))
+ (example-2-face ((t (:foreground "LightGreen"))) face-defspec-spec))
+@end group
+
+@group
+(use-package zenburn-theme
+ :preface
+ (setq my/zenburn-colors-alist
+ '((fg . "#DCDCCC") (bg . "#1C1C1C") (cyan . "#93E0E3")))
+ :custom-face
+ (region ((t (:background ,(alist-get my/zenburn-colors-alist 'cyan)))))
+ :config
+ (load-theme 'zenburn t))
+@end group
+@end lisp
+
+@node Hiding minor modes
+@section Hiding minor modes with diminish and delight
+@cindex hiding minor modes
+
+@code{use-package} supports the @file{diminish} and @file{delight}
+packages, both of which make it possible to remove or change minor mode
+strings in your mode-line. Which one to use is up to you, but you
+should normally only use one or the other -- never both.@footnote{When
+in doubt, you might as well use @file{diminish}.} To use either of them, you
+must first install the corresponding package from @acronym{GNU} @acronym{ELPA}.
+
+@menu
+* Diminish:: Hiding minor modes with Diminish.
+* Delight:: Hiding minor modes with Delight.
+@end menu
+
+@node Diminish
+@subsection Diminish
+
+@findex :diminish
+When diminish@footnote{The @file{diminish} package is installable from
+@acronym{GNU} @acronym{ELPA}.} is installed, you can use the @code{:diminish}
+keyword. If @file{diminish} is not installed, the @code{:diminish} keyword
+does nothing.
+
+First, add the following declaration to the beginning of your init
+file.
+
+@lisp
+(use-package diminish :ensure t)
+@end lisp
+
+@noindent
+The optional @w{@code{:ensure t}} makes sure the package is installed
+if it isn't already (@pxref{Installing packages}).
+
+The @code{:diminish} keyword takes as its argument either a minor mode
+symbol, a cons of the symbol and its replacement string, or just a
+replacement string, in which case the minor mode symbol is guessed to
+be the package name with @samp{-mode} appended at the end:
+
+@lisp
+@group
+(use-package abbrev
+ :diminish abbrev-mode
+ :config
+ (if (file-exists-p abbrev-file-name)
+ (quietly-read-abbrev-file)))
+@end group
+@end lisp
+
+@node Delight
+@subsection Delight
+
+@findex :delight
+When @file{delight}@footnote{The @file{delight} package is installable from
+@acronym{GNU} @acronym{ELPA}.} is installed, you can use the
+@code{:delight} keyword. If @file{delight} is not installed, the
+@code{:delight} keyword does nothing.
+
+First, add the following declaration to the beginning of your init
+file.
+
+@lisp
+(use-package delight :ensure t)
+@end lisp
+
+@noindent
+The optional @w{@code{:ensure t}} makes sure the package is installed
+if it isn't already (@pxref{Installing packages}).
+
+The @code{:delight} keyword takes as its argument a minor mode symbol,
+a replacement string, or quoted mode line data (in which case the
+minor mode symbol is assumed to be the package name with @samp{-mode}
+appended at the end), both of these, or several lists of both.
+@xref{Mode Line Data,,, elisp, GNU Emacs Lisp Reference Manual}. If
+no arguments are provided, the default mode name is hidden completely.
+
+For example, the following hides everything for the @samp{foo-mode}
+minor mode in the @samp{foo} package:
+
+@lisp
+@group
+(use-package foo
+ :delight)
+@end group
+@end lisp
+
+If the mode name doesn't match the package name with @samp{-mode}
+appended, provide a symbol instead. For example, the following hides
+@code{auto-revert-mode} from the mode line:
+
+@lisp
+@group
+;; Don't show anything for auto-revert-mode, which doesn't match
+;; its package name.
+(use-package autorevert
+ :delight auto-revert-mode)
+@end group
+@end lisp
+
+You can also use arbitrary Lisp code as argument of @code{:delight}.
+For example, to replace @samp{foo-mode} with the value of the current
+buffer:
+
+@lisp
+@group
+(use-package foo
+ :delight '(:eval buffer-file-name))
+@end group
+@end lisp
+
+Here is an example of hiding several built-in minor modes:
+
+@lisp
+@group
+;; Completely hide visual-line-mode and change auto-fill-mode to " AF".
+(use-package emacs
+ :delight
+ (auto-fill-function " AF")
+ (visual-line-mode))
+@end group
+@end lisp
+
+@c ----------------------------------------------------------------------------
+@node Installing packages
+@chapter Installing packages automatically
+
+The standard Emacs package manager is documented in the Emacs manual
+(@pxref{Package Installation,,, emacs, GNU Emacs Manual}). The
+@code{use-package} macro provides the @code{:ensure} and @code{:pin}
+keywords that interface with that package manager to automatically
+install packages. The @code{:vc} keyword may be used to control how
+package sources are downloaded; e.g., from remote hosts
+(@pxref{Fetching Package Sources,,, emacs, GNU Emacs Manual}). This
+is particularly useful if you use your init file on more than one
+system.
+
+@menu
+* Install package::
+* Pinning packages::
+* Other package managers::
+@end menu
+
+@node Install package
+@section Installing package
+@cindex installing packages from archives
+
+@findex :ensure
+The @code{:ensure} keyword makes use-package ask the Emacs package
+manager to install a package if it is not already present on your
+system.
+
+For example:
+
+@lisp
+@group
+(use-package magit
+ :ensure t)
+@end group
+@end lisp
+
+If you need to install a different package from the one named by
+@code{use-package}, you can use a symbol:
+
+@lisp
+@group
+(use-package tex
+ :ensure auctex)
+@end group
+@end lisp
+
+@vindex use-package-always-ensure
+You can customize the user option @code{use-package-always-ensure} to
+a non-@code{nil} value if you want this behavior to be global for all
+packages:
+
+@lisp
+@group
+(require 'use-package-ensure)
+(setq use-package-always-ensure t)
+@end group
+@end lisp
+
+@noindent
+You can override the above setting for a single package by adding
+@w{@code{:ensure nil}} to its declaration.
+
+@findex :vc
+The @code{:vc} keyword can be used to control how packages are
+downloaded and/or installed. More specifically, it allows one to fetch
+and update packages directly from a version control system. This is
+especially convenient when wanting to install a package that is not on
+any package archive.
+
+The keyword accepts the same arguments as specified in
+@pxref{Fetching Package Sources,,, emacs, GNU Emacs Manual}, except
+that a name need not explicitly be given: it is inferred from the
+declaration. The accepted property list is augmented by a @code{:rev}
+keyword, which has the same shape as the @code{REV} argument to
+@code{package-vc-install}. Notably -- even when not specified --
+@code{:rev} defaults to checking out the last release of the package.
+You can use @code{:rev :newest} to check out the latest commit.
+
+For example,
+
+@example
+@group
+(use-package bbdb
+ :vc (:url "https://git.savannah.nongnu.org/git/bbdb.git"
+ :rev :newest))
+@end group
+@end example
+
+would try -- by invoking @code{package-vc-install} -- to install the
+latest commit of the package @code{foo} from the specified remote.
+
+@vindex use-package-vc-prefer-newest
+Alternatively, the @code{use-package-vc-prefer-newest} user option
+exists to always prefer the latest commit.
+
+The @code{:vc} keyword can also be used for local packages, by
+combining it with @code{:load-path} (@pxref{Load path}):
+
+@example
+@group
+;; Use a local copy of BBDB instead of the one from GNU ELPA.
+(use-package bbdb
+ :vc t
+ :load-path "/path/to/bbdb/dir/")
+@end group
+@end example
+
+The above dispatches to @code{package-vc-install-from-checkout}.
+
+@node Pinning packages
+@section Pinning packages using @code{:pin}
+@cindex installing package from specific archive
+@cindex pinning a package to archive
+
+@findex :pin
+use-package can @dfn{pin} a package to a specific archive using the
+@code{:pin} keyword.@footnote{The @code{:pin} keyword has no effect on
+Emacs versions older than 24.4.} This allows you to mix and match
+packages from different archives. The primary use-case for this is
+preferring to install packages from @acronym{GNU} @acronym{ELPA} or
+@acronym{NonGNU} @acronym{ELPA} (indicated by @code{gnu} and @code{nongnu},
+respectively), while installing specific packages from third-party
+archives.
+
+For example:
+
+@lisp
+@group
+(use-package company
+ :ensure t
+ :pin gnu) ; GNU ELPA
+@end group
+@end lisp
+
+@vindex use-package-always-pin
+Unfortunately, the third-party archive @acronym{MELPA} uses a
+versioning scheme based on dates, which means that packages from that
+archive are always preferred. If you are using that archive, we
+strongly encourage you to customize @code{use-package-always-pin} to
+@code{nongnu}. This guarantees that you are using a version of that
+package that has been specifically marked for release by its
+developer, and not a development snapshot.
+
+@cindex manual update of packages
+@c FIXME: This needs clarifying. AFAIK, :ensure does not update packages.
+If you want to manually keep a package updated and ignore upstream
+updates, you can pin it to @samp{manual}. This will work as long as
+you have not customized a repository to use that name in the
+@code{package-archives} variable.
+
+Example:
+
+@lisp
+@group
+(use-package org
+ :ensure t
+ ;; ignore org-mode from upstream and use a manually installed version
+ :pin manual)
+@end group
+@end lisp
+
+@code{use-package} signals an error if you try to pin a package to an
+archive that is not configured using @code{package-archives} (except
+from the special @samp{manual} archive).
+
+@node Other package managers
+@section Non-standard package managers
+@cindex non-standard package managers
+@cindex package managers, other than @file{package.el}
+@cindex installing using non-standard package managers
+
+By default, use-package assumes that you are using the Emacs built-in
+@file{package.el} package manager. We expect that most users will
+find that it is capable enough, even for advanced use cases.
+
+@vindex use-package-ensure-function
+However, some users might prefer to use a third-party package manager
+for a specific circumstance or use case. By setting the user option
+@code{use-package-ensure-function} to the name of a function, you can
+direct @code{:ensure} to use a different package manager for
+installing packages.
+
+For more details, please see the documentation of the package manager
+you are using. If you run into any bugs, it is often best to report
+them directly to the developers of that package manager.
+
+@c ----------------------------------------------------------------------------
+@node Byte-compiling
+@chapter Byte-compiling your init file
+@cindex byte-compiling your init file
+
+Some users might want to byte-compile their init file to make Emacs
+startup faster. This is not recommended in most cases, as the
+speed-up is usually too small to be worth it, and it can lead to
+confusion if the byte-compiled files are out-of-date. If you still
+want to do it, this chapter explains how to do that.
+
+@code{use-package} always loads every library that it can while a file
+is being byte-compiled. This helps silence spurious warnings about
+unknown variables and functions.
+
+@findex :defines
+@findex :functions
+@cindex silence byte-compilation warnings
+However, there are times when this is just not enough. For those
+times, use the @code{:defines} and @code{:functions} keywords to
+introduce dummy variable and function declarations solely for the sake
+of silencing byte-compiler warnings. For example:
+
+@lisp
+@group
+(use-package texinfo
+ :defines texinfo-section-list
+ :commands texinfo-mode
+ :init
+ (add-to-list 'auto-mode-alist '("\\.texi$" . texinfo-mode)))
+@end group
+@end lisp
+
+If you need to silence a missing function warning, you can use
+@code{:functions}:
+
+@lisp
+@group
+(use-package ruby-mode
+ :mode "\\.rb\\'"
+ :interpreter "ruby"
+ :functions inf-ruby-keys
+ :config
+ (defun my-ruby-mode-hook ()
+ (require 'inf-ruby)
+ (inf-ruby-keys))
+ (add-hook 'ruby-mode-hook 'my-ruby-mode-hook))
+@end group
+@end lisp
+
+@findex :no-require
+@cindex prevent a package from loading at compile-time
+@cindex package loading at byte-compilation time, prevent
+Normally, @code{use-package} will load each package at compile time
+before compiling the configuration, to ensure that any necessary
+symbols are in scope to satisfy the byte-compiler. At times this can
+cause problems, since a package may have special loading requirements,
+and all that you want to use @code{use-package} for is to add a
+configuration to the @code{eval-after-load} hook. In such cases, use
+the @code{:no-require} keyword:
+
+@lisp
+@group
+(use-package foo
+ :no-require t
+ :config
+ (message "Evaluate this immediately after loading `foo'"))
+@end group
+@end lisp
+
+@c ----------------------------------------------------------------------------
+@node Troubleshooting
+@chapter Troubleshooting
+
+@cindex troubleshooting use-package
+@cindex debugging use-package
+If an error occurs while initializing or configuring a package, this
+will not stop your Emacs from loading. Instead, @code{use-package}
+captures the error and reports it in a special @file{*Warnings*} popup
+buffer, so that you can debug the situation in an otherwise functional
+Emacs.
+
+If you are having trouble when starting Emacs, you can pass Emacs the
+@samp{--debug-init} command line flag. @xref{Initial Options,,,
+emacs, GNU Emacs Manual}. To get even more information when using
+that flag, add the following to your init file (these options are
+documented below):
+
+@lisp
+@group
+(when init-file-debug
+ (setq use-package-verbose t
+ use-package-expand-minimally nil
+ use-package-compute-statistics t
+ debug-on-error t))
+@end group
+@end lisp
+
+@cindex reporting bugs
+@cindex expanding macro, for troubleshooting
+Since @code{use-package} is a macro, the first step when you need to
+dig deeper is usually to see what Emacs Lisp code your declaration
+expands to. You can either use the command @w{@kbd{M-x
+pp-macroexpand-last-sexp}}, or wrap the use-package declaration in
+@code{macroexpand} and evaluate it. It is a good idea to include
+their output in any bugs you file for use-package.
+
+@menu
+* Troubleshooting Options::
+* Gathering Statistics::
+* Disabling a package::
+@end menu
+
+@node Troubleshooting Options
+@section Options that help when troubleshooting
+@cindex options for troubleshooting
+@cindex troubleshooting, options that help
+
+@vindex use-package-expand-minimally
+By default, use-package will attempts to catch and report errors that
+occur during expansion of use-package declarations in your init file.
+Customize the user option @code{use-package-expand-minimally} to a
+non-@code{nil} value to disable this checking.
+
+@findex :catch
+This behavior may be overridden locally using the @code{:catch}
+keyword. If @code{t} or @code{nil}, it enables or disables catching
+errors at load time. It can also be a function taking two arguments:
+the keyword being processed at the time the error was encountered, and
+the error object (as generated by @code{condition-case}). For
+example:
+
+@lisp
+@group
+(use-package example
+ ;; Note that errors are never trapped in the preface, since
+ ;; doing so would hide definitions from the byte-compiler.
+ :preface (message "I'm here at byte-compile and load time")
+ :init (message "I'm always here at startup")
+ :config
+ (message "I'm always here after the package is loaded")
+ (error "oops")
+ ;; Don't try to (require 'example), this is just an example!
+ :no-require t
+ :catch (lambda (keyword err)
+ (message (error-message-string err))))
+@end group
+@end lisp
+
+Evaluating the above form will print these messages:
+
+@verbatim
+I'm here at byte-compile and load time
+I'm always here at startup
+Configuring package example...
+I'm always here after the package is loaded
+oops
+@end verbatim
+
+@node Gathering Statistics
+@section Gathering Statistics
+@cindex gathering use-package statistics
+@cindex usage statistics for use-package
+
+@vindex use-package-verbose
+When a package is loaded, and if you have @code{use-package-verbose}
+set to @code{t}, or if the package takes longer than 0.1 seconds to
+load, you will see a message to indicate this loading activity in the
+@code{*Messages*} buffer. The same will happen for configuration, or
+@code{:config} blocks, that take longer than 0.1 seconds to execute.
+
+@vindex use-package-compute-statistics
+If you'd like to see a summary how many packages you've loaded, what
+stage of initialization they've reached, and how much aggregate time
+they've spent (roughly), you can customize the user option
+@code{use-package-compute-statistics} to a non-@code{nil} value. Then
+reload your packages, normally by restarting Emacs, to make sure that
+use-package can gather statistics for all your packages.
+
+@cindex use-package-report
+Run the command @kbd{M-x use-package-report} to see the results. The
+buffer displayed is a tabulated list. To sort rows based on a
+particular column, move point to it and type @kbd{S}, or click the
+column name at the top of the buffer on graphical displays.
+
+@findex use-package-reset-statistics
+To reset all statistics that use-package has gathered for the current
+Emacs invocation, run the command @kbd{M-x use-package-reset-statistics}.
+
+Note that if you are setting @code{use-package-compute-statistics}
+directly in your init file, and not with @code{customize}, you must do
+this after loading @code{use-package}, but before any
+@code{use-package} forms.
+
+@node Disabling a package
+@section Disabling a package
+@cindex disable package
+
+@findex :disabled
+The @code{:disabled} keyword inhibits loading a package, and all its
+customizations. It is equivalent to commenting out or deleting the
+definition.
+
+You could use this, for example, to temporarily disable a package that
+you're having difficulties with, or to avoid loading a package that
+you're not currently using.
+
+This example disables the @samp{foo} package:
+
+@lisp
+@group
+(use-package foo
+ :disabled)
+@end group
+@end lisp
+
+When byte-compiling your init file, use-package omits disabled
+declarations from the output entirely, in order to make Emacs startup
+faster.
+
+@c ----------------------------------------------------------------------------
+@node Keyword extensions
+@appendix Keyword extensions
+@cindex keyword extension
+@cindex extending use-package keywords
+
+use-package is based on an extensible framework that makes it easy for
+package authors to add new keywords, or modify the behavior of
+existing keywords.
+
+Some keyword extensions are included with @code{use-package}, and can
+be optionally enabled.
+
+@menu
+* use-package-ensure-system-package::
+* Creating an extension::
+@end menu
+
+@node use-package-ensure-system-package
+@appendixsec :use-package-ensure-system-package
+
+@findex :ensure-system-package
+The @code{:ensure-system-package} keyword allows you to ensure certain
+executables are available on your system alongside your package
+declarations.@footnote{On macOS, your @code{exec-path} might be
+different if you are starting Emacs as a GUI app instead of from a
+shell. If you find that Emacs on macOS cannot find some executables
+that you know are already installed, you could try the
+@uref{https://github.com/purcell/exec-path-from-shell,@samp{exec-path-from-shell}}
+package.}
+
+To use this extension, add this immediately after loading
+@code{use-package}:
+
+@lisp
+(use-package use-package-ensure-system-package)
+@end lisp
+
+Now you can use the @code{:ensure-system-package} keyword.
+Here's an example usage:
+
+@lisp
+@group
+(use-package foo
+ :ensure-system-package foo)
+@end group
+@end lisp
+
+This will expect a global binary package to exist called @code{foo}.
+If it does not, it will use your system package manager to attempt an
+install of a binary by the same name asynchronously. This requires
+the @acronym{GNU} @acronym{ELPA} package
+@uref{https://gitlab.com/jabranham/system-packages,@samp{system-packages}},
+so for this to work you must install that first.
+
+One way of making sure it is installed is with @code{use-package}
+together with @code{:ensure}.
+
+@lisp
+@group
+(use-package system-packages
+ :ensure t)
+@end group
+@end lisp
+
+For example, on a Debian GNU/Linux system, this would call
+@samp{apt-get install foo}.
+
+If the package is named differently than the binary, you can use a
+cons in the form of @code{(binary . package-name)}. For example:
+
+@lisp
+@group
+(use-package foo
+ :ensure-system-package
+ (foocmd . foo))
+@end group
+@end lisp
+
+On a Debian GNU/Linux system, this would call @code{apt install foo}
+if Emacs could not locate the executable @code{foocmd}.@footnote{For
+manual testing, you could use the @code{executable-find} function,
+which is what @samp{system-packages} uses internally.}
+
+@code{:ensure-system-package} can also take a cons where the
+@code{cdr} is a string that will get called by
+@code{(async-shell-command)} to install if it isn't found. This does
+not depend on any external package.
+
+@lisp
+@group
+(use-package tern
+ :ensure-system-package (tern . "npm i -g tern"))
+@end group
+@end lisp
+
+To install several packages, you can pass in a list of conses:
+
+@lisp
+@group
+(use-package ruby-mode
+ :ensure-system-package
+ ((rubocop . "gem install rubocop")
+ (ruby-lint . "gem install ruby-lint")
+ (ripper-tags . "gem install ripper-tags")
+ (pry . "gem install pry")))
+@end group
+@end lisp
+
+Finally, in case the package dependency does not provide a global
+executable, you can ensure that packages exist by checking the
+presence of a file by providing a string like so:
+
+@lisp
+@group
+(use-package dash-at-point
+ :if (eq system-type 'darwin)
+ :ensure-system-package
+ ("/Applications/Dash.app" . "brew cask install dash"))
+@end group
+@end lisp
+
+@code{:ensure-system-package} will use @code{system-packages-install}
+to install system packages, except where a custom command has been
+specified, in which case it will be executed verbatim by
+@code{async-shell-command}.
+
+The user options @code{system-packages-package-manager} and
+@code{system-packages-use-sudo} are honored, but not for custom
+commands. Custom commands should include the call to sudo in the
+command if needed.
+
+@node Creating an extension
+@appendixsec How to create an extension keyword
+@cindex extension keywords
+
+This section describes how to create a new keyword.
+
+@enumerate
+@item
+Add the keyword.
+
+The first step is to add your keyword at the right place in
+@code{use-package-keywords}. This list determines the order in which
+things will happen in the expanded code. You should never change this
+order, but it gives you a framework within which to decide when your
+keyword should fire.
+
+@item
+Create a normalizer.
+
+The job of the normalizer is take a list of arguments (possibly
+@code{nil}), and turn it into the single argument (which could still
+be a list) that should appear in the final property list used by
+@code{use-package}.
+
+Define a normalizer for your keyword by defining a function named
+after the keyword, for example:
+
+@lisp
+@group
+(defun use-package-normalize/:pin (name-symbol keyword args)
+ (use-package-only-one (symbol-name keyword) args
+ (lambda (label arg)
+ (cond
+ ((stringp arg) arg)
+ ((symbolp arg) (symbol-name arg))
+ (t
+ (use-package-error
+ ":pin wants an archive name (a string)"))))))
+@end group
+@end lisp
+
+@item
+Create a handler.
+
+Once you have a normalizer, you must create a handler for the keyword.
+
+Handlers can affect the handling of keywords in two ways. First, they
+can modify the @code{state} plist before recursively processing the
+remaining keywords, to influence keywords that pay attention to the
+state (one example is the state keyword @code{:deferred}, not to be
+confused with the @code{use-package} keyword @code{:defer}). Then,
+once the remaining keywords have been handled and their resulting
+forms returned, the handlers may manipulate, extend, or just ignore
+those forms.
+
+The task of each handler is to return a @emph{list of forms}
+representing code to be inserted. It does not need to be a
+@code{progn} list, as this is handled automatically in other places.
+Thus it is common to see the idiom of using @code{use-package-concat}
+to add new functionality before or after a code body, so that only the
+minimum code necessary is emitted as the result of a
+@code{use-package} expansion.
+
+This is an example handler:
+
+@lisp
+@group
+(defun use-package-handler/:pin (name-symbol keyword archive-name rest state)
+ (let ((body (use-package-process-keywords name-symbol rest state)))
+ ;; This happens at macro expansion time, not when the expanded code is
+ ;; compiled or evaluated.
+ (if (null archive-name)
+ body
+ (use-package-pin-package name-symbol archive-name)
+ (use-package-concat
+ body
+ `((push '(,name-symbol . ,archive-name)
+ package-pinned-packages))))))
+@end group
+@end lisp
+
+@item
+Test it.
+
+After the keyword has been inserted into @code{use-package-keywords},
+and a normalizer and a handler has been defined, you can now test the
+keyword by seeing how usages of the keyword will expand. For this,
+use @w{@kbd{M-x pp-macroexpand-last-sexp}} with the cursor set
+immediately after the @code{(use-package @dots{})} expression.
+@end enumerate
+
+@c ----------------------------------------------------------------------------
+@node History
+@appendix History and acknowledgments
+
+use-package was written by John Wiegley. Its development started in
+2012, and it got merged into Emacs in 2022, in preparation of the
+release of Emacs 29.1.
+
+Dozens of people have contributed to use-package over the years with
+bug reports, documentation and code. They are too many to list here,
+but we thank them all for their contributions.
+
+This Texinfo manual was written by Stefan Kangas, as a significant
+rewrite of the old use-package manual and @file{README}.
+
+@node GNU Free Documentation License
+@appendix GNU Free Documentation License
+@include doclicense.texi
+
+@node Index
+@unnumbered Index
+@printindex cp
+
+@bye