X-Git-Url: http://git.chise.org/gitweb/?a=blobdiff_plain;f=texi%2Femacs-mime.texi;h=efda9aabd4352403f4d3235f4536a557a790573e;hb=d928b9630b7aad6d0ecf001d02d49bc053116f42;hp=93e1d6ed42d0d245d5d9ef834263a30620a213c2;hpb=c3e1fa9581a5bfd59386b25a438fbb6650441f79;p=elisp%2Fgnus.git-

diff --git a/texi/emacs-mime.texi b/texi/emacs-mime.texi
index 93e1d6e..efda9aa 100644
--- a/texi/emacs-mime.texi
+++ b/texi/emacs-mime.texi
@@ -746,6 +746,7 @@ returned as a result of this analysis.
 * Handles::        Handle manipulations.
 * Display::        Displaying handles.
 * Customization::  Variables that affect display.
+* New Viewers::    How to write your own viewers.
 @end menu
 
 
@@ -898,10 +899,46 @@ library will display it externally (e.g. with @samp{ImageMagick} or
 makes the library display all inline images as inline, regardless of
 their size.
 
+@item mm-inline-override-p
+@code{mm-inlined-types} may include regular expressions, for example to
+specify that all @samp{text/.*} parts be displayed inline.  If a user
+prefers to have a type that matches such a regular expression be treated
+as an attachment, that can be accomplished by setting this variable to a
+list containing that type.  For example assuming @code{mm-inlined-types}
+includes @samp{text/.*}, then including @samp{text/html} in this
+variable will cause @samp{text/html} parts to be treated as attachments.
 
 @end table
 
 
+@node New Viewers
+@section New Viewers
+
+Here's an example viewer for displaying @code{text/enriched} inline:
+
+@lisp
+(defun mm-display-enriched-inline (handle)
+  (let (text)
+    (with-temp-buffer
+      (mm-insert-part handle)
+      (save-window-excursion
+        (enriched-decode (point-min) (point-max))
+        (setq text (buffer-string))))
+    (mm-insert-inline handle text)))
+@end lisp
+
+We see that the function takes a @sc{mime} handle as its parameter.  It
+then goes to a temporary buffer, inserts the text of the part, does some 
+work on the text, stores the result, goes back to the buffer it was
+called from and inserts the result.
+
+The two important helper functions here are @code{mm-insert-part} and
+@code{mm-insert-inline}.  The first function inserts the text of the
+handle in the current buffer.  It handles charset and/or content
+transfer decoding.  The second function just inserts whatever text you
+tell it to insert, but it also sets things up so that the text can be
+``undisplayed' in a convenient manner.
+
 
 @node Composing
 @chapter Composing
@@ -923,6 +960,7 @@ string containing the @sc{mime} message.
 * Simple MML Example::             An example MML document.
 * MML Definition::                 All valid MML elements.
 * Advanced MML Example::           Another example MML document.
+* Charset Translation::            How charsets are mapped from @sc{mule} to MIME.
 * Conversion::                     Going from @sc{mime} to MML and vice versa.
 @end menu
 
@@ -1144,6 +1182,43 @@ This plain text part is an attachment.
 --=-=-=--
 @end example
 
+@node Charset Translation
+@section Charset Translation
+@cindex charsets
+
+During translation from MML to @sc{mime}, for each @sc{mime} part which
+has been composed inside Emacs, an appropriate charset has to be chosen.
+
+@vindex mail-parse-charset
+If you are running a non-@sc{mule} Emacs, this process is simple: If the
+part contains any non-ASCII (8-bit) characters, the @sc{mime} charset
+given by @code{mail-parse-charset} (a symbol) is used.  (Never set this
+variable directly, though.  If you want to change the default charset,
+please consult the documentation of the package which you use to process
+@sc{mime} messages.
+@xref{Various Message Variables, , Various Message Variables, message, 
+      Message Manual}, for example.)
+If there are only ASCII characters, the @sc{mime} charset US-ASCII is
+used, of course.
+
+@cindex MULE
+@cindex UTF-8
+@cindex Unicode
+@vindex mm-mime-mule-charset-alist
+Things are slightly more complicated when running Emacs with @sc{mule}
+support.  In this case, a list of the @sc{mule} charsets used in the
+part is obtained, and the @sc{mule} charsets are translated to @sc{mime}
+charsets by consulting the variable @code{mm-mime-mule-charset-alist}.
+If this results in a single @sc{mime} charset, this is used to encode
+the part.  But if the resulting list of @sc{mime} charsets contains more
+than one element, two things can happen: If it is possible to encode the
+part via UTF-8, this charset is used.  (For this, Emacs must support
+the @code{utf-8} coding system, and the part must consist entirely of
+characters which have Unicode counterparts.)  If UTF-8 is not available
+for some reason, the part is split into several ones, so that each one
+can be encoded with a single @sc{mime} charset.  The part can only be
+split at line boundaries, though---if more than one @sc{mime} charset is
+required to encode a single line, it is not possible to encode the part.
 
 @node Conversion
 @section Conversion
@@ -1179,7 +1254,7 @@ if not identical.
 The Emacs @sc{mime} library implements handling of various elements
 according to a (somewhat) large number of RFCs, drafts and standards
 documents.  This chapter lists the relevant ones.  They can all be
-fetched from @samp{http://www.stud.ifi.uio.no/~larsi/notes/}.
+fetched from @samp{http://quimby.gnus.org/notes/}.
 
 @table @dfn
 @item RFC822