[elpa] externals/ilist 1dc0cea03a 3/5: Update documentations.

[ELPA Syncer]

branch: externals/ilist
commit 1dc0cea03ac314965465355b574ad423f61c8e4b
Author: JSDurand <mmemmew@gmail.com>
Commit: JSDurand <mmemmew@gmail.com>

    Update documentations.
    
    * README.org:
    * ilist.texinfo: Update documentations.
---
 README.org    | 10 +++++++++-
 ilist.texinfo | 45 +++++++++++++++++++++++++++++++++++----------
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/README.org b/README.org
index e00362950d..2c63ba6d9e 100644
--- a/README.org
+++ b/README.org
@@ -151,7 +151,15 @@ experience for users who are fine with the approximation 
provided by
 work with pixels by the variable: =ilist-pixel-precision=.  If this
 variable is not =nil=, the package works with pixels rather than
 characters, and should provide better alignment and truncation.
-  
+
+Moreover, if the value of this variable is the symbol ~precise~, then
+the paddings will use display properties to produce pixel-exact spaces
+so that the alignment is precise and perfect.  See the Info node
+"(elisp) Display Property" for more details.
+
+However, on text terminals, this may not work as expected, as Emacs
+has no control over exact pixels on a text terminal (my guess).
+
 * Mapping over lines
 
 For the convenience of package-users, this package also provides some
diff --git a/ilist.texinfo b/ilist.texinfo
index 5b4e6e461b..128e4074af 100644
--- a/ilist.texinfo
+++ b/ilist.texinfo
@@ -287,6 +287,11 @@ displayed before the group labelled by the second argument.
 @comment  node-name,  next,  previous,  up
 @chapter Pixel precision
 
+@vindex ilist-pixel-precise
+@cindex pixel precision
+@cindex exact
+@cindex padding
+
 Emacs is old, and its age shows from time to time.
 
 As an example, Emacs usually measures lengths of strings by the numbers
@@ -298,16 +303,36 @@ alignment inside tables.
 In the beginning, I used the function @code{string-width} to measure the
 widths of strings, but as its documentation says, this function only
 returns an approximation to the actual width.  This is changed in the
-version @emph{0.2} of the package.
-
-Now the package uses the function @code{string-pixel-width} to measure
-the widths of strings in pixels.  Since working with actual pixels
-requires more computation, and as it does not improve the user
-experience for users who are fine with the approximation provided by
-@code{string-width}, I decide to let the users control whether or not to
-work with pixels by the variable: @samp{ilist-pixel-precision}.  If this
-variable is not @code{nil}, the package works with pixels rather than
-characters, and should provide better alignment and truncation.
+version @emph{0.2} of the package, by the introduction of the variable
+@var{ilist-pixel-precise}.
+
+@table@code
+@item ilist-pixel-precise
+If this variable is not @code{nil}, the package works with pixels rather
+than characters, and should provide better alignment and truncation.  To
+be more detailed, when the variable is not @code{nil}, the package uses
+the function @code{string-pixel-width} to measure the widths of strings
+in pixels.
+
+Since working with actual pixels requires more computation, and as it
+does not improve the user experience for users who are fine with the
+approximation provided by @code{string-width}, the users should
+intentionally set this variable to enable the feature.
+
+Moreover, after version @emph{0.3}, if the value of this variable is the
+symbol @samp{precise}, then the paddings will use display properties to
+produce pixel-exact spaces so that the alignment is precise and perfect.
+See the Info node ``(elisp) Display Property'' for more details.  For
+any other non-nil values, the package uses the function @code{round} to
+calculate the needed number of spaces to pad.  When the number of pixels
+is not a multiple of the number of pixels of a space character, some
+imprecisions will follow.  Therefore it is recommended to set this
+variable to @samp{precise} if the user wants to set it to some non-nil
+value.
+
+However, on text terminals, precise alignment may not work as expected,
+as Emacs has no control over exact pixels on a text terminal (my guess).
+@end table
 
 @node Mapping over lines, Moving, Pixel precision, Top
 @comment  node-name,  next,  previous,  up