b12f/nixpkgs
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

nixpkgs docs: Reformat

Browse source
This commit is contained in:
Graham Christensen 2018-10-02 15:59:59 -04:00
parent 444e04b985
commit c07ba7c856
No known key found for this signature in database
GPG key ID: ACA1C1D120C83D5C
8 changed files with 788 additions and 777 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
doc/cross-compilation.xml
View file

@ -47,9 +47,10 @@
<para> <para>
In Nixpkgs, these three platforms are defined as attribute sets under the In Nixpkgs, these three platforms are defined as attribute sets under the
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
<literal>targetPlatform</literal>. They are always defined as attributes in and <literal>targetPlatform</literal>. They are always defined as
the standard environment. That means one can access them like: attributes in the standard environment. That means one can access them
like:
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting> <programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
. .
</para> </para>

8
doc/functions/debug.xml
View file

@ -13,9 +13,9 @@
<para> <para>
In the <literal>lib/debug.nix</literal> file you will find a number of In the <literal>lib/debug.nix</literal> file you will find a number of
functions that help (pretty-)printing values while evaluation is runnnig. functions that help (pretty-)printing values while evaluation is runnnig. You
You can even specify how deep these values should be printed recursively, can even specify how deep these values should be printed recursively, and
and transform them on the fly. Please consult the docstrings in transform them on the fly. Please consult the docstrings in
<literal>lib/debug.nix</literal> for usage information. <literal>lib/debug.nix</literal> for usage information.
</para> </para>
</section> </section>

96
doc/functions/dockertools.xml
View file

@ -30,8 +30,8 @@
</para> </para>
<para> <para>
The parameters of <varname>buildImage</varname> with relative example The parameters of <varname>buildImage</varname> with relative example values
values are described below: are described below:
</para> </para>
<example xml:id='ex-dockerTools-buildImage'> <example xml:id='ex-dockerTools-buildImage'>
@ -71,8 +71,8 @@ buildImage {
<calloutlist> <calloutlist>
<callout arearefs='ex-dockerTools-buildImage-1'> <callout arearefs='ex-dockerTools-buildImage-1'>
<para> <para>
<varname>name</varname> specifies the name of the resulting image. This <varname>name</varname> specifies the name of the resulting image. This is
is the only required argument for <varname>buildImage</varname>. the only required argument for <varname>buildImage</varname>.
</para> </para>
</callout> </callout>
<callout arearefs='ex-dockerTools-buildImage-2'> <callout arearefs='ex-dockerTools-buildImage-2'>
@ -84,8 +84,8 @@ buildImage {
</callout> </callout>
<callout arearefs='ex-dockerTools-buildImage-3'> <callout arearefs='ex-dockerTools-buildImage-3'>
<para> <para>
<varname>fromImage</varname> is the repository tarball containing the <varname>fromImage</varname> is the repository tarball containing the base
base image. It must be a valid Docker image, such as exported by image. It must be a valid Docker image, such as exported by
<command>docker save</command>. By default it's <literal>null</literal>, <command>docker save</command>. By default it's <literal>null</literal>,
which can be seen as equivalent to <literal>FROM scratch</literal> of a which can be seen as equivalent to <literal>FROM scratch</literal> of a
<filename>Dockerfile</filename>. <filename>Dockerfile</filename>.
@ -111,10 +111,10 @@ buildImage {
</callout> </callout>
<callout arearefs='ex-dockerTools-buildImage-6'> <callout arearefs='ex-dockerTools-buildImage-6'>
<para> <para>
<varname>contents</varname> is a derivation that will be copied in the <varname>contents</varname> is a derivation that will be copied in the new
new layer of the resulting image. This can be similarly seen as layer of the resulting image. This can be similarly seen as <command>ADD
<command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. contents/ /</command> in a <filename>Dockerfile</filename>. By default
By default it's <literal>null</literal>. it's <literal>null</literal>.
</para> </para>
</callout> </callout>
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'> <callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
@ -146,9 +146,9 @@ buildImage {
<para> <para>
After the new layer has been created, its closure (to which After the new layer has been created, its closure (to which
<varname>contents</varname>, <varname>config</varname> and <varname>contents</varname>, <varname>config</varname> and
<varname>runAsRoot</varname> contribute) will be copied in the layer <varname>runAsRoot</varname> contribute) will be copied in the layer itself.
itself. Only new dependencies that are not already in the existing layers Only new dependencies that are not already in the existing layers will be
will be copied. copied.
</para> </para>
<para> <para>
@ -170,8 +170,8 @@ buildImage {
<note> <note>
<para> <para>
If you see errors similar to <literal>getProtocolByName: does not exist If you see errors similar to <literal>getProtocolByName: does not exist (no
(no such protocol name: tcp)</literal> you may need to add such protocol name: tcp)</literal> you may need to add
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>. <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
</para> </para>
</note> </note>
@ -187,24 +187,23 @@ buildImage {
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date"> <example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
<title>Impurely Defining a Docker Layer's Creation Date</title> <title>Impurely Defining a Docker Layer's Creation Date</title>
<para> <para>
By default <function>buildImage</function> will use a static By default <function>buildImage</function> will use a static date of one
date of one second past the UNIX Epoch. This allows second past the UNIX Epoch. This allows <function>buildImage</function> to
<function>buildImage</function> to produce binary reproducible produce binary reproducible images. When listing images with
images. When listing images with <command>docker list <command>docker list images</command>, the newly created images will be
images</command>, the newly created images will be listed like listed like this:
this:
</para> </para>
<screen><![CDATA[ <screen><![CDATA[
$ docker image list $ docker image list
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest 08c791c7846e 48 years ago 25.2MB hello latest 08c791c7846e 48 years ago 25.2MB
]]></screen> ]]></screen>
<para> <para>
You can break binary reproducibility but have a sorted, You can break binary reproducibility but have a sorted, meaningful
meaningful <literal>CREATED</literal> column by setting <literal>CREATED</literal> column by setting <literal>created</literal> to
<literal>created</literal> to <literal>now</literal>. <literal>now</literal>.
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[
pkgs.dockerTools.buildImage { pkgs.dockerTools.buildImage {
name = "hello"; name = "hello";
tag = "latest"; tag = "latest";
@ -215,9 +214,9 @@ pkgs.dockerTools.buildImage {
} }
]]></programlisting> ]]></programlisting>
<para> <para>
and now the Docker CLI will display a reasonable date and and now the Docker CLI will display a reasonable date and sort the images
sort the images as expected: as expected:
<screen><![CDATA[ <screen><![CDATA[
$ docker image list $ docker image list
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest de2bf4786de6 About a minute ago 25.2MB hello latest de2bf4786de6 About a minute ago 25.2MB
@ -380,8 +379,8 @@ pkgs.dockerTools.buildLayeredImage {
<para> <para>
If the produced image will not be extended by other Docker builds, it is If the produced image will not be extended by other Docker builds, it is
safe to set <varname>maxLayers</varname> to <literal>128</literal>. safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
However it will be impossible to extend the image further. it will be impossible to extend the image further.
</para> </para>
<para> <para>
@ -402,10 +401,10 @@ pkgs.dockerTools.buildLayeredImage {
<title>pullImage</title> <title>pullImage</title>
<para> <para>
This function is analogous to the <command>docker pull</command> command, This function is analogous to the <command>docker pull</command> command, in
in that can be used to pull a Docker image from a Docker registry. By that can be used to pull a Docker image from a Docker registry. By default
default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
used to pull images. images.
</para> </para>
<para> <para>
@ -439,8 +438,8 @@ pullImage {
<varname>imageDigest</varname> specifies the digest of the image to be <varname>imageDigest</varname> specifies the digest of the image to be
downloaded. Skopeo can be used to get the digest of an image, with its downloaded. Skopeo can be used to get the digest of an image, with its
<varname>inspect</varname> subcommand. Since a given <varname>inspect</varname> subcommand. Since a given
<varname>imageName</varname> may transparently refer to a manifest list <varname>imageName</varname> may transparently refer to a manifest list of
of images which support multiple architectures and/or operating systems, images which support multiple architectures and/or operating systems,
supply the `--override-os` and `--override-arch` arguments to specify supply the `--override-os` and `--override-arch` arguments to specify
exactly which image you want. By default it will match the OS and exactly which image you want. By default it will match the OS and
architecture of the host the command is run on. architecture of the host the command is run on.
@ -461,8 +460,8 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
</callout> </callout>
<callout arearefs='ex-dockerTools-pullImage-4'> <callout arearefs='ex-dockerTools-pullImage-4'>
<para> <para>
<varname>sha256</varname> is the checksum of the whole fetched image. <varname>sha256</varname> is the checksum of the whole fetched image. This
This argument is required. argument is required.
</para> </para>
</callout> </callout>
<callout arearefs='ex-dockerTools-pullImage-5'> <callout arearefs='ex-dockerTools-pullImage-5'>
@ -485,10 +484,10 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
<para> <para>
This function is analogous to the <command>docker export</command> command, This function is analogous to the <command>docker export</command> command,
in that can used to flatten a Docker image that contains multiple layers. in that can used to flatten a Docker image that contains multiple layers. It
It is in fact the result of the merge of all the layers of the image. As is in fact the result of the merge of all the layers of the image. As such,
such, the result is suitable for being imported in Docker with the result is suitable for being imported in Docker with <command>docker
<command>docker import</command>. import</command>.
</para> </para>
<note> <note>
@ -517,9 +516,8 @@ exportImage {
<para> <para>
The parameters relative to the base image have the same synopsis as The parameters relative to the base image have the same synopsis as
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
that <varname>fromImage</varname> is the only required argument in this <varname>fromImage</varname> is the only required argument in this case.
case.
</para> </para>
<para> <para>
@ -533,8 +531,8 @@ exportImage {
<para> <para>
This constant string is a helper for setting up the base files for managing This constant string is a helper for setting up the base files for managing
users and groups, only if such files don't exist already. It is suitable users and groups, only if such files don't exist already. It is suitable for
for being used in a <varname>runAsRoot</varname> being used in a <varname>runAsRoot</varname>
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
in the example below: in the example below:
</para> </para>
@ -563,4 +561,4 @@ buildImage {
manipulate users and groups. manipulate users and groups.
</para> </para>
</section> </section>
</section> </section>

26
doc/functions/fhs-environments.xml
View file

@ -9,12 +9,11 @@
FHS-compatible lightweight sandboxes. It creates an isolated root with bound FHS-compatible lightweight sandboxes. It creates an isolated root with bound
<filename>/nix/store</filename>, so its footprint in terms of disk space <filename>/nix/store</filename>, so its footprint in terms of disk space
needed is quite small. This allows one to run software which is hard or needed is quite small. This allows one to run software which is hard or
unfeasible to patch for NixOS -- 3rd-party source trees with FHS unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
assumptions, games distributed as tarballs, software with integrity checking games distributed as tarballs, software with integrity checking and/or
and/or external self-updated binaries. It uses Linux namespaces feature to external self-updated binaries. It uses Linux namespaces feature to create
create temporary lightweight environments which are destroyed after all temporary lightweight environments which are destroyed after all child
child processes exit, without root user rights requirement. Accepted processes exit, without root user rights requirement. Accepted arguments are:
arguments are:
</para> </para>
<variablelist> <variablelist>
@ -57,8 +56,7 @@
</term> </term>
<listitem> <listitem>
<para> <para>
Additional commands to be executed for finalizing the directory Additional commands to be executed for finalizing the directory structure.
structure.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -109,8 +107,8 @@
</variablelist> </variablelist>
<para> <para>
One can create a simple environment using a <literal>shell.nix</literal> One can create a simple environment using a <literal>shell.nix</literal> like
like that: that:
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[
@ -136,9 +134,9 @@
<para> <para>
Running <literal>nix-shell</literal> would then drop you into a shell with Running <literal>nix-shell</literal> would then drop you into a shell with
these libraries and binaries available. You can use this to run these libraries and binaries available. You can use this to run closed-source
closed-source applications which expect FHS structure without hassles: applications which expect FHS structure without hassles: simply change
simply change <literal>runScript</literal> to the application path, e.g. <literal>runScript</literal> to the application path, e.g.
<filename>./bin/start.sh</filename> -- relative paths are supported. <filename>./bin/start.sh</filename> -- relative paths are supported.
</para> </para>
</section> </section>

13
doc/functions/generators.xml
View file

@ -14,12 +14,11 @@
All generators follow a similar call interface: <code>generatorName All generators follow a similar call interface: <code>generatorName
configFunctions data</code>, where <literal>configFunctions</literal> is an configFunctions data</code>, where <literal>configFunctions</literal> is an
attrset of user-defined functions that format nested parts of the content. attrset of user-defined functions that format nested parts of the content.
They each have common defaults, so often they do not need to be set They each have common defaults, so often they do not need to be set manually.
manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
] name)</code> from the <literal>INI</literal> generator. It receives the name)</code> from the <literal>INI</literal> generator. It receives the name
name of a section and sanitizes it. The default of a section and sanitizes it. The default <literal>mkSectionName</literal>
<literal>mkSectionName</literal> escapes <literal>[</literal> and escapes <literal>[</literal> and <literal>]</literal> with a backslash.
<literal>]</literal> with a backslash.
</para> </para>
<para> <para>
@ -87,4 +86,4 @@ merge:"diff3"
Detailed documentation for each generator can be found in Detailed documentation for each generator can be found in
<literal>lib/generators.nix</literal>. <literal>lib/generators.nix</literal>.
</para> </para>
</section> </section>

42
doc/functions/overrides.xml
View file

@ -81,17 +81,16 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
<note> <note>
<para> <para>
Note that <varname>separateDebugInfo</varname> is processed only by the Note that <varname>separateDebugInfo</varname> is processed only by the
<varname>stdenv.mkDerivation</varname> function, not the generated, raw <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
Nix derivation. Thus, using <varname>overrideDerivation</varname> will not derivation. Thus, using <varname>overrideDerivation</varname> will not work
work in this case, as it overrides only the attributes of the final in this case, as it overrides only the attributes of the final derivation.
derivation. It is for this reason that <varname>overrideAttrs</varname> It is for this reason that <varname>overrideAttrs</varname> should be
should be preferred in (almost) all cases to preferred in (almost) all cases to <varname>overrideDerivation</varname>,
<varname>overrideDerivation</varname>, i.e. to allow using i.e. to allow using <varname>sdenv.mkDerivation</varname> to process input
<varname>sdenv.mkDerivation</varname> to process input arguments, as well arguments, as well as the fact that it is easier to use (you can use the
as the fact that it is easier to use (you can use the same attribute names same attribute names you see in your Nix code, instead of the ones
you see in your Nix code, instead of the ones generated (e.g. generated (e.g. <varname>buildInputs</varname> vs
<varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>, <varname>nativeBuildInputs</varname>, and involves less typing.
and involves less typing.
</para> </para>
</note> </note>
</section> </section>
@ -101,8 +100,8 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
<warning> <warning>
<para> <para>
You should prefer <varname>overrideAttrs</varname> in almost all cases, You should prefer <varname>overrideAttrs</varname> in almost all cases, see
see its documentation for the reasons why. its documentation for the reasons why.
<varname>overrideDerivation</varname> is not deprecated and will continue <varname>overrideDerivation</varname> is not deprecated and will continue
to work, but is less nice to use and does not have as many abilities as to work, but is less nice to use and does not have as many abilities as
<varname>overrideAttrs</varname>. <varname>overrideAttrs</varname>.
@ -115,18 +114,17 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
modifying it, which breaks package abstraction and removes error-checking modifying it, which breaks package abstraction and removes error-checking
of function arguments. In addition, this evaluation-per-function of function arguments. In addition, this evaluation-per-function
application incurs a performance penalty, which can become a problem if application incurs a performance penalty, which can become a problem if
many overrides are used. It is only intended for ad-hoc customisation, many overrides are used. It is only intended for ad-hoc customisation, such
such as in <filename>~/.config/nixpkgs/config.nix</filename>. as in <filename>~/.config/nixpkgs/config.nix</filename>.
</para> </para>
</warning> </warning>
<para> <para>
The function <varname>overrideDerivation</varname> creates a new derivation The function <varname>overrideDerivation</varname> creates a new derivation
based on an existing one by overriding the original's attributes with the based on an existing one by overriding the original's attributes with the
attribute set produced by the specified function. This function is attribute set produced by the specified function. This function is available
available on all derivations defined using the on all derivations defined using the <varname>makeOverridable</varname>
<varname>makeOverridable</varname> function. Most standard function. Most standard derivation-producing functions, such as
derivation-producing functions, such as
<varname>stdenv.mkDerivation</varname>, are defined using this function, <varname>stdenv.mkDerivation</varname>, are defined using this function,
which means most packages in the nixpkgs expression, which means most packages in the nixpkgs expression,
<varname>pkgs</varname>, have this function. <varname>pkgs</varname>, have this function.
@ -197,9 +195,9 @@ c = lib.makeOverridable f { a = 1; b = 2; };
<para> <para>
The variable <varname>c</varname> however also has some additional The variable <varname>c</varname> however also has some additional
functions, like <link linkend="sec-pkg-override">c.override</link> which functions, like <link linkend="sec-pkg-override">c.override</link> which can
can be used to override the default arguments. In this example the value of be used to override the default arguments. In this example the value of
<varname>(c.override { a = 4; }).result</varname> is 6. <varname>(c.override { a = 4; }).result</varname> is 6.
</para> </para>
</section> </section>
</section> </section>

9
doc/functions/shell.xml
View file

@ -5,16 +5,15 @@
<title>pkgs.mkShell</title> <title>pkgs.mkShell</title>
<para> <para>
<function>pkgs.mkShell</function> is a special kind of derivation <function>pkgs.mkShell</function> is a special kind of derivation that is
that is only useful when using it combined with only useful when using it combined with <command>nix-shell</command>. It will
<command>nix-shell</command>. It will in fact fail to instantiate in fact fail to instantiate when invoked with <command>nix-build</command>.
when invoked with <command>nix-build</command>.
</para> </para>
<section xml:id="sec-pkgs-mkShell-usage"> <section xml:id="sec-pkgs-mkShell-usage">
<title>Usage</title> <title>Usage</title>
<programlisting><![CDATA[ <programlisting><![CDATA[
{ pkgs ? import <nixpkgs> {} }: { pkgs ? import <nixpkgs> {} }:
pkgs.mkShell { pkgs.mkShell {
# this will make all the build inputs from hello and gnutar # this will make all the build inputs from hello and gnutar

70
doc/package-notes.xml
View file

@ -671,8 +671,9 @@ overrides = self: super: rec {
plugins = with availablePlugins; [ python perl ]; plugins = with availablePlugins; [ python perl ];
} }
}</programlisting> }</programlisting>
If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal> If the <literal>configure</literal> function returns an attrset without the
attribute, <literal>availablePlugins</literal> will be used automatically. <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
will be used automatically.
</para> </para>
<para> <para>
@ -706,9 +707,11 @@ overrides = self: super: rec {
}; } }; }
</programlisting> </programlisting>
</para> </para>
<para> <para>
WeeChat allows to set defaults on startup using the <literal>--run-command</literal>. WeeChat allows to set defaults on startup using the
The <literal>configure</literal> method can be used to pass commands to the program: <literal>--run-command</literal>. The <literal>configure</literal> method
can be used to pass commands to the program:
<programlisting>weechat.override { <programlisting>weechat.override {
configure = { availablePlugins, ... }: { configure = { availablePlugins, ... }: {
init = '' init = ''
@ -720,9 +723,11 @@ overrides = self: super: rec {
Further values can be added to the list of commands when running Further values can be added to the list of commands when running
<literal>weechat --run-command "your-commands"</literal>. <literal>weechat --run-command "your-commands"</literal>.
</para> </para>
<para> <para>
Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>. Additionally it's possible to specify scripts to be loaded when starting
These will be loaded before the commands from <literal>init</literal>: <literal>weechat</literal>. These will be loaded before the commands from
<literal>init</literal>:
<programlisting>weechat.override { <programlisting>weechat.override {
configure = { availablePlugins, ... }: { configure = { availablePlugins, ... }: {
scripts = with pkgs.weechatScripts; [ scripts = with pkgs.weechatScripts; [
@ -734,11 +739,13 @@ overrides = self: super: rec {
}; };
}</programlisting> }</programlisting>
</para> </para>
<para> <para>
In <literal>nixpkgs</literal> there's a subpackage which contains derivations for In <literal>nixpkgs</literal> there's a subpackage which contains
WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute derivations for WeeChat scripts. Such derivations expect a
which contains a list of all scripts inside the store path. Furthermore all scripts <literal>passthru.scripts</literal> attribute which contains a list of all
have to live in <literal>$out/share</literal>. An exemplary derivation looks like this: scripts inside the store path. Furthermore all scripts have to live in
<literal>$out/share</literal>. An exemplary derivation looks like this:
<programlisting>{ stdenv, fetchurl }: <programlisting>{ stdenv, fetchurl }:
stdenv.mkDerivation { stdenv.mkDerivation {
@ -817,20 +824,26 @@ citrix_receiver.override {
<section xml:id="sec-ibus-typing-booster"> <section xml:id="sec-ibus-typing-booster">
<title>ibus-engines.typing-booster</title> <title>ibus-engines.typing-booster</title>
<para>This package is an ibus-based completion method to speed up typing.</para> <para>
This package is an ibus-based completion method to speed up typing.
</para>
<section xml:id="sec-ibus-typing-booster-activate"> <section xml:id="sec-ibus-typing-booster-activate">
<title>Activating the engine</title> <title>Activating the engine</title>
<para> <para>
IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration IBus needs to be configured accordingly to activate
depends on the desktop manager in use. For detailed instructions, please refer to the <literal>typing-booster</literal>. The configuration depends on the desktop
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream docs</link>. manager in use. For detailed instructions, please refer to the
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream
docs</link>.
</para> </para>
<para> <para>
On NixOS you need to explicitly enable <literal>ibus</literal> with given engines On NixOS you need to explicitly enable <literal>ibus</literal> with given
before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved engines before customizing your desktop to use
using the <literal>ibus</literal> module: <literal>typing-booster</literal>. This can be achieved using the
<literal>ibus</literal> module:
<programlisting>{ pkgs, ... }: { <programlisting>{ pkgs, ... }: {
i18n.inputMethod = { i18n.inputMethod = {
enabled = "ibus"; enabled = "ibus";
@ -844,17 +857,20 @@ citrix_receiver.override {
<title>Using custom hunspell dictionaries</title> <title>Using custom hunspell dictionaries</title>
<para> <para>
The IBus engine is based on <literal>hunspell</literal> to support completion in many languages. The IBus engine is based on <literal>hunspell</literal> to support
By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <literal>es-es</literal>, completion in many languages. By default the dictionaries
<literal>it-it</literal>, <literal>sv-se</literal> and <literal>sv-fi</literal> <literal>de-de</literal>, <literal>en-us</literal>,
are in use. To add another dictionary, the package can be overridden like this: <literal>es-es</literal>, <literal>it-it</literal>,
<literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add
another dictionary, the package can be overridden like this:
<programlisting>ibus-engines.typing-booster.override { <programlisting>ibus-engines.typing-booster.override {
langs = [ "de-at" "en-gb" ]; langs = [ "de-at" "en-gb" ];
}</programlisting> }</programlisting>
</para> </para>
<para> <para>
<emphasis>Note: each language passed to <literal>langs</literal> must be an attribute name in <emphasis>Note: each language passed to <literal>langs</literal> must be an
<literal>pkgs.hunspellDicts</literal>.</emphasis> attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
</para> </para>
</section> </section>
@ -862,10 +878,12 @@ citrix_receiver.override {
<title>Built-in emoji picker</title> <title>Built-in emoji picker</title>
<para> <para>
The <literal>ibus-engines.typing-booster</literal> package contains a program The <literal>ibus-engines.typing-booster</literal> package contains a
named <literal>emoji-picker</literal>. To display all emojis correctly, program named <literal>emoji-picker</literal>. To display all emojis
a special font such as <literal>noto-fonts-emoji</literal> is needed: correctly, a special font such as <literal>noto-fonts-emoji</literal> is
needed:
</para> </para>
<para> <para>
On NixOS it can be installed using the following expression: On NixOS it can be installed using the following expression:
<programlisting>{ pkgs, ... }: { <programlisting>{ pkgs, ... }: {