forked from mirrors/nixpkgs
nixpkgs docs: Reformat
This commit is contained in:
Graham Christensen
parent
444e04b985
commit
c07ba7c856
|
|
@ -47,9 +47,10 @@
|
|||
|
||||
<para>
|
||||
In Nixpkgs, these three platforms are defined as attribute sets under the
|
||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and
|
||||
<literal>targetPlatform</literal>. They are always defined as attributes in
|
||||
the standard environment. That means one can access them like:
|
||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
|
||||
and <literal>targetPlatform</literal>. They are always defined as
|
||||
attributes in the standard environment. That means one can access them
|
||||
like:
|
||||
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
|
||||
.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@
|
|||
|
||||
<para>
|
||||
In the <literal>lib/debug.nix</literal> file you will find a number of
|
||||
functions that help (pretty-)printing values while evaluation is runnnig.
|
||||
You can even specify how deep these values should be printed recursively,
|
||||
and transform them on the fly. Please consult the docstrings in
|
||||
functions that help (pretty-)printing values while evaluation is runnnig. You
|
||||
can even specify how deep these values should be printed recursively, and
|
||||
transform them on the fly. Please consult the docstrings in
|
||||
<literal>lib/debug.nix</literal> for usage information.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -30,8 +30,8 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>buildImage</varname> with relative example
|
||||
values are described below:
|
||||
The parameters of <varname>buildImage</varname> with relative example values
|
||||
are described below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-buildImage'>
|
||||
|
|
@ -71,8 +71,8 @@ buildImage {
|
|||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-buildImage-1'>
|
||||
<para>
|
||||
<varname>name</varname> specifies the name of the resulting image. This
|
||||
is the only required argument for <varname>buildImage</varname>.
|
||||
<varname>name</varname> specifies the name of the resulting image. This is
|
||||
the only required argument for <varname>buildImage</varname>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-2'>
|
||||
|
|
@ -84,8 +84,8 @@ buildImage {
|
|||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-3'>
|
||||
<para>
|
||||
<varname>fromImage</varname> is the repository tarball containing the
|
||||
base image. It must be a valid Docker image, such as exported by
|
||||
<varname>fromImage</varname> is the repository tarball containing the base
|
||||
image. It must be a valid Docker image, such as exported by
|
||||
<command>docker save</command>. By default it's <literal>null</literal>,
|
||||
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
||||
<filename>Dockerfile</filename>.
|
||||
|
|
@ -111,10 +111,10 @@ buildImage {
|
|||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-6'>
|
||||
<para>
|
||||
<varname>contents</varname> is a derivation that will be copied in the
|
||||
new layer of the resulting image. This can be similarly seen as
|
||||
<command>ADD contents/ /</command> in a <filename>Dockerfile</filename>.
|
||||
By default it's <literal>null</literal>.
|
||||
<varname>contents</varname> is a derivation that will be copied in the new
|
||||
layer of the resulting image. This can be similarly seen as <command>ADD
|
||||
contents/ /</command> in a <filename>Dockerfile</filename>. By default
|
||||
it's <literal>null</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
||||
|
|
@ -146,9 +146,9 @@ buildImage {
|
|||
<para>
|
||||
After the new layer has been created, its closure (to which
|
||||
<varname>contents</varname>, <varname>config</varname> and
|
||||
<varname>runAsRoot</varname> contribute) will be copied in the layer
|
||||
itself. Only new dependencies that are not already in the existing layers
|
||||
will be copied.
|
||||
<varname>runAsRoot</varname> contribute) will be copied in the layer itself.
|
||||
Only new dependencies that are not already in the existing layers will be
|
||||
copied.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -170,8 +170,8 @@ buildImage {
|
|||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>getProtocolByName: does not exist
|
||||
(no such protocol name: tcp)</literal> you may need to add
|
||||
If you see errors similar to <literal>getProtocolByName: does not exist (no
|
||||
such protocol name: tcp)</literal> you may need to add
|
||||
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
|
@ -187,24 +187,23 @@ buildImage {
|
|||
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
|
||||
<title>Impurely Defining a Docker Layer's Creation Date</title>
|
||||
<para>
|
||||
By default <function>buildImage</function> will use a static
|
||||
date of one second past the UNIX Epoch. This allows
|
||||
<function>buildImage</function> to produce binary reproducible
|
||||
images. When listing images with <command>docker list
|
||||
images</command>, the newly created images will be listed like
|
||||
this:
|
||||
By default <function>buildImage</function> will use a static date of one
|
||||
second past the UNIX Epoch. This allows <function>buildImage</function> to
|
||||
produce binary reproducible images. When listing images with
|
||||
<command>docker list images</command>, the newly created images will be
|
||||
listed like this:
|
||||
</para>
|
||||
<screen><![CDATA[
|
||||
<screen><![CDATA[
|
||||
$ docker image list
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest 08c791c7846e 48 years ago 25.2MB
|
||||
]]></screen>
|
||||
<para>
|
||||
You can break binary reproducibility but have a sorted,
|
||||
meaningful <literal>CREATED</literal> column by setting
|
||||
<literal>created</literal> to <literal>now</literal>.
|
||||
You can break binary reproducibility but have a sorted, meaningful
|
||||
<literal>CREATED</literal> column by setting <literal>created</literal> to
|
||||
<literal>now</literal>.
|
||||
</para>
|
||||
<programlisting><![CDATA[
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildImage {
|
||||
name = "hello";
|
||||
tag = "latest";
|
||||
|
|
@ -215,9 +214,9 @@ pkgs.dockerTools.buildImage {
|
|||
}
|
||||
]]></programlisting>
|
||||
<para>
|
||||
and now the Docker CLI will display a reasonable date and
|
||||
sort the images as expected:
|
||||
<screen><![CDATA[
|
||||
and now the Docker CLI will display a reasonable date and sort the images
|
||||
as expected:
|
||||
<screen><![CDATA[
|
||||
$ docker image list
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest de2bf4786de6 About a minute ago 25.2MB
|
||||
|
|
@ -380,8 +379,8 @@ pkgs.dockerTools.buildLayeredImage {
|
|||
|
||||
<para>
|
||||
If the produced image will not be extended by other Docker builds, it is
|
||||
safe to set <varname>maxLayers</varname> to <literal>128</literal>.
|
||||
However it will be impossible to extend the image further.
|
||||
safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
|
||||
it will be impossible to extend the image further.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -402,10 +401,10 @@ pkgs.dockerTools.buildLayeredImage {
|
|||
<title>pullImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker pull</command> command,
|
||||
in that can be used to pull a Docker image from a Docker registry. By
|
||||
default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is
|
||||
used to pull images.
|
||||
This function is analogous to the <command>docker pull</command> command, in
|
||||
that can be used to pull a Docker image from a Docker registry. By default
|
||||
<link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
|
||||
images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -439,8 +438,8 @@ pullImage {
|
|||
<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
|
||||
<varname>inspect</varname> subcommand. Since a given
|
||||
<varname>imageName</varname> may transparently refer to a manifest list
|
||||
of images which support multiple architectures and/or operating systems,
|
||||
<varname>imageName</varname> may transparently refer to a manifest list of
|
||||
images which support multiple architectures and/or operating systems,
|
||||
supply the `--override-os` and `--override-arch` arguments to specify
|
||||
exactly which image you want. By default it will match the OS and
|
||||
architecture of the host the command is run on.
|
||||
|
|
@ -461,8 +460,8 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
|||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-4'>
|
||||
<para>
|
||||
<varname>sha256</varname> is the checksum of the whole fetched image.
|
||||
This argument is required.
|
||||
<varname>sha256</varname> is the checksum of the whole fetched image. This
|
||||
argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-5'>
|
||||
|
|
@ -485,10 +484,10 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
|||
|
||||
<para>
|
||||
This function is analogous to the <command>docker export</command> command,
|
||||
in that can used to flatten a Docker image that contains multiple layers.
|
||||
It is in fact the result of the merge of all the layers of the image. As
|
||||
such, the result is suitable for being imported in Docker with
|
||||
<command>docker import</command>.
|
||||
in that can used to flatten a Docker image that contains multiple layers. It
|
||||
is in fact the result of the merge of all the layers of the image. As such,
|
||||
the result is suitable for being imported in Docker with <command>docker
|
||||
import</command>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
|
|
@ -517,9 +516,8 @@ exportImage {
|
|||
|
||||
<para>
|
||||
The parameters relative to the base image have the same synopsis as
|
||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except
|
||||
that <varname>fromImage</varname> is the only required argument in this
|
||||
case.
|
||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
|
||||
<varname>fromImage</varname> is the only required argument in this case.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -533,8 +531,8 @@ exportImage {
|
|||
|
||||
<para>
|
||||
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
|
||||
for being used in a <varname>runAsRoot</varname>
|
||||
users and groups, only if such files don't exist already. It is suitable for
|
||||
being used in a <varname>runAsRoot</varname>
|
||||
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
||||
in the example below:
|
||||
</para>
|
||||
|
|
@ -563,4 +561,4 @@ buildImage {
|
|||
manipulate users and groups.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -9,12 +9,11 @@
|
|||
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
||||
<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
|
||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS
|
||||
assumptions, games distributed as tarballs, software with integrity checking
|
||||
and/or external self-updated binaries. It uses Linux namespaces feature to
|
||||
create temporary lightweight environments which are destroyed after all
|
||||
child processes exit, without root user rights requirement. Accepted
|
||||
arguments are:
|
||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
|
||||
games distributed as tarballs, software with integrity checking and/or
|
||||
external self-updated binaries. It uses Linux namespaces feature to create
|
||||
temporary lightweight environments which are destroyed after all child
|
||||
processes exit, without root user rights requirement. Accepted arguments are:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
|
|
@ -57,8 +56,7 @@
|
|||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the directory
|
||||
structure.
|
||||
Additional commands to be executed for finalizing the directory structure.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -109,8 +107,8 @@
|
|||
</variablelist>
|
||||
|
||||
<para>
|
||||
One can create a simple environment using a <literal>shell.nix</literal>
|
||||
like that:
|
||||
One can create a simple environment using a <literal>shell.nix</literal> like
|
||||
that:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
|
|
@ -136,9 +134,9 @@
|
|||
|
||||
<para>
|
||||
Running <literal>nix-shell</literal> would then drop you into a shell with
|
||||
these libraries and binaries available. You can use this to run
|
||||
closed-source applications which expect FHS structure without hassles:
|
||||
simply change <literal>runScript</literal> to the application path, e.g.
|
||||
these libraries and binaries available. You can use this to run closed-source
|
||||
applications which expect FHS structure without hassles: simply change
|
||||
<literal>runScript</literal> to the application path, e.g.
|
||||
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -14,12 +14,11 @@
|
|||
All generators follow a similar call interface: <code>generatorName
|
||||
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
||||
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
|
||||
manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]"
|
||||
] name)</code> from the <literal>INI</literal> generator. It receives the
|
||||
name of a section and sanitizes it. The default
|
||||
<literal>mkSectionName</literal> escapes <literal>[</literal> and
|
||||
<literal>]</literal> with a backslash.
|
||||
They each have common defaults, so often they do not need to be set manually.
|
||||
An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
|
||||
name)</code> from the <literal>INI</literal> generator. It receives the name
|
||||
of a section and sanitizes it. The default <literal>mkSectionName</literal>
|
||||
escapes <literal>[</literal> and <literal>]</literal> with a backslash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -87,4 +86,4 @@ merge:"diff3"
|
|||
Detailed documentation for each generator can be found in
|
||||
<literal>lib/generators.nix</literal>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -81,17 +81,16 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
|||
<note>
|
||||
<para>
|
||||
Note that <varname>separateDebugInfo</varname> is processed only by the
|
||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw
|
||||
Nix derivation. Thus, using <varname>overrideDerivation</varname> will not
|
||||
work in this case, as it overrides only the attributes of the final
|
||||
derivation. It is for this reason that <varname>overrideAttrs</varname>
|
||||
should be preferred in (almost) all cases to
|
||||
<varname>overrideDerivation</varname>, i.e. to allow using
|
||||
<varname>sdenv.mkDerivation</varname> to process input arguments, as well
|
||||
as the fact that it is easier to use (you can use the same attribute names
|
||||
you see in your Nix code, instead of the ones generated (e.g.
|
||||
<varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>,
|
||||
and involves less typing.
|
||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
|
||||
derivation. Thus, using <varname>overrideDerivation</varname> will not work
|
||||
in this case, as it overrides only the attributes of the final derivation.
|
||||
It is for this reason that <varname>overrideAttrs</varname> should be
|
||||
preferred in (almost) all cases to <varname>overrideDerivation</varname>,
|
||||
i.e. to allow using <varname>sdenv.mkDerivation</varname> to process input
|
||||
arguments, as well as the fact that it is easier to use (you can use the
|
||||
same attribute names you see in your Nix code, instead of the ones
|
||||
generated (e.g. <varname>buildInputs</varname> vs
|
||||
<varname>nativeBuildInputs</varname>, and involves less typing.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
|
@ -101,8 +100,8 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
|||
|
||||
<warning>
|
||||
<para>
|
||||
You should prefer <varname>overrideAttrs</varname> in almost all cases,
|
||||
see its documentation for the reasons why.
|
||||
You should prefer <varname>overrideAttrs</varname> in almost all cases, see
|
||||
its documentation for the reasons why.
|
||||
<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
|
||||
<varname>overrideAttrs</varname>.
|
||||
|
|
@ -115,18 +114,17 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
|||
modifying it, which breaks package abstraction and removes error-checking
|
||||
of function arguments. In addition, this evaluation-per-function
|
||||
application incurs a performance penalty, which can become a problem if
|
||||
many overrides are used. It is only intended for ad-hoc customisation,
|
||||
such as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||
many overrides are used. It is only intended for ad-hoc customisation, such
|
||||
as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideDerivation</varname> creates a new derivation
|
||||
based on an existing one by overriding the original's attributes with the
|
||||
attribute set produced by the specified function. This function is
|
||||
available on all derivations defined using the
|
||||
<varname>makeOverridable</varname> function. Most standard
|
||||
derivation-producing functions, such as
|
||||
attribute set produced by the specified function. This function is available
|
||||
on all derivations defined using the <varname>makeOverridable</varname>
|
||||
function. Most standard derivation-producing functions, such as
|
||||
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
||||
which means most packages in the nixpkgs expression,
|
||||
<varname>pkgs</varname>, have this function.
|
||||
|
|
@ -197,9 +195,9 @@ c = lib.makeOverridable f { a = 1; b = 2; };
|
|||
|
||||
<para>
|
||||
The variable <varname>c</varname> however also has some additional
|
||||
functions, like <link linkend="sec-pkg-override">c.override</link> which
|
||||
can be used to override the default arguments. In this example the value of
|
||||
functions, like <link linkend="sec-pkg-override">c.override</link> which can
|
||||
be used to override the default arguments. In this example the value of
|
||||
<varname>(c.override { a = 4; }).result</varname> is 6.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -5,16 +5,15 @@
|
|||
<title>pkgs.mkShell</title>
|
||||
|
||||
<para>
|
||||
<function>pkgs.mkShell</function> is a special kind of derivation
|
||||
that is only useful when using it combined with
|
||||
<command>nix-shell</command>. It will in fact fail to instantiate
|
||||
when invoked with <command>nix-build</command>.
|
||||
<function>pkgs.mkShell</function> is a special kind of derivation that is
|
||||
only useful when using it combined with <command>nix-shell</command>. It will
|
||||
in fact fail to instantiate when invoked with <command>nix-build</command>.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkgs-mkShell-usage">
|
||||
<title>Usage</title>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
pkgs.mkShell {
|
||||
# this will make all the build inputs from hello and gnutar
|
||||
|
|
|
|||
|
|
@ -671,8 +671,9 @@ overrides = self: super: rec {
|
|||
plugins = with availablePlugins; [ python perl ];
|
||||
}
|
||||
}</programlisting>
|
||||
If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal>
|
||||
attribute, <literal>availablePlugins</literal> will be used automatically.
|
||||
If the <literal>configure</literal> function returns an attrset without the
|
||||
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
|
||||
will be used automatically.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -706,9 +707,11 @@ overrides = self: super: rec {
|
|||
}; }
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
WeeChat allows to set defaults on startup using the <literal>--run-command</literal>.
|
||||
The <literal>configure</literal> method can be used to pass commands to the program:
|
||||
WeeChat allows to set defaults on startup using the
|
||||
<literal>--run-command</literal>. The <literal>configure</literal> method
|
||||
can be used to pass commands to the program:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
init = ''
|
||||
|
|
@ -720,9 +723,11 @@ overrides = self: super: rec {
|
|||
Further values can be added to the list of commands when running
|
||||
<literal>weechat --run-command "your-commands"</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>.
|
||||
These will be loaded before the commands from <literal>init</literal>:
|
||||
Additionally it's possible to specify scripts to be loaded when starting
|
||||
<literal>weechat</literal>. These will be loaded before the commands from
|
||||
<literal>init</literal>:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
scripts = with pkgs.weechatScripts; [
|
||||
|
|
@ -734,11 +739,13 @@ overrides = self: super: rec {
|
|||
};
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In <literal>nixpkgs</literal> there's a subpackage which contains derivations for
|
||||
WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute
|
||||
which contains a list of all scripts inside the store path. Furthermore all scripts
|
||||
have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
|
||||
In <literal>nixpkgs</literal> there's a subpackage which contains
|
||||
derivations for WeeChat scripts. Such derivations expect a
|
||||
<literal>passthru.scripts</literal> attribute which contains a list of all
|
||||
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 }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
|
|
@ -817,20 +824,26 @@ citrix_receiver.override {
|
|||
<section xml:id="sec-ibus-typing-booster">
|
||||
<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">
|
||||
<title>Activating the engine</title>
|
||||
|
||||
<para>
|
||||
IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration
|
||||
depends on the desktop 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>.
|
||||
IBus needs to be configured accordingly to activate
|
||||
<literal>typing-booster</literal>. The configuration depends on the desktop
|
||||
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>
|
||||
On NixOS you need to explicitly enable <literal>ibus</literal> with given engines
|
||||
before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved
|
||||
using the <literal>ibus</literal> module:
|
||||
On NixOS you need to explicitly enable <literal>ibus</literal> with given
|
||||
engines before customizing your desktop to use
|
||||
<literal>typing-booster</literal>. This can be achieved using the
|
||||
<literal>ibus</literal> module:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
i18n.inputMethod = {
|
||||
enabled = "ibus";
|
||||
|
|
@ -844,17 +857,20 @@ citrix_receiver.override {
|
|||
<title>Using custom hunspell dictionaries</title>
|
||||
|
||||
<para>
|
||||
The IBus engine is based on <literal>hunspell</literal> to support completion in many languages.
|
||||
By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <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:
|
||||
The IBus engine is based on <literal>hunspell</literal> to support
|
||||
completion in many languages. By default the dictionaries
|
||||
<literal>de-de</literal>, <literal>en-us</literal>,
|
||||
<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 {
|
||||
langs = [ "de-at" "en-gb" ];
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<emphasis>Note: each language passed to <literal>langs</literal> must be an attribute name in
|
||||
<literal>pkgs.hunspellDicts</literal>.</emphasis>
|
||||
<emphasis>Note: each language passed to <literal>langs</literal> must be an
|
||||
attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -862,10 +878,12 @@ citrix_receiver.override {
|
|||
<title>Built-in emoji picker</title>
|
||||
|
||||
<para>
|
||||
The <literal>ibus-engines.typing-booster</literal> package contains a program
|
||||
named <literal>emoji-picker</literal>. To display all emojis correctly,
|
||||
a special font such as <literal>noto-fonts-emoji</literal> is needed:
|
||||
The <literal>ibus-engines.typing-booster</literal> package contains a
|
||||
program named <literal>emoji-picker</literal>. To display all emojis
|
||||
correctly, a special font such as <literal>noto-fonts-emoji</literal> is
|
||||
needed:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On NixOS it can be installed using the following expression:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
|
|
|
|||
Loading…
Reference in a new issue