Scriptin' MIME

Scriptin' MIME

[Lars Magne Ingebrigtsen]

One thing that occurred to me while I was waking up just now was that
it might be neat to have a TeXinfo-like MIME interface.  Like:

@alternative
@part{text/plain}
This is plain text.
@part{text/enriched}
@charset{iso-8859-1}
This ïs <b>enriched</b>.
@part{image/gif}
@external{~/rms.gif}
@end{alternative}

And so on.  Commands for all the things one wants.  A MIME composition
language.  Of course, one could add a gazillion MIME composition
commands so that people doesn't have to write stuff like that unless
they really want to.

The most common command would be

@externalpart{image/gif}{~/rms.gif}

(Er.  Or something.)

which isn't really more intrusive than the current buttoney approach.

Now, I really like TeXinfo, but I realise that some weird people might
not, so I don't know whether this really is a good idea or not.

And besides, I haven't really woken up properly yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Scriptin' MIME

[Bruce Stephens]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> One thing that occurred to me while I was waking up just now was that
> it might be neat to have a TeXinfo-like MIME interface.  Like:
> 
> @alternative
> @part{text/plain}
> This is plain text.
> @part{text/enriched}
> @charset{iso-8859-1}
> This ïs <b>enriched</b>.
> @part{image/gif}
> @external{~/rms.gif}
> @end{alternative}
> 
> And so on.  Commands for all the things one wants.  A MIME composition
> language.

Which is basically what elm does.  Or did.  I haven't used it for a
while.  MH/nmh also provide something like this.  Perhaps it would be
good to use the same syntax, or something?

Having a scriptable interface is convenient for some applications.
For example, at work we send change requests and patches around to
each other, packaging them in MIME.  For reading it, we use a MUA, but
it's handy to use a script to send them, since the script knows where
to find the change requests and how to produce the patches.

Re: Scriptin' MIME

[Lars Magne Ingebrigtsen]

Bruce Stephens <bruce@cenderis.demon.co.uk> writes:

> Which is basically what elm does.  Or did.  I haven't used it for a
> while.  MH/nmh also provide something like this.  Perhaps it would be
> good to use the same syntax, or something?

Could someone who has used elm or MH give a description of their MIME
composition interfaces? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Scriptin' MIME

[Andi Kleen]

In article <m37lwy5m2e.fsf@sparky.gnus.org>,
Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Now, I really like TeXinfo, but I realise that some weird people might
> not, so I don't know whether this really is a good idea or not.

MH has had something like this for years with mhbuild 
I liked it. Of course it didn't look like texinfo @)

Example:

#<text/enriched
this content will be tagged as text/enriched
#
and this content will be tagged as text/plain
#
#<application/x-patch [this is a patch]
and this content will be tagged as application/x-patch
#audio/basic [silly giggle]  \
          |raw2audio -F < /usr/lib/sounds/giggle.au
#image/gif   [photo of foobar] \
          /home/foobar/lib/picture.gif
#@application/octet-stream; \
          type=tar; \
          conversions=compress [] \
          access-type=anon-ftp; \
          name="gnus.tar.gz"; \
          directory="/pub/emacs/gnus"; \
          site="ftp.gnus.org"




-Andi 

Re: Scriptin' MIME

[Bruce Stephens]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Could someone who has used elm or MH give a description of their MIME
> composition interfaces? 

When I used it (which was years ago), elm's was pretty minimal.  When
you composed a message, you could insert magic lines:

[import rms.png image/x-png]

Something like that, anyway.  I forget the exact syntax.  It was
pretty basic anyway, and not at all what we expect from Gnus.

Someone's already sent an example of MH's syntax.  exmh (a Tcl/Tk
interface onto mh) does its own MIME stuff, but it's also pretty
basic: adding new sections is easy, but editing is next to impossible.
MH's interface is also available, however.

Re: Scriptin' MIME

[Hrvoje Niksic]

IMHO the "scripting" ideas are totally horrible, unless they involve
non-text properties.  I would absolutely hate to have to beware of
message interpreting random text in my message as s&m "attach me"
commands.

The SGML idea is even worse, because it would mean having to type
every `<' and `>' as `&lt;' and `&gt;'.  Or am I missing something?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Mix 2 table spoons sugar with 1 spoon salt.  Put it in a bottle
and stick a fuse into it.  Say "Shit!" when it doesn't detonate.

Re: Scriptin' MIME

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> IMHO the "scripting" ideas are totally horrible, unless they involve
> non-text properties. 

Non-text props save badly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Scriptin' MIME

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > IMHO the "scripting" ideas are totally horrible, unless they involve
> > non-text properties. 
> 
> Non-text props save badly.

I know, but there are ways around that.  format-alist is one way.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
A sadist is a masochist who follows the Golden Rule.

Re: Scriptin' MIME

[Richard Coleman]

> > Which is basically what elm does.  Or did.  I haven't used it for a
> > while.  MH/nmh also provide something like this.  Perhaps it would be
> > good to use the same syntax, or something?
> 
> Could someone who has used elm or MH give a description of their MIME
> composition interfaces? 

I'm the author of nmh.  The translation of MIME composition drafts
is done with a command called mhbuild.  Here is the man page for
it, which explains the syntax.

But I wouldn't necessarily recommend that you do it this way.  The
MH code base is pretty old.  I expect I would do many things
differently, if I was writing this from scratch.

But it does allow the creating of fairly complicated MIME messages.

Richard Coleman (author, nmh)
coleman@math.gatech.edu


NAME
       mhbuild - translate MIME composition draft

SYNOPSIS
       mhbuild file
	    [-list] [-nolist] [-realsize] [-norealsize]
	    [-headers] [-noheaders] [-ebcdicsafe] [-noebcdicsafe]
	    [-rfc934mode] [-norfc934mode] [-verbose] [-noverbose]
	    [-check] [-nocheck] [-version] [-help]

DESCRIPTION
       The mhbuild command will translate a MIME compostion draft
       into a valid MIME message.

       mhbuild	creates  multi-media  messages	as  specified  in
       RFC-2045  thru  RFC-2049.  Currently mhbuild only supports
       encodings in message bodies,  and  does	not  support  the
       encoding of message headers as specified in RFC-2047.

       If  you	specify  the name of the composition file as "-",
       then mhbuild will accept  the  composition  draft  on  the
       standard  input.  If the translation of this input is suc-
       cessful, mhbuild will output the new MIME message  to  the
       standard  output.  This argument must be the last argument
       on the command line.

       Otherwise if the file argument to mhbuild is the name of a
       valid composition file, and the translation is successful,
       mhbuild will replace the orginal file with  the	new  MIME
       message.   It  will rename the original file to start with
       the "," character and end with the string  ".orig",  e.g.,
       if you are editing the file "draft", it will be renamed to
       ",draft.orig".  This allows  you  to  easily  recover  the
       mhbuild input file.


   Listing the Contents
       The `-list' switch tells mhbuild to list the table of con-
       tents associated with the MIME message that is created.

       The `-headers' switch indicates	that  a  one-line  banner
       should  be  displayed  above the listing.  The `-realsize'
       switch tells mhbuild to evaluate  the  "native"	(decoded)
       format of each content prior to listing.  This provides an
       accurate count at the expense of a small  delay.   If  the
       `-verbose'  switch  is present, then the listing will show
       any "extra" information that is present	in  the  message,
       such as comments in the Content-Type header.


   Translating the Composition File
       mhbuild	is essentially a filter to aid in the composition
       of MIME messages.  mhbuild will convert an mhbuild "compo-
       sition  file"  into  a  valid  MIME  message.   A  mhbuild
       "composition file" is just a file  containing  plain  text
       that  is  interspersed  with  various  mhbuild directives.
       When this file is processed by mhbuild, the various direc-
       tives  will  be	expanded  to the appropriate content, and
       will be encoded according  to  the  MIME  standards.   The
       resulting  MIME	message  can  then  be sent by electronic
       mail.

       The formal  syntax  for	a  mhbuild  composition  file  is
       defined	at the end of this document, but the ideas behind
       this format are not complex.  Basically, the body contains
       one  or	more  contents.   A  content consists of either a
       directive, indicated with a "#" as the first character  of
       a  line;  or,  plaintext (one or more lines of text).  The
       continuation character, "\", may be used to enter a single
       directive on more than one line, e.g.,

	    #image/png \
		/home/foobar/junk/picture.png

       There  are  four  kinds	of directives: "type" directives,
       which name the type and subtype of the content; "external-
       type"  directives, which also name the type and subtype of
       the content; the "message"  directive  (#forw),	which  is
       used  to  forward  one  or more messages; and, the "begin"
       directive (#begin), which is used to  create  a	multipart
       content.

       The  "type" directive is used to directly specify the type
       and subtype of a content.  You may only	specify  discrete
       types in this manner (can't specify the types multipart or
       message with this directive).  You may optionally  specify
       the  name  of  a  file containing the contents in "native"
       (decoded) format.  If this filename starts  with  the  "|"
       character,  then  it represents a command to execute whose
       output is captured accordingly.	For example,

	    #audio/basic |raw2audio -F < /usr/lib/sound/giggle.au

       If a filename is not given, mhbuild will look for informa-
       tion  in the user's profile to determine how the different
       contents should be composed.  This is accomplished by con-
       sulting	a  composition	string,  and  executing  it under
       /bin/sh, with the standard output set to the content.   If
       the `-verbose' switch is given, mhbuild will echo any com-
       mands that are used to create contents in this  way.   The
       composition string may contain the following escapes:

	    %a	Insert parameters from directive
	    %f	Insert filename containing content
	    %F	%f, and stdout is not re-directed
	    %s	Insert content subtype
	    %%	Insert character %


       First, mhbuild will look for an entry of the form:

	    mhbuild-compose-<type>/<subtype>

       to  determine  the  command to use to compose the content.
       If this isn't found, mhbuild will look for an entry of the
       form:

	    mhbuild-compose-<type>

       to determine the composition command.

       If this isn't found, mhbuild will complain.

       An example entry might be:

	    mhbuild-compose-audio/basic: record | raw2audio -F

       Because	commands  like	these will vary, depending on the
       display environment used for  login,  composition  strings
       for  different contents should probably be put in the file
       specified by the $MHBUILD environment variable, instead of
       directly in your user profile.

       The  "external-type" directives are used to provide a MIME
       reference to a content, rather than enclosing the contents
       itself  (for instance, by specifying an ftp site).  Hence,
       instead of providing a filename as with	the  type  direc-
       tives,  external-parameters are supplied.  These look like
       regular parameters, so they must be separated accordingly.
       For example,

	    #@application/octet-stream; \
		type=tar; \
		conversions=compress \
		[this is the nmh distribution] \
		name="nmh.tar.gz"; \
		directory="/pub/nmh"; \
		site="ftp.math.gatech.edu"; \
		access-type=anon-ftp; \
		mode="image"

       You must give a description string to separate the content
       parameters from	the  external-parameters  (although  this
       string  may  be empty).	This description string is speci-
       fied by enclosing it within "[]".  These parameters are of
       the form:

	    access-type=  usually anon-ftp or mail-server
	    name=	  filename
	    permission=   read-only or read-write
	    site=	  hostname
	    directory=	  directoryname (optional)
	    mode=	  usually ascii or image (optional)
	    size=	  number of octets
	    server=	  mailbox
	    subject=	  subject to send
	    body=	  command to send for retrieval


       The  "message" directive (#forw) is used to specify a mes-
       sage or group of messages to include.  You may  optionally
       specify	the  name of the folder and which messages are to
       be forwarded.  If a folder is not given,  it  defaults  to
       the current folder.  Similarly, if a message is not given,
       it defaults to the current message.   Hence,  the  message
       directive  is similar to the forw (1) command, except that
       the former uses the MIME rules  for  encapsulation  rather
       than those specified in RFC-934.  For example,

	    #forw +inbox 42 43 99

       If  you	include  a  single  message,  it will be included
       directly as a content of type  "message/rfc822".   If  you
       include	more  than  one  message, then mhbuild will add a
       content of type "multipart/digest" and include  each  mes-
       sage as a subpart of this content.

       If  you	are using this directive to include more than one
       message, you  may  use  the  `-rfc934mode'  switch.   This
       switch  will  indicate that mhbuild should attempt to uti-
       lize the MIME encapsulation rules in such a way	that  the
       "multipart/digest"  that is created is (mostly) compatible
       with the encapsulation specified in  RFC-934.   If  given,
       then RFC-934 compliant user-agents should be able to burst
       the message on reception -- providing  that  the  messages
       being  encapsulated  do	not contain encapsulated messages
       themselves.  The drawback of this  approach  is	that  the
       encapsulations  are  generated by placing an extra newline
       at the end of the body of each message.

       The "begin" directive is used to create a  multipart  con-
       tent.   When using the "begin" directive, you must specify
       at least one content between the begin and end pairs.

	    #begin
	    This will be a multipart with only one part.
	    #end

       If you use multiple directives  in  a  composition  draft,
       mhbuild	will automatically encapsulate them inside a mul-
       tipart content.	Therefore the "begin" directive  is  only
       necessary  if you wish to use nested multiparts, or create
       a multipart message containing only one part.

       For all of these directives, the user may include a  brief
       description  of	the content between the "[" character and
       the "]" character.  This description will be  copied  into
       the "Content-Desciption" header when the directive is pro-
       cessed.

	    #forw [important mail from Bob] +bob 1 2 3 4 5

       By default, mhbuild will generate a  unique  "Content-ID:"
       for each directive; however, the user may override this by
       defining the ID using the "<" and ">" characters.

       In addition to the various directives,  plaintext  can  be
       present.   Plaintext  is  gathered,  until  a directive is
       found or the draft is exhausted, and this is made to  form
       a  text	content.   If the plaintext must contain a "#" at
       the beginning of a line, simply double it, e.g.,

	    ##when sent, this line will start with only one #

       If you want to end the plaintext  prior	to  a  directive,
       e.g.,  to  have	two  plaintext	contents adjacent, simply
       insert a line containing a single "#" character, e.g.,

	    this is the first content
	    #
	    and this is the second

       Finally, if the plaintext starts with a line of the form:

	    Content-Description: text

       then this will be used to describe the plaintext  content.
       You  MUST follow this line with a blank line before start-
       ing your text.

       By default, plaintext is captured as a text/plain content.
       You  can override this by starting the plaintext with "#<"
       followed by a content-type  specification.   For  example,
       e.g.,

	    #<text/enriched
	    this content will be tagged as text/enriched
	    #
	    and this content will be tagged as text/plain
	    #
	    #<application/x-patch [this is a patch]
	    and this content will be tagged as application/x-patch

       Note  that  if  you  use the "#<" plaintext-form, then the
       content-description must be on the same line which identi-
       fies the content type of the plaintext.

       When  composing a text content, you may indicate the rele-
       vant character set by adding the  "charset"  parameter  to
       the directive.

	    #<text/plain; charset=iso-8859-5

       If a text content contains any 8bit characters (characters
       with the high bit set) and the character set is not speci-
       fied  as above, then mhbuild will assume the character set
       is  of  the  type  given  by  the   environment	 variable
       MM_CHARSET.  If this environment variable is not set, then
       the character set will be labeled as "x-unknown".

       If a text content contains only 7bit  characters  and  the
       character  set is not specified as above, then the charac-
       ter set will be labeled as "us-ascii"

       Putting this all together, here is an example  of  a  more
       complicated  message  draft.   The  following  draft  will
       expand into  a  multipart/mixed	message  containing  five
       parts:

	    To: nobody@nowhere.org
	    cc:
	    Subject: Look and listen to me!
	    --------
	    The first part will be text/plain
	    #<text/enriched
	    The second part will be text/enriched
	    #
	    This third part will be text/plain
	    #audio/basic [silly giggle]  \
		|raw2audio -F < /usr/lib/sounds/giggle.au
	    #image/gif	 [photo of foobar] \
				/home/foobar/lib/picture.gif


   Integrity Check
       If mhbuild is given the `-check' switch, then it will also
       associate an integrity check  with  each  "leaf"  content.
       This  will  add a Content-MD5 header field to the content,
       along with the md5 sum of the  unencoded  contents.   This
       may  be used by the receiver of the message to verify that
       the contents of the message were not changed in transport.


   Transfer Encodings
       After  mhbuild  constructs the new MIME message by parsing
       directives, including files, etc., it scans  the  contents
       of  the	message  to  determine which transfer encoding to
       use.  It will check for 8bit data, long lines,  spaces  at
       the  end  of lines, and clashes with multipart boundaries.
       It will then choose a transfer  encoding  appropriate  for
       each content type.

       If  an  integrity check is being associated with each con-
       tent by using  the  `-check'  switch,  then  mhbuild  will
       encode  each content with a transfer encoding, even it the
       content contains only 7bit data.  This is to increase  the
       likelihood that the content is not changed while in trans-
       port.

       The switch `-ebcdicsafe' will cause  mhbuild  to  slightly
       change the way in which it performs the "quoted-printable"
       transfer encoding.  Along with encoding	8bit  characters,
       it will now also encode certain common punctuation charac-
       ters as well.  This slightly reduces  the  readability  of
       the  message, but allows the message to pass more reliably
       through mail gateways which involve the	EBCDIC	character
       encoding.


   Invoking mhbuild
       Typically,  mhbuild  is	invoked  by  the whatnow program.
       This command will expect the body of the draft to be  for-
       matted as an mhbuild composition file.  Once you have com-
       posed this input file using a command such as comp,  repl,
       or forw, you invoke mhbuild at the "What now" prompt with

	    What now? mime

       prior  to  sending  the draft.  This will cause whatnow to
       execute mhbuild to translate  the  composition  file  into
       MIME format.

       It  is  also  possible  to have the whatnow program invoke
       mhbuild automatically when a message is sent.  To do this,
       you must add the line

	    automimeproc: 1

       to your .mh_profile file.

       Finally, you should consider adding this line to your pro-
       file:

	    lproc: show

       This way, if you decide to list after invoking  mime,  the
       command

	    What now? list

       will work as you expect.


   User Environment
       Because the environment in which mhbuild operates may vary
       for a user, mhbuild will look for the environment variable
       $MHBUILD.  If present, this specifies the name of an addi-
       tional user profile which should be read.  Hence,  when	a
       user  logs  in  on  a particular machine, this environment
       variable should be set to refer to a file containing defi-
       nitions useful for that machine.

       Finally,  mhbuild will attempt to consult a global mhbuild
       user profile, e.g.,

	    /home/rcoleman/nmh-bin/etc/mhn.defaults

       if it exists.


   Syntax of Composition Files
       The following is the formal syntax of a mhbuild	"composi-
       tion file".

	       body	    ::=     1*(content | EOL)

	       content	    ::=     directive | plaintext

	       directive    ::=     "#" type "/" subtype
					0*(";" attribute "=" value)
					[ "(" comment ")" ]
					[ "<" id ">" ]
					[ "[" description "]" ]
					[ filename ]
					EOL

				  | "#@" type "/" subtype
					0*(";" attribute "=" value)
					[ "(" comment ")" ]
					[ "<" id ">" ]
					[ "[" description "]" ]
					external-parameters
					EOL

				  | "#forw"
					[ "<" id ">" ]
					[ "[" description "]" ]
					[ "+"folder ] [ 0*msg ]
					EOL

				  | "#begin"
					  [ "<" id ">" ]
					  [ "[" description "]" ]
					  [   "alternative"
					    | "parallel"
					    | something-else	]
					  EOL
					1*body
				    "#end" EOL

	       plaintext    ::=     [ "Content-Description:"
					  description EOL EOL ]
					1*line
				    [ "#" EOL ]

				  | "#<" type "/" subtype
					0*(";" attribute "=" value)
					[ "(" comment ")" ]
					[ "[" description "]" ]
					EOL
					1*line
				    [ "#" EOL ]

	       line	    ::=     "##" text EOL
				    -- interpreted as "#"text EOL
				  | text EOL


FILES
       $HOME/.mh_profile		    The user profile
       $MHBUILD 			    Additional profile entries
       /home/rcoleman/nmh-bin/etc/mhn.defaulSystem default MIME profile entries

PROFILE COMPONENTS
       Path:		    To determine the user's nmh directory
       Current-Folder:	    To find the default current folder
       mhbuild-compose-<typeTemplate for composing contents

SEE ALSO
       mhlist(1), mhshow(1), mhstore(1)
       RFC-934:
	  Proposed Standard for Message Encapsulation,
       RFC-2045:
	  Multipurpose Internet Mail Extensions (MIME) Part One:
	  Format of Internet Message Bodies,
       RFC-2046:
	  Multipurpose Internet Mail Extensions (MIME) Part Two:
	  Media Types,
       RFC-2047:
	  Multipurpose	 Internet  Mail  Extensions  (MIME)  Part
       Three:
	  Message Header Extensions for Non-ASCII Text,
       RFC-2048:
	  Multipurpose Internet Mail Extensions (MIME) Part Four:
	  Registration Procedures,
       RFC-2049:
	  Multipurpose Internet Mail Extensions (MIME) Part Five:
	  Conformance Criteria and Examples.

DEFAULTS
       `-headers'
       `-realsize'
       `-norfc934mode'
       `-nocheck'
       `-noebcdicsafe'
       `-noverbose'

CONTEXT
       If a folder is given, it will become the  current  folder.
       The last message selected will become the current message.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Wow!  I'm impressed bu Gnus' handling of this -- it was rendered
perfectly, without a slightest hint that there was anything MIMEish
about the message.  The Scandinavian and Chinese characters on the
same line in the body and everything.  *gloat*   :-)

Could someone take a quick peek at the message from Kurt in a non-Gnus 
MIME-aware reader and see what it does when presented with a message
that contains only text/plain parts, but with different charsets?

Kurt Swanson <ksw@dna.lth.se> writes:

> But if one places the very same line in the body, sgml-#parts must be
> added manually:

[...]

> Couldn't this be quickly scanned to have #part's automatically added?
> I.e. one starts out with the group default coding and then goes
> through the body until a character not belonging to that coding is
> found - insert #part, and then repeat for that encoding...

Yes, I think MML should do that.  The result will be displayed very
nicely -- seen from Gnus, at least.  :-)

However, if someone (inadvertantly) mixed (*really* mixed) Chinese and 
Scandianvian (for instance, talking about two people who's names
contain characters from two different charsets), then that might
result in that someone (inadvertantly) sending out a really long and
winding MIME message that might be annoying for the non-Gnus recipient 
to receive...

Of course, MML might just ask the user whether to go ahead and
multipart away or not...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> However, if someone (inadvertantly) mixed (*really* mixed) Chinese and
> Scandianvian (for instance, talking about two people who's names contain
> characters from two different charsets), then that might result in that
> someone (inadvertantly) sending out a really long and winding MIME
> message that might be annoying for the non-Gnus recipient to receive...

> Of course, MML might just ask the user whether to go ahead and multipart
> away or not...

"Warning:  Your message contains 37 parts.  Do you really want to send?"

User settable warning limit.  That's what makes the most sense to me, just
like the warnings about lines over 80 columns.

(And as an aside, I am *really* impressed at the new MIME support.  So
impressed that this is literally converting me from a MIME-hater to rather
liking it, if it can do stuff this cool when well-programmed.  It makes me
think that there really isn't anything that wrong with MIME, it's just
that all the existing implementations suck.  Except, finally, one.)

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Matt Armstrong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Wow!  I'm impressed bu Gnus' handling of this -- it was rendered
> perfectly, without a slightest hint that there was anything MIMEish
> about the message.  The Scandinavian and Chinese characters on the
> same line in the body and everything.  *gloat* :-)
> 
> Could someone take a quick peek at the message from Kurt in a non-Gnus 
> MIME-aware reader and see what it does when presented with a message
> that contains only text/plain parts, but with different charsets?

Netscape splits them up into different parts with an HTML-like <hr>
line between them.


-- 
matta

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"KS" == Kurt Swanson writes:

 KS>   Automatic part insertion:

Well, very nice. :-) I take my words back about automatical parts
insertions, _provided_that_ there is an RFC which specifies that some
part should be displayed as a continuation of the line of previous
part (as gnus did when displaying your message). Is it really
documented? If so, then all is fine. Also, gnus should prefer to not
create `automagical' mime parts if it _can_ find a single charset for
the whole part. For example, a message with mixed russian+japanese
seems to fit into japanese mime encoding. So, even if i'm sending this
from a cyrillic environment in Emacs, gnus should prefer to encode the
part with the mixed text using single charset, if available. Thus,
when Emacs will support unicode, gnus will send messages with mixed
chinese+scandinavian text without breaking into parts.

	Best regards, -- Vladimir.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Kurt Swanson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]


Russ Allbery <rra@stanford.edu> writes:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> However, if someone (inadvertantly) mixed (*really* mixed) Chinese and
>> Scandianvian (for instance, talking about two people who's names contain
>> characters from two different charsets), then that might result in that
>> someone (inadvertantly) sending out a really long and winding MIME
>> message that might be annoying for the non-Gnus recipient to receive...

>> Of course, MML might just ask the user whether to go ahead and multipart
>> away or not...

> "Warning:  Your message contains 37 parts.  Do you really want to send?"

> User settable warning limit.  That's what makes the most sense to me, just
> like the warnings about lines over 80 columns.

That sounds like the best solution - allows for experts to pass
through, warns dummies, and (probably) easily incorporates into the
existing structure of controls on message sending.

> (And as an aside, I am *really* impressed at the new MIME support.  So
> impressed that this is literally converting me from a MIME-hater to rather
> liking it, if it can do stuff this cool when well-programmed.  It makes me
> think that there really isn't anything that wrong with MIME, it's just
> that all the existing implementations suck.  Except, finally, one.)

Hear, hear!  I've even stopped saying "quoted-unreadable" and
"mime-encrypted".

Gnus is already, in my experience, the best the extensible,
customizable, self-documenting real-time display mail/news-reader
supporting mime.
-- 
© 1998 Kurt Swanson AB (ksw@dna.lth.se)
.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Michael Harnois]

Did I miss a patch somewhere? When I try to open Kurt's message, I get

Signaling: (wrong-type-argument char-or-string-p nil)
  mm-inline-text((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil))
  mm-display-inline((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil))
  mm-display-part((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil) t)
  byte-code("..." [ignored string-match type throw nil mm-automatic-display-p mm-inlinable-part-p 4 handle "inline" not-attachment t display split-string "/" "text" text gnus-article-mime-handle-alist id gnus-unbuttonized-mime-type-p gnus-article-insert-newline gnus-insert-mime-button move -2 gnus-newsgroup-default-charset gnus-newsgroup-iso-8859-1-forced mm-charset-iso-8859-1-forced rfc2047-default-charset mm-display-part mm-insert-inline mm-get-part] 5)
  gnus-mime-display-single((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil))
  gnus-mime-display-part((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil))
  mapcar(gnus-mime-display-part ((#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil)))
  gnus-mime-display-mixed(((#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil)))
  gnus-mime-display-part(("multipart/mixed" (#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil)))
  gnus-display-mime()
  gnus-article-prepare-display()
  gnus-article-prepare(3464 nil)
  gnus-summary-display-article(3464 nil)
  gnus-summary-select-article(nil nil pseudo)
  gnus-summary-scroll-up(1)
  call-interactively(gnus-summary-scroll-up)

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@willinet.net                      aa0bt@aa0bt.ampr.org 
 Censorship is the strongest drive in human nature; 
 sex is a weak second. -- Phil Kerby

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Wow!  I'm impressed bu Gnus' handling of this -- it was rendered
> perfectly, without a slightest hint that there was anything MIMEish
> about the message.  The Scandinavian and Chinese characters on the
> same line in the body and everything.  *gloat*   :-)

Gloat?  Gloat?!  Gnus gloriously mucks things up when replying to such 
messages!  :-(

When creating reply headers, one should probably simply copy the MIME
stuff, or information tends to get lost.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Q: What's an IBM man-year?
A: 730 people trying to get a project done before noon.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Michael Harnois]

Brain fart. 

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@willinet.net                      aa0bt@aa0bt.ampr.org 
 Censorship is the strongest drive in human nature; 
 sex is a weak second. -- Phil Kerby

Re: Automatic part insertion: åäö and ÔÄû on the same line

[François Pinard]

Russ Allbery <rra@stanford.edu> writes:

> It makes me think that there really isn't anything that wrong with MIME,
> it's just that [almost] all the existing implementations suck.

Exactly my impression, too.  For years, I had the impression that the
worst enemies of MIME are those implementing it. :-)

I'm not really a MIME lover, I find it a bit oldish already, and there are
limitations to it.  However, I think MIME addresses real problems, and
it is nearly the only solution at hand that has a some chance to become
widely accepted.  It is taking really many long years to get there.
I hardly imagine all the time it will take for some next better step! :-)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Automatic part insertion: åäö and ÔÄû on the same line

[Hrvoje Niksic]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> I'm not really a MIME lover, I find it a bit oldish already, and
> there are limitations to it.

Yup.  I wish there were a clean way to say that a MIME part is
gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Reporter: Mr Gandhi, what do you think of Western Civilization?
Gandhi: I think it would be a good idea.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Shenghuo ZHU]

This sounds cool!

>>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VVV> Well, very nice. :-) I take my words back about automatical parts
VVV> insertions, _provided_that_ there is an RFC which specifies that
VVV> some part should be displayed as a continuation of the line of
VVV> previous part (as gnus did when displaying your message). Is it
VVV> really documented? If so, then all is fine. Also, gnus should
VVV> prefer to not create `automagical' mime parts if it _can_ find a
VVV> single charset for the whole part. For example, a message with
VVV> mixed russian+japanese seems to fit into japanese mime
VVV> encoding. So, even if i'm sending this from a cyrillic
VVV> environment in Emacs, gnus should prefer to encode the part with
VVV> the mixed text using single charset, if available. Thus, when
VVV> Emacs will support unicode, gnus will send messages with mixed
VVV> chinese+scandinavian text without breaking into parts.

Does mule use the same (mule) charset for Russian characters in
cyrillic-iso-8bit and japanese-iso-8bit? Possible not. In Gnu Emacs
20.3, cyrillic-iso8859-5 is not safe in japanese-iso-8bit. So I guess,
Gnu Emacs itself can not safely encode cyrillic-iso8859-5 characters
with japanese.

There is a unicode package. But it only support utf-8 in Gnu Emacs.

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Hrvoje Niksic]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> "KS" == Kurt Swanson writes:
> 
>  KS>   Automatic part insertion:
> 
> Well, very nice. :-) I take my words back about automatical parts
> insertions, _provided_that_ there is an RFC which specifies that some
> part should be displayed as a continuation of the line of previous
> part (as gnus did when displaying your message). Is it really
> documented?

Well.  RFC's don't normally specify message rendering.  However, it
*is* documented that the newline preceding the closing boundary is
syntactically a part of the boundary.  Quoth rfc2046:

   The boundary delimiter MUST occur at the beginning of a line, i.e.,
   following a CRLF, and the initial CRLF is considered to be attached
   to the boundary delimiter line rather than part of the preceding
   part.

This implies that this:

--boundary
text
--boundary--

means `text' without newline, while

--boundary
text

--boundary--

means `text
', all with the newline.  So what Gnus does is quite right.  This also
explains why many MIME composers insert seemingly redundant newlines
before the closing boundaries.

But then again, noone can guarantee anything about how others will
display it.  Netscape, for one, displays a horizontal ruler between
the multiparts, and I can't find a good objection to that.

> If so, then all is fine. Also, gnus should prefer to not create
> `automagical' mime parts if it _can_ find a single charset for the
> whole part.

Agreed.  Gnus should try not to use magic if it is at all possible.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

Re: Automatic part insertion: åäö and ÔÄû on the same line

[Richard Coleman]

> > I'm not really a MIME lover, I find it a bit oldish already, and
> > there are limitations to it.
> 
> Yup.  I wish there were a clean way to say that a MIME part is
> gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'.

This has been discussed many times on comp.mail.mime.  There have been
several proposals made, but there is little chance that something like
this will be adopted soon, since:

  1. At this point, it would be virtually impossible to add another
     Content-Transfer-Encoding type.  It would break too many
     existing readers.

  2. Most MIME types that are very large (image/jpeg, video/mpeg,
     etc., already have their own internal compression).

--
Richard Coleman
coleman@math.gatech.edu

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"ZSH" == Shenghuo ZHU writes:

 ZSH> Does mule use the same (mule) charset for Russian characters in
 ZSH> cyrillic-iso-8bit and japanese-iso-8bit? Possible not. In Gnu
 ZSH> Emacs 20.3, cyrillic-iso8859-5 is not safe in
 ZSH> japanese-iso-8bit. So I guess, Gnu Emacs itself can not safely
 ZSH> encode cyrillic-iso8859-5 characters with japanese.

Well, according to mm-mime-mule-charset-alist defined in mm-util.el,
the iso-2022-int-1 charset supports both cyrillic-iso8859-5 and
japanese-* charsets (and much more):

    (iso-2022-int-1 latin-iso8859-1 latin-iso8859-2
		    cyrillic-iso8859-5 greek-iso8859-7
		    latin-jisx0201 japanese-jisx0208-1978
		    chinese-gb2312 japanese-jisx0208
		    korean-ksc5601 japanese-jisx0212
		    chinese-cns11643-1 chinese-cns11643-2
		    chinese-cns11643-3 chinese-cns11643-4
		    chinese-cns11643-5 chinese-cns11643-6
		    chinese-cns11643-7))

So, if gnus finds that the part contains e.g. cyrillic-iso8859-5 and
japanese-* charsets, it should send the whole part (without breaking
it into `automagical' subparts), using the iso-2022-int-1 MIME
charset.

	Best regards, -- Vladimir.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Shenghuo ZHU]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="iso-2022-int-1", Size: 479 bytes --]

>>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VVV> So, if gnus finds that the part contains e.g. cyrillic-iso8859-5 and
VVV> japanese-* charsets, it should send the whole part (without breaking
VVV> it into `automagical' subparts), using the iso-2022-int-1 MIME
VVV> charset.

You are right. This is not multipart mail and not automatically
generated by gnus.

^[-A\x0eedv\x0f and ^[$(A3TDDH{^[(B on the same line

But, do most mailers support iso-2022-int-1?

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

(Sorry about the previous, empty message.)

Matt Armstrong <mattdav+matt@best.com> writes:

> > Could someone take a quick peek at the message from Kurt in a non-Gnus 
> > MIME-aware reader and see what it does when presented with a message
> > that contains only text/plain parts, but with different charsets?
> 
> Netscape splits them up into different parts with an HTML-like <hr>
> line between them.

Ick.  Did the different charsets display OK, though?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

(Sorry about the previous, empty message.)

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> Well, very nice. :-) I take my words back about automatical parts
> insertions, _provided_that_ there is an RFC which specifies that some
> part should be displayed as a continuation of the line of previous
> part (as gnus did when displaying your message).

Quoth RFC2046:

   NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

> Also, gnus should prefer to not create `automagical' mime parts if
> it _can_ find a single charset for the whole part. For example, a
> message with mixed russian+japanese seems to fit into japanese mime
> encoding. So, even if i'm sending this from a cyrillic environment
> in Emacs, gnus should prefer to encode the part with the mixed text
> using single charset, if available. Thus, when Emacs will support
> unicode, gnus will send messages with mixed chinese+scandinavian
> text without breaking into parts.

I don't really know about this one.  If I'm composing a message using
Scandianvian and Sami characters (which would be iso-8859-1 and
iso-8859-9 if I'm responsing to someone using iso-8859-9,) I want to
respons using iso-8859-9 and iso-8859-1, not Unicode, no matter
whether Emacs supports it or not.  What's important is what the
recipient supports, and one can't assume that the recipient supports
these megacharsets.

MIME is widely implemented, if (ahum) slightly shakily here and
there.  Unicode is not.  So it's better to Mimetilate a message than
to Unicodelate the messege.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> "Warning:  Your message contains 37 parts.  Do you really want to send?"

I've added this, but only when the user hasn't typed any <#part>
thingies.  So no multiparts should happen without anyone being
notified, but the multipartedness of the thing might be more
impressive than anticipated.

> (And as an aside, I am *really* impressed at the new MIME support.  So
> impressed that this is literally converting me from a MIME-hater to rather
> liking it, if it can do stuff this cool when well-programmed.  It makes me
> think that there really isn't anything that wrong with MIME, it's just
> that all the existing implementations suck.  Except, finally, one.)

It's easy to become giddy with the possibilities new, er, stuff
presents one with.  I can imagine Netscape programmers enthusing about 
<BLINK>: "Hey!  We can blink now!  Neat!  Blink!"

But I must say that I'm enjoying MIME much more than I thought I would
be.  It's not pretty or elegant, but it works, and is flexible and
extensible.  And one can implement interfaces that makes the whole
thing, like, go away, and just leave is with purty images and purty
characters from different countries and stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"LMI" == Lars Magne Ingebrigtsen writes:

 LMI> Quoth RFC2046:

thanks. gnus now supports empty lines in mime almost fine, but it
seems to be a bit more `aggressive' in:

* ignoring empty lines in MIME parts when displaying. e.g the message
  which started this thread contained in the last part:

>  --==-=-=
>  Content-Type: text/plain; charset=iso-8859-1
>  Content-Transfer-Encoding: 8bit
>
>
>
>  Couldn't this be quickly scanned to have #part's automatically added?
>  I.e. one starts out with the group default coding and then goes

i.e., as i understand, gnus should have leaved two empty lines before
the last paragraph when displaying the message, but it showed only one
empty line.

* putting some extra empty lines in MIME when composing
  messages. E.g. if i create a text/plain us-ascii part, gnus puts two
  or three empty lines after part boundary, instead of just one.

 LMI> I don't really know about this one.  If I'm composing a message
 LMI> using Scandianvian and Sami characters (which would be
 LMI> iso-8859-1 and iso-8859-9 if I'm responsing to someone using
 LMI> iso-8859-9,) I want to respons using iso-8859-9 and iso-8859-1,
 LMI> not Unicode, no matter whether Emacs supports it or not.  What's
 LMI> important is what the recipient supports, and one can't assume
 LMI> that the recipient supports these megacharsets.

 LMI> MIME is widely implemented, if (ahum) slightly shakily here and
 LMI> there.  Unicode is not.  So it's better to Mimetilate a message
 LMI> than to Unicodelate the messege.

Well, maybe, gnus should decide how to behave in these situations
based on the mm-mime-mule-charset-alist? i.e., you can just remove
unicode line from that list (if it were there), but someone else would
want to leave it there? So, gnus should _first_ look in the
mm-mime-mule-charset-alist, and try to encode the whole part with a
single charset, and _if_ it could not find a single charset, only then
it should try to insert automagical parts?

	Best regards, -- Vladimir.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> But, do most mailers support iso-2022-int-1?

Which reminds me -- does anyone have a reference to something (say, a
web site or whatever) that has a good overview of charset issues?
Things like this ("Is iso-2022-int-1 supported by anything but
Emacs?") is something I wonder about from time to time...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > Netscape splits them up into different parts with an HTML-like <hr>
> > line between them.
> 
> Ick. Did the different charsets display OK, though?

Not for me.

I can't get my netscape to react on charset's in the article at all --
it always displays everything with the default character set. If I
change the default character set to japanese, I get japanse signs in
Kurt's article. That's horrible.

If I select GB2312 as my default encoding I get the same behaviour as
iso-8859-1 in my netscape, so I guess it's less than optimal.

A picture at <URL:http://www.pdc.kth.se/~jas/netscape.png>.

(Netscape 4.5. Against a IMAP server which provides correct MIME
information on the article parts.)

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"ZSH" == Shenghuo ZHU writes:

 ZSH> You are right. This is not multipart mail and not automatically
 ZSH> generated by gnus.

But how did you manage to send it with pgnus, though? :-) I get the
following error:

Signaling: (error "Can't encode a part with several charsets.  Insert a .")
  signal(error ("Can't encode a part with several charsets.  Insert a ."))
  error("Can't encode a part with several charsets.  Insert a .")
  mml-insert-mime-headers((part (type . "text/plain") (contents . #("Hi,\n\n\x8e5\x8e4\x8f6 and \x99d4\xa244\xa47b on the same line\n\n	Best regards, -- Vladimir.\n" 0 5 ... 5 34 ... 34 63 ...))) "text/plain" (latin-iso8859-1 chinese-gb2312) 8bit)
  mml-generate-mime-1((part (type . "text/plain") (contents . #("Hi,\n\n\x8e5\x8e4\x8f6 and \x99d4\xa244\xa47b on the same line\n\n	Best regards, -- Vladimir.\n" 0 5 ... 5 34 ... 34 63 ...))))
  mml-generate-mime()
  message-encode-message-body()
  message-send-mail(nil)
  message-send-via-mail(nil)
  message-send(nil)
  message-send-and-exit(nil)
* call-interactively(message-send-and-exit)

	Best regards, -- Vladimir.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Vladimir Volovich <vvv@vvv.vsu.ru> writes:
> 
> > Well, very nice. :-) I take my words back about automatical parts
> > insertions, _provided_that_ there is an RFC which specifies that some
> > part should be displayed as a continuation of the line of previous
> > part (as gnus did when displaying your message).
> 
> Quoth RFC2046:
> 
>    NOTE:  The CRLF preceding the boundary delimiter line is conceptually
>    attached to the boundary so that it is possible to have a part that
>    does not end with a CRLF (line  break).  Body parts that must be
>    considered to end with line breaks, therefore, must have two CRLFs
>    preceding the boundary delimiter line, the first of which is part of
>    the preceding body part, and the second of which is part of the
>    encapsulation boundary.

Note, however, that this says nothing about actually *displaying*
multiparts.  Netscape's horizontal ruler is not prohibited by this.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The Lord protects children and fools...  But don't push it.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Hrvoje Niksic]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> >  --==-=-=
> >  Content-Type: text/plain; charset=iso-8859-1
> >  Content-Transfer-Encoding: 8bit
> >
> >
> >
> >  Couldn't this be quickly scanned to have #part's automatically added?
> >  I.e. one starts out with the group default coding and then goes
> 
> i.e., as i understand, gnus should have leaved two empty lines
> before the last paragraph when displaying the message, but it showed
> only one empty line.

I agree.  This looks like a bug.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
A radioactive cat has eighteen half-lives.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Shenghuo ZHU]

>>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VVV> "ZSH" == Shenghuo ZHU writes:
ZSH> You are right. This is not multipart mail and not automatically
ZSH> generated by gnus.

VVV> But how did you manage to send it with pgnus, though? :-) I get the
VVV> following error:

I said it is "not automatically generated by gnus".

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"ZSH" == Shenghuo ZHU writes:

 ZSH> I said it is "not automatically generated by gnus".

Ah, sorry. Then i consider it as a bug that gnus does not use
mm-mime-mule-charset-alist to find a single charset for the MIME part.

And: even with pgnus 0.61 (with automagical additions of mime parts),
i was unable to send a message with the line which is in subject.

i was only able to send a message when 8859-2 and chinese characters
were on different lines.

but again: gnus should use mm-mime-mule-charset-alist first of all,
and try to find parts only if that test fails. if someone does not
want to use iso-2022-int-1 for some combination of mule charsets, then
simply define your own setting of mm-mime-mule-charset-alist.

	Best regards, -- Vladimir.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Could someone take a quick peek at the message from Kurt in a non-Gnus 
> MIME-aware reader and see what it does when presented with a message
> that contains only text/plain parts, but with different charsets?

Outlook Express under Win98:
http://www.cs.cmu.edu/~karl/pgnus/mime-test/chinese.gif
Not pretty.  Viewed as one main part + 2 ISOified text attachments.
The subject has been font-recognized but abused into ISOness, too.

While I'm here...  I'm one of the benighted many who don't see any of
this neat stuff, apparently.  I'm using non-MULE XEmacs 20.4 -- could
some kind soul give me a quick rundown of what would be required to be
fully Gnus/MIME/fonts-capable?  I run RH5.1 Linux (soon to be 5.2)
with the usual bland XFree fonts installed; Do I need a different
XEmacs?  Is there a suitable source for all these fonts?  I've heard
of something called (I think) xfsft; do I need this, and where is it
found?

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> i.e., as i understand, gnus should have leaved two empty lines before
> the last paragraph when displaying the message, but it showed only one
> empty line.

Yes, and that's correct, because the MIME looked like:

  on the same line
  --==-=-=
  Content-Type: text/plain; charset=iso-8859-1
  Content-Transfer-Encoding: 8bit



  Couldn't this be quickly scanned to have #part's automatically added?

So the first newline belonged on the end of the line before the
separator, and then the next one belonged to the final part. 

> Well, maybe, gnus should decide how to behave in these situations
> based on the mm-mime-mule-charset-alist? i.e., you can just remove
> unicode line from that list (if it were there), but someone else would
> want to leave it there? So, gnus should _first_ look in the
> mm-mime-mule-charset-alist, and try to encode the whole part with a
> single charset, and _if_ it could not find a single charset, only then
> it should try to insert automagical parts?

I don't know.  What to do by default depends on how widely implemented 
these other megacharsets are.  I have no idea.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Hrvoje Niksic]

Karl Kleinpaste <karl@justresearch.com> writes:

> While I'm here...  I'm one of the benighted many who don't see any
> of this neat stuff, apparently.  I'm using non-MULE XEmacs 20.4 --
> could some kind soul give me a quick rundown of what would be
> required to be fully Gnus/MIME/fonts-capable?  I run RH5.1 Linux
> (soon to be 5.2) with the usual bland XFree fonts installed; Do I
> need a different XEmacs?

For starters, you need to compile with Mule.  I can't help you about
the fonts.

Good luck!

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
If we get involved in a nuclear war, will the electromagnetic pulses
from exploding bombs damage my videotapes?

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@justresearch.com> writes:

> Outlook Express under Win98:
> http://www.cs.cmu.edu/~karl/pgnus/mime-test/chinese.gif
> Not pretty.  Viewed as one main part + 2 ISOified text attachments.
> The subject has been font-recognized but abused into ISOness, too.

Not very pretty; no.

> While I'm here...  I'm one of the benighted many who don't see any of
> this neat stuff, apparently.  I'm using non-MULE XEmacs 20.4 -- could
> some kind soul give me a quick rundown of what would be required to be
> fully Gnus/MIME/fonts-capable?

You need an Emacs/XEmacs with Mule -- for instance, reconfigure xemacs
20.4 with --with-mule and recompile.

Then you need the intlfonts package.  It's 19Mb of all sorts of
wunnerful fonts.  You can get if from the XEmacs ftp site, or do an
ftpsearch for intlfont.tar.gz (or something similar).

After you have that, you just say
"xset +fp /that/directory; xset +fp rehash" (or something to that
effect). 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> And: even with pgnus 0.61 (with automagical additions of mime parts),
> i was unable to send a message with the line which is in subject.

Hm.

Automatic part insertion: åäö and 

[-- Attachment #2: Type: text/plain, Size: 207 bytes --]

吃哪塞 on the same line

Er...  Yes, it divided up the message buggily.  Fix in Pterodactyl
Gnus v0.62.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Info on Internationalization

[Richard Coleman]

> > But, do most mailers support iso-2022-int-1?
> 
> Which reminds me -- does anyone have a reference to something (say, a
> web site or whatever) that has a good overview of charset issues?
> Things like this ("Is iso-2022-int-1 supported by anything but
> Emacs?") is something I wonder about from time to time...

I got the following information from the IMC mailing list several
months ago.  The IMC website is a good place to look for e-mail
related info.


                                  IMC News
 
New IMC Internationalization Report Available
 
Many mail users need to send messages to people outside their own country,
and mail user agents (MUAs) have to be able to send and receive messages in
an interoperable fashion. To this end, the IMC has released its report on
which standards MUAs should implement in order to be considered
"internationalized". Internationalization is a complex and still-changing
field, and IMC's report should help its members determine what steps they
have to take in order to meet the needs of the widest variety of users. The
report is available at <http://www.imc.org/mail-i18n.html>

--
Richard Coleman
coleman@math.gatech.edu

Re: Info on Internationalization

[Lars Magne Ingebrigtsen]

Richard Coleman <coleman@math.gatech.edu> writes:

> The report is available at <http://www.imc.org/mail-i18n.html>

Quite interesting.  Summary of the document: UTF-8!  UTF-8!  UTF-8!
So, is there any UTF-8 support on the horizon for the Emacsen?

(I found the terminology in the document interesting, though -- they
refer to UFT-8 as a "charset".  Hee hee hee hee!  Ok, they explain
that it's really a CES (character encoding scheme), but it's a charset
anyway.  (Not a character set; that's different.  A charset.  :-)

The document is clearly advocacy, though.  They acknowledge that no
clients have UTF-8 support, but they then go on to say things like
this: 

------
Recommendation: All mail-creating programs created or revised after
January 1, 1999, must be able to create mail using the UTF-8
charset. Another way to say this is that any program created or
revised after January 1, 1999, that cannot create mail using the UTF-8
charset should be considered deficient and lacking in standard
internationalization capabilities. Of course, all mail-creating
programs should try to meet this requirement as early as possible.
------

Lack *this*, IMC!  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "RC" == Richard Coleman <coleman@math.gatech.edu> writes:

RC> report is available at <http://www.imc.org/mail-i18n.html>

I just found some recommendations in the page. Can Gnus do these?

IMC> Sending UTF-8 

IMC> All mail-creating programs created or revised after January 1, 1999,
IMC> must be able to create mail using the UTF-8 charset. Another way to
IMC> say this is that any program created or revised after January 1, 1999,
IMC> that cannot create mail using the UTF-8 charset should be considered
IMC> deficient and lacking in standard internationalization
IMC> capabilities. Of course, all mail-creating programs should try to meet
IMC> this requirement as early as possible.

A deadline. I know a package for Emacs 20.x support UTF-8, which is
decoding/encoding by an external program. Does XEmacs support UTF-8?

IMC> Choosing charsets on creation 

IMC> All mail-creating programs that are controlled by humans should
IMC> allow the sender to choose the charset used to create a message.
IMC> These programs should also give advice to the user about the
IMC> different charsets, such as about the likelihood that the
IMC> recipient will be able to display a particular charset.

Gnus does not allow user choose.

IMC> Specifying languages 

IMC> All body parts that are created with a Content-type header that
IMC> include human-readable text should also include a
IMC> Content-language header. This practice makes it more likely that
IMC> programs that process messages where different languages would
IMC> process differently will process them correctly. Note that the
IMC> MIME media type does not define whether or not the content is
IMC> human-readable, and the Content-language header should be used
IMC> with all types of human-readable content, not just plain text.

Content-language, a header gnus should use.

IMC> Multi-language text 

IMC> All plain text body parts that use UTF-8 and have more than one
IMC> language should use Unicode Language Tags in addition to a
IMC> Content-language header. However, Unicode Language Tags should
IMC> only be used with plain text body parts that have more than one
IMC> language; they should not be used with body parts that have a
IMC> single language, nor should they be used with structured text
IMC> body parts such as those coded with HTML.

Although automagical additions of mime parts are cool, gnus should
allow user choose UTF-8, if support it.

IMC> Displaying UTF-8 

IMC> All mail-displaying programs created or revised after January 1,
IMC> 1999, must be able to display mail that uses the UTF-8 charset.
IMC> Another way to say this is that any program created or revised
IMC> after January 1, 1999, that cannot display mail using the UTF-8
IMC> charset should be considered deficient and lacking in standard
IMC> internationalization capabilities. Of course, all mail-displaying
IMC> programs should try to meet this requirement as early as
IMC> possible.

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Kai.Grossjohann]

Karl Kleinpaste <karl@justresearch.com> writes:

  > While I'm here...  I'm one of the benighted many who don't see any of
  > this neat stuff, apparently.  I'm using non-MULE XEmacs 20.4 -- could
  > some kind soul give me a quick rundown of what would be required to be
  > fully Gnus/MIME/fonts-capable?

That's very simple.  You get the GNU intlfonts package (warning,
large), unpack it and install it using the script given.  Suppose you
install it into /opt/local/lib/X11/fonts/intlfonts.  Then you need to
say

xset fp+ /opt/local/lib/X11/fonts/intlfonts

Maybe +fp (prepend) rather than fp+ (append).  That's it.

You can also put the new directory in XF86config.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Info on Internationalization

[Hrvoje Niksic]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> A deadline. I know a package for Emacs 20.x support UTF-8, which is
> decoding/encoding by an external program. Does XEmacs support UTF-8?

I don't think so.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Personifiers Unite!  You have nothing to lose but Mr. Dignity!

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> The document is clearly advocacy, though.  They acknowledge that
LMI> no clients have UTF-8 support, but they then go on to say things
LMI> like this:

At least, I got some utf-8 (even utf-7) messages. By install
unicode.el in Emacs 20.3, I can read those messages in Gnus.

-- 
Shenghuo

Re: Info on Internationalization

[Richard Coleman]

> Richard Coleman <coleman@math.gatech.edu> writes:
> 
> > The report is available at <http://www.imc.org/mail-i18n.html>
> 
> The document is clearly advocacy, though.  They acknowledge that no
> clients have UTF-8 support, but they then go on to say things like
> this: 
> 
> Recommendation: All mail-creating programs created or revised after
> January 1, 1999, must be able to create mail using the UTF-8
> charset. Another way to say this is that any program created or
> revised after January 1, 1999, that cannot create mail using the UTF-8
> charset should be considered deficient and lacking in standard
> internationalization capabilities. Of course, all mail-creating
> programs should try to meet this requirement as early as possible.

The IMC recommendation to use UTF-8 is probably a good one.  But
their deadline of 1/1/99 is at least 5 years too early.

The report suggests reading through the first few chapters
of the Unicode Report.  That might be a good idea.

--
Richard Coleman
coleman@math.gatech.edu

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Graham Murray]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> That's very simple.  You get the GNU intlfonts package (warning,
> large), unpack it and install it using the script given.  Suppose you
> install it into /opt/local/lib/X11/fonts/intlfonts.  Then you need to
> say

Do you also have to set (or unset) a font in .emacs? I set an
iso8859-1 font in default-frame-alist, so would this prevent
emacs/gnus from choosing a font with the appropriate charset? 

Re: Automatic part insertion: åao and ÔAû on the same line

[Jari Aalto+list.ding]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

|Wed 1998-12-02 Richard Coleman <coleman@math.gatech.edu> list.ding
| > > I'm not really a MIME lover, I find it a bit oldish already, and
| > > there are limitations to it.
| > 
| > Yup.  I wish there were a clean way to say that a MIME part is
| > gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'.
| 
| This has been discussed many times on comp.mail.mime.  There have been
| several proposals made, but there is little chance that something like
| this will be adopted soon, since:
| 
|   1. At this point, it would be virtually impossible to add another
|      Content-Transfer-Encoding type.  It would break too many
|      existing readers.


Hm. Tm used x-gzip like this:
jari


[-- Attachment #2: T.gz --]
[-- Type: application/octet-stream, Size: 6 bytes --]

1 2 3

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Kai.Grossjohann]

Graham Murray <graham@barnowl.demon.co.uk> writes:

  > Do you also have to set (or unset) a font in .emacs? I set an
  > iso8859-1 font in default-frame-alist, so would this prevent
  > emacs/gnus from choosing a font with the appropriate charset? 

Dunno.  I have the following in .Xdefaults

,-----
| Emacs*font:                     KAIFONT
`-----

where KAIFONT is either one of the etl fonts or lucida sans
typewriter.  Chinese works automagically in both cases.  I have no
other Emacs font setup (well, there's the menu bar font but that
doesn't matter does it).

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Info on Internationalization

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> I know a package for Emacs 20.x support UTF-8, which is
> decoding/encoding by an external program.

How is this done?  What does the external program translate utf-8
into? 

> Content-language, a header gnus should use.

Well -- do we really want to prompt the user for what language they
are using?  The information has its uses (for instance, emacspeak
would know which language to speak in), but it's a rather marginally
useful header, and inflicting this pain on a gazillion users is
wrongheaded, in my opinion.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Info on Internationalization

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> At least, I got some utf-8 (even utf-7) messages.

Do you know which mail readers are able to send out utf-8 and utf-7?
(I'm just curious.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Graham Murray <graham@barnowl.demon.co.uk> writes:

> Do you also have to set (or unset) a font in .emacs? I set an
> iso8859-1 font in default-frame-alist, so would this prevent
> emacs/gnus from choosing a font with the appropriate charset? 

I don't think so.  I've done no Emacs charset config thing, and things 
work.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Info on Internationalization

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > I know a package for Emacs 20.x support UTF-8, which is
> > decoding/encoding by an external program.
> 
> How is this done?  What does the external program translate utf-8
> into?

Where can I find unicode.el?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Don't fight it son, confess quickly. If you hold out too long, you
could jeopardize your credit rating."  -- IR officer in _Brazil_

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
>> I know a package for Emacs 20.x support UTF-8, which is
>> decoding/encoding by an external program.

LMI> How is this done?  What does the external program translate utf-8
LMI> into?

External program read and write text in emacs-mule coding system. But
XEmacs does not support emacs-mule. I am thinking about native elisp
implementation. However, the convert table is a bit large.

>> Content-language, a header gnus should use.

LMI> Well -- do we really want to prompt the user for what language
LMI> they are using?  The information has its uses (for instance,
LMI> emacspeak would know which language to speak in), but it's a
LMI> rather marginally useful header, and inflicting this pain on a
LMI> gazillion users is wrongheaded, in my opinion.

How about using gnus-default-language or checking the charset the
message uses? 

-- 
Shenghuo

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "HH" == Hrvoje Niksic <hniksic@srce.hr> writes:

HH> Where can I find unicode.el?

http://www.cs.ust.hk/~otfried/Mule/


-- 
Shenghuo

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Do you know which mail readers are able to send out utf-8 and
LMI> utf-7?  (I'm just curious.)

I don't know. (Those messages are expired.)

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Simon Josefsson]

Kurt Swanson <ksw@dna.lth.se> writes:

> To get it to work in netscape you need to:
...
> 7. Choose, View->Character Set->Simplified Chinese.

This step should not be necessary and that's why I don't think
netscape "works". The character set is indicated in the article, so
why should I have to tell it manually?

Re: Info on Internationalization

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> External program read and write text in emacs-mule coding system. But
> XEmacs does not support emacs-mule.

What is the emacs-mule coding system, anyway?  Is it just an, er,
binary dump of the internal Emacs MULE representation or something?

> I am thinking about native elisp implementation. However, the
> convert table is a bit large.

Hm.  Well, if there is some program that translates utf-8 to MULE,
then why doesn't Emacs include that code in Emacs proper?

I am on the xemacs-mule@xemacs.org mailing list, which isn't very
active, but has made many things about the XEmacs implementation
clearer to me.  Is there a mailing list used by the Emacs MULE people?

> How about using gnus-default-language or checking the charset the
> message uses? 

Well -- I'm a pretty typical European mail user, I think.  I get mail
in my native language and in English.  What language I respond in
depends mainly on what language people address me in.  The character
set I use for 99.3% of all my messages is iso-8859-1, no matter what
language I respond in.  (Although the English messages often are in
ASCII, but so are some of the more terse Norwegian ones.)

So, for me, I'd have to default to language "en", and correct that
manually to "no" whenever I write Norwegian text.

I see no real tangible benifits to this.  As with the January 1st 1999 
"deadline" for utf-8 support, I think the Content-Language thing is
premature.  Voice-speech mail readers (!) are still rare.  The
Content-Language header can wait until the computer is smart enough to 
figure out (through artificial stupidity) which language I'm typing,
and by that time, the receiver can do the same, which makes the whole
thing moot.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Info on Internationalization

[Shenghuo ZHU]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> What is the emacs-mule coding system, anyway?  Is it just an, er,
LMI> binary dump of the internal Emacs MULE representation or
LMI> something?

When Emacs auto-saves a file, emacs-mule is coding-system-for-write.
In XEmacs, escape-quoted is used.

BTW, I found a message encoded in UTF-8 is sent by Microsoft Outlook
Express 4.71.1712.3. I am not sure whether Outlook Express did it or
other agent converted it.

-- 
Shenghuo

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Vladimir Volovich]

"LMI" == Lars Magne Ingebrigtsen writes:

 LMI> So the first newline belonged on the end of the line before the
 LMI> separator, and then the next one belonged to the final part.

Yup. sorry.

	Best regards, -- Vladimir.

Re: Info on Internationalization

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (I found the terminology in the document interesting, though -- they
> refer to UFT-8 as a "charset".  Hee hee hee hee!  Ok, they explain
> that it's really a CES (character encoding scheme), but it's a charset
> anyway.  (Not a character set; that's different.  A charset.  :-)

I had a similar problem in `recode'.  Users did convince me that since
the UTF-8 encoding scheme is exclusively used with the UCS (Universal
Character Set), it is kind of conceptual overkill to consider a double
layer, and just simpler to take UTF-8 as a charset.  This *is* abusive,
of course, but I now think it is handy to accept it that way.

Also, beware that all UCS related things (Unicode, ISO 10646, UCS-N and
UTF-N) are a religious issue for many people.  It relies to Han unification
(for example, attributing a single code to similar Chinese and Japanese
glyphs), to which many Japanese *strongly* object.

So, any blind UTF-8! UTF-8! UTF-8! attitudes are prone to be very irritating
to some people, and we should be careful about our own attitudes.  Of course,
UTF-8 has its own elegances and various technical merits, which surely appeal
me a lot, but we should never loose sight and perspective that charsets
(or encodings) are there to serve people, and not the other way around.

We surely may discuss at length for Mule or against Mule, which currently
ignores UCS (yet this is in the process of changing).  The FSF choice
favouring Mule was indeed taking a position within a religious fight about
Han unification, and we know that the FSF likes politics :-).  For the
poor little me, Mule is not technically appealing (to put it very mildly!).
However, there are two great qualities I recognise in Mule: the first is the
incredible amount of knowledge and experience which has been melt within it
(especially about input methods), the second is to bring a discording voice
in our Americanized views, remembering us that we should not bulldoze people.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Neil Crellin]

So I installed intlfonts, and turned off standard-display-european,
and was very impressed with how well this worked. But for one thing. 
The summary buffer lines display the subject as:

Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line

despite it appearing correctly in the subject and body in the article buffer.
This is with pgnus 0.76. Am I expecting more than I should, or should
it work in the summary buffer lines as well?

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Dmitry Yaitskov]

Neil Crellin <neilc@wallaby.cc> writes:

> So I installed intlfonts, and turned off standard-display-european,
<snip>

Pardon my ignorance, what *is* intlfonts?

-- 
Cheers,
-Dima.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Kai.Grossjohann]

Dmitry Yaitskov <dimas@home.com> writes:

  > Pardon my ignorance, what *is* intlfonts?

GNU intlfonts is a package of X11 fonts for all kinds of languages.
Get it from any ftp.gnu.org mirror.

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Lars Magne Ingebrigtsen]

Neil Crellin <neilc@wallaby.cc> writes:

> So I installed intlfonts, and turned off standard-display-european,
> and was very impressed with how well this worked. But for one thing. 
> The summary buffer lines display the subject as:
> 
> Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line

That's interesting; I haven't seen those in months, now.

Do you start Emacs with --unibyte or fiddle with
enable-multibyte-characters anywhere?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Automatic part insertion: åäö and 吃哪塞 on the same line

[Neil Crellin]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Neil Crellin <neilc@wallaby.cc> writes:
> 
> > So I installed intlfonts, and turned off standard-display-european,
> > and was very impressed with how well this worked. But for one thing. 
> > The summary buffer lines display the subject as:
> > 
> > Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line
> 
> That's interesting; I haven't seen those in months, now.
> 
> Do you start Emacs with --unibyte or fiddle with
> enable-multibyte-characters anywhere?

Nope. Tracked it down tho. I had entered those entries into the cache,
and the cache .overview hadn't been regenerated and was presenting old
wierd crappy subject lines. Easily fixed.

-Neil