Making message/rfc822 boundaries visible

Making message/rfc822 boundaries visible

[Robert Bihlmeyer]

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

Hi,

I finally decided to stop whining, and provide some code. The
following, when put into your .gnus file, will render brackets around
message/rfc822 parts, so you can see where an inlined message begins
and ends. Nesting works out nice, too. Tested under XEmacs 21.1, but
IIRC markers are also provided by FSF Emacsen.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-emacs-lisp, Size: 386 bytes --]

(setf (cadr (assoc "message/rfc822" mm-inline-media-tests))
      'mm-inline-message-bracketed)

(defun mm-inline-message-bracketed (handle)
  (insert ",---\n")
  (let ((end (point-marker)))
    (set-marker-insertion-type end t)
    (mm-inline-message handle)
    (while (< (point) end)
      (insert "| ")
      (beginning-of-line 2))
    (move-marker end nil)
    (insert "`---\n")))

[-- Attachment #3: Type: text/plain, Size: 237 bytes --]


Adapting this to other types which have nonobviouse boundaries is
easy.

        Robbe

-- 
Robert Bihlmeyer       reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>    <http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Making message/rfc822 boundaries visible

[Jack Vinson]

>>>>> "Robbe" == Robert Bihlmeyer <robbe@orcus.priv.at> writes:

Robbe> I finally decided to stop whining, and provide some code. The
Robbe> following, when put into your .gnus file, will render brackets around
Robbe> message/rfc822 parts, so you can see where an inlined message begins
Robbe> and ends. Nesting works out nice, too. Tested under XEmacs 21.1, but
Robbe> IIRC markers are also provided by FSF Emacsen.

What is wrong with setting gnus-inhibit-mime-unbuttonizing to 't?  This
gives me buttons before each part of a mime message.  Ellipses (...) after
a button indicates that it has not been "expanded," either because it is
not inlinable or because my setup keeps it from inlining automatically.

-- 
Jack Vinson
Bart: I will not charge admission to the bathroom. 

Re: Making message/rfc822 boundaries visible

[François Pinard]

Jack Vinson <vinson@unagi.cis.upenn.edu> writes:

> What is wrong with setting gnus-inhibit-mime-unbuttonizing to 't?  This
> gives me buttons before each part of a mime message.

I did not try, but from what I guess this variable does, it might make too
many buttons and disrupt the legibility of a presentation which was meant
to be unified, and make Gnus an uncomfortable reader.  For an excrutiating
example, you might try `C-h h' in Emacs, and mail the generated output
buffer to yourself.  Having nearly 50 spurious buttons in the display of
the message you will get breaks the overall intent of the original mailing.

MIME was meant, by design, for a unified presentation.  MIME acquired a
bad reputation after many people implemented it with their own opinion
about what MIME should have been, rather than grasping what it really is.
Such distance is doomed to generate uncomfortable readers.  Adding buttons
all over is just not in the spirit of MIME.  Buttons are some kind of last
resort, when MIME rendering just cannot be completed as it was meant to be.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Making message/rfc822 boundaries visible

[Kai Großjohann]

François Pinard <pinard@iro.umontreal.ca> writes:

> Buttons are some kind of last resort, when MIME rendering just
> cannot be completed as it was meant to be.

I think buttons (or icons) are an appropriate visualization for
attachments.

kai
-- 
Life is hard and then you die.

Re: Making message/rfc822 boundaries visible

[Jack Vinson]

>>>>> "FP" == François Pinard <pinard@iro.umontreal.ca> writes: For an
FP> excrutiating example, you might try `C-h h' in Emacs, and mail the
FP> generated output buffer to yourself.

Wow.  HELLO has 56 parts.  Gnus asks if you really want to send it.  Then
Gnus dies when you try to send it  (pgnus 0.97) because it "Can't encode a
part with several charsets."  This also happens if you try to attach the
file as any kind of text.  Attaching as binary works because it gets
encoded.

Jack 

Any interest in the backtrace?  Here she comes:

Signaling: (error "Can't encode a part with several charsets.")
  signal(error ("Can't encode a part with several charsets."))
  error("Can't encode a part with several charsets.")
  mml-insert-mime-headers((part (type . "text/plain") (contents . "\x7c000, ")) "text/plain" (nil devanagari) quoted-printable)
  mml-generate-mime-1((part (type . "text/plain") (contents . "\x7c000, ")))
  mml-generate-mime-1((multipart (type . "mixed") (part (type . "text/plain") (contents . "TEXT FROM HELLO FILE"))))
  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)

Re: Making message/rfc822 boundaries visible

[Toby Speight]

Jack> Jack Vinson <URL:mailto:vinson@unagi.cis.upenn.edu>

0> In article <wkpuylr1iw.fsf@chevax.ecs.umass.edu>, Jack wrote:

Jack> Wow.  HELLO has 56 parts.  Gnus asks if you really want to send
Jack> it.  Then Gnus dies when you try to send it (pgnus 0.97) because
Jack> it "Can't encode a part with several charsets."

I get this too (47 parts, fails encoding Thai, rather than Devanagari
as yours does).  I'm suprised it doesn't offer to encode it in UTF-8 -
is my installation of unicode.el broken, or is there something else I
need to do?  (I prefer Unicode encodings over most other ones, except
for (single) parts of IS-8859; is there a way to tell Emacs this?
Ideally, I'd like to use whichever of UTF-8 and UTF-16 gives the
shortest output.)

Re: Making message/rfc822 boundaries visible

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> I get this too (47 parts, fails encoding Thai, rather than Devanagari
> as yours does).  I'm suprised it doesn't offer to encode it in UTF-8 -
> is my installation of unicode.el broken, or is there something else I
> need to do?

Gnus just encodes the Mule charsets.  If you make utf-8 the preferred
encoding of all the charsets, then Gnus will encode it as utf-8.

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

Re: Making message/rfc822 boundaries visible

[Florian Weimer]

Jack Vinson <vinson@unagi.cis.upenn.edu> writes:

> Wow.  HELLO has 56 parts.  Gnus asks if you really want to send it.  Then
> Gnus dies when you try to send it  (pgnus 0.97) because it "Can't encode a
> part with several charsets."

That's the right thing to do, until there's UTF-8 support in Gnus.

Re: Making message/rfc822 boundaries visible

[François Pinard]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:

> Jack Vinson <vinson@unagi.cis.upenn.edu> writes:

> > Wow.  HELLO has 56 parts.  Gnus asks if you really want to send it.  Then
> > Gnus dies when you try to send it  (pgnus 0.97) because it "Can't encode a
> > part with several charsets."

> That's the right thing to do, until there's UTF-8 support in Gnus.

Gnus is meant to create as many parts as necessary, on the fly.  But sadly,
I too get "Can't encode a part with several charsets." with the HELLO file.
I'm still using 0.95, but I think it used to work in some earlier version.
When I send simpler multi-charsets files, Gnus 0.95 usually does the proper
thing.  So there are some failing conditions in HELLO, yet the poor little
me would need time investigate them (I do not understand Mule programming).

It is true that in many cases, UTF-8 support would allow for a single
MIME part for everything, indeed.  In other cases, UTF-8 would not convey
distinctions that Asian do want to make, or might not be convenient in some
environments.  We should not start thinking that UTF-8 solves everything.
Too many of us have that strange belief, it is more hope than knowledge! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Making message/rfc822 boundaries visible

[Florian Weimer]

François Pinard <pinard@iro.umontreal.ca> writes:

> Gnus is meant to create as many parts as necessary, on the fly.  But
> sadly, I too get "Can't encode a part with several charsets." with
> the HELLO file.

The composed characters in Hindi and Lao cause the problems.  I thought
several charsets in one line would be required to encode this file
(which isn't true, but can be handled using UTF-8).

> It is true that in many cases, UTF-8 support would allow for a single
> MIME part for everything, indeed.  In other cases, UTF-8 would not convey
> distinctions that Asian do want to make,

The main problem with Unicode was that in the official manual, only
Chinese glyphs were printed, which extremly annoyed some Japanese people
(who, on the other hand, are used to write short Chinese citations in
Japanese text using the Japanese glyphs ;).

Re: Making message/rfc822 boundaries visible

[Toby Speight]

Florian> Florian Weimer <URL:mailto:fw@deneb.cygnus.argh.org>

0> In article <87yad7ls79.fsf@deneb.cygnus.argh.org>, Florian wrote:

Florian> François Pinard <pinard@iro.umontreal.ca> writes:

>> It is true that in many cases, UTF-8 support would allow for a
>> single MIME part for everything, indeed.  In other cases, UTF-8
>> would not convey distinctions that Asian do want to make,

Florian> The main problem with Unicode was that in the official manual,
Florian> only Chinese glyphs were printed, which extremly annoyed some
Florian> Japanese people (who, on the other hand, are used to write
Florian> short Chinese citations in Japanese text using the Japanese
Florian> glyphs ;).

Shouldn't the Content-Language header be used to select the appropriate
glyphset?  (A longer quotation of course being in a separate part with
it's own MIME headers)

I'm not sure whether the Plane-14 language-tagging characters are a
help or a hindrance here.  They ought not to be used when there's an
external means of indicating language (MIME headers), but they would
help in the generic code-conversion that Emacs does all day.

Re: Making message/rfc822 boundaries visible

[François Pinard]

Florian Weimer <fw@deneb.cygnus.argh.org> écrit:

> The main problem with Unicode was that in the official manual, only
> Chinese glyphs were printed, which extremly annoyed some Japanese people
> (who, on the other hand, are used to write short Chinese citations in
> Japanese text using the Japanese glyphs ;).

I'm surely not in a good position to argue in the place of Asian people,
nor give too much interpretation to their position.  On the other hand,
if they tell me they are not satisfied with Unicode, it would be very
pretentious from me (or from almost any Westerner, in fact) if I started
arguing with them.  They know a great deal better than I do what the matter
is, and so, I'm willing to respect them.

Unicode does not have much technical limitations, nowadays, to handle
more than 16 bits per character.  Yet, this was not the original plan,
and it required some doing to get there.  So, Asian reluctance to Unicode,
which might have started technical, became to be more political over time,
and solving the technical aspects do not fully repair the politics.

Let's face it, Unicode lost its technical virginity for good since it was
first laid out (sic).  People still being much attracted by its "purity"
might not be fully willing to implement all of it, and the simpler parts
of Unicode are just not enough to fit all of the bill.  This yields all
sort of contractual lies: "See all that it will do for you!" to convince
other to embark, followed by some more intimate "I'll do that part which
interest me most, and postpone even thinking about the rest" that soon
becomes a strong incentive to say "You are wrong in what you want", or
even more astonishingly, one step further, "Forget it, this is not Unicode".

Because of my `recode' little tool, it happens that I speak with many
people about charsets.  On the way, I clearly saw that may proponents of
UTF-8 are fanatical enough, that I would myself be very frightening if I
were Asian.  Asian and me have this in common (:-), that we put our culture
long before technical considerations.  I'm far from knowing the story, but
I guess that if Unicode listened better, things would be different today.
Asian probably understood they will be better served by themselves, anyway.

P.S. - Unicode is not a problem for the little me.  French is well supported,
out of the box.  UTF-8 is very elegant, technically, I like it a lot.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Making message/rfc822 boundaries visible

[Lars Magne Ingebrigtsen]

Jack Vinson <vinson@unagi.cis.upenn.edu> writes:

> Wow.  HELLO has 56 parts.  Gnus asks if you really want to send it.  Then
> Gnus dies when you try to send it  (pgnus 0.97) because it "Can't encode a
> part with several charsets."

The problem is with a couple of the charsets that are kinda, er,
weird.  If you remove the, uhm, three offending greetings, then the
rest should go through ok.

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

Re: Making message/rfc822 boundaries visible

[Robert Bihlmeyer]

Hi,

>>>>> On 11 Oct 1999 11:13:34 -0500
>>>>> Jack Vinson <vinson@unagi.cis.upenn.edu> said:

 Jack> What is wrong with setting gnus-inhibit-mime-unbuttonizing to
 Jack> 't? This gives me buttons before each part of a mime message.

I don't want buttons all over the place. Francois has convinced me
that they are normally not necessary. I don't need a button to see
where an inlined image start, I can see it by myself. I can also
usually infer where inlined C/elisp/patches start and end, if I want
to know this at all.

Inlined message/rfc822 parts are of a different kind. The beginning is
visible in some configurations, the end too, in some cases. But I want
some indications where the boundaries are, that work everytime. Seeing
the structure of a double-bounce that has been forwarded to you is not
easy without some help. Buttons are one possibility, my code is
another.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>