1 files changed, 38 insertions, 48 deletions

diff --git a/doc/guix.texi b/doc/guix.texi
index 5a6ddf44ad7..70677e24446 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -15994,51 +15994,10 @@ Use @var{host} as the OpenPGP key server when importing a public key.
 @cindex format conventions
 The @command{guix style} command helps users and packagers alike style
 their package definitions and configuration files according to the
-latest fashionable trends.  It can either reformat whole files, with the
-@option{--whole-file} option, or apply specific @dfn{styling rules} to
-individual package definitions.  The command currently provides the
-following styling rules:
-
-@itemize
-@item
-formatting package definitions according to the project's conventions
-(@pxref{Formatting Code});
-
-@item
-rewriting package inputs to the ``new style'', as explained below.
-@end itemize
-
-The way package inputs are written is going through a transition
-(@pxref{package Reference}, for more on package inputs).  Until version
-1.3.0, package inputs were written using the ``old style'', where each
-input was given an explicit label, most of the time the package name:
-
-@lisp
-(package
-  ;; @dots{}
-  ;; The "old style" (deprecated).
-  (inputs `(("libunistring" ,libunistring)
-            ("libffi" ,libffi))))
-@end lisp
-
-Today, the old style is deprecated and the preferred style looks like
-this:
-
-@lisp
-(package
-  ;; @dots{}
-  ;; The "new style".
-  (inputs (list libunistring libffi)))
-@end lisp
-
-Likewise, uses of @code{alist-delete} and friends to manipulate inputs
-is now deprecated in favor of @code{modify-inputs} (@pxref{Defining
-Package Variants}, for more info on @code{modify-inputs}).
-
-In the vast majority of cases, this is a purely mechanical change on the
-surface syntax that does not even incur a package rebuild.  Running
-@command{guix style -S inputs} can do that for you, whether you're working on
-packages in Guix proper or in an external channel.
+latest fashionable trends, or patch them with specific rewrites.  It can
+either reformat whole files, with the @option{--whole-file} option, or
+apply specific @dfn{styling rules} to individual package definitions.
+The command provides multiple styling rules, explained below.
 
 The general syntax is:
 
@@ -16101,14 +16060,45 @@ definition of the Coreutils package like so:
 @end example
 
 @item inputs
-Rewrite package inputs to the ``new style'', as described above.  This
-is how you would rewrite inputs of package @code{whatnot} in your own
-channel:
+Rewrite package inputs to the ``new style''. This is how you would
+rewrite inputs of package @code{whatnot} in your own channel:
 
 @example
 guix style -L ~/my/channel -S inputs whatnot
 @end example
 
+The way package inputs are written is going through a transition
+(@pxref{package Reference}, for more on package inputs).  Until version
+1.3.0, package inputs were written using the ``old style'', where each
+input was given an explicit label, most of the time the package name:
+
+@lisp
+(package
+  ;; @dots{}
+  ;; The "old style" (deprecated).
+  (inputs `(("libunistring" ,libunistring)
+            ("libffi" ,libffi))))
+@end lisp
+
+Today, the old style is deprecated and the preferred style looks like
+this:
+
+@lisp
+(package
+  ;; @dots{}
+  ;; The "new style".
+  (inputs (list libunistring libffi)))
+@end lisp
+
+Likewise, uses of @code{alist-delete} and friends to manipulate inputs
+is now deprecated in favor of @code{modify-inputs} (@pxref{Defining
+Package Variants}, for more info on @code{modify-inputs}).
+
+In the vast majority of cases, this is a purely mechanical change on the
+surface syntax that does not even incur a package rebuild.  Running
+@command{guix style -S inputs} can do that for you, whether you're working on
+packages in Guix proper or in an external channel.
+
 Rewriting is done in a conservative way: preserving comments and bailing
 out if it cannot make sense of the code that appears in an inputs field.
 The @option{--input-simplification} option described below provides