doc: Rebalance guix style inputs description.

* doc/guix.texi: It seems that there were two places where styling
rules were declared, and one was vastly outdated.  Only describe
styling rules once instead, and move their specific discussion where
the styling rule is described.

Change-Id: Ic83d4c59e45ed51f63dfe91e624b6f453a800818
Signed-off-by: Ludovic Courtès <ludo@gnu.org>

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