Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

Eli Zaretskii writes:

> Why, doesn't
> 
>    (coding-system-get FOO :mime-charset)
> 
> work for you, or isn't TRT in this case?

The FOO in this case is a coding-system?  But VM doesn't know what
coding-system to use.  It has to find the coding-system based on the
mime-charset.

It received a string that is encoded in the MIME charset
"iso-8859-8-i".  It tried to find an Emacs coding system that had this
mime-charset property.  But there wasn't any.  So it gave up.  That
was the problem the OP ran into orignally.

Note that (coding-system "iso-8859-8-i" :mime-charset) returns
"iso-8859-8".  

What I am doing now is to see if there is a coding-system with the
same name as the mime-charset.  That works.  So, as long as you
continue to define aliases for coding-systems that correspond to
mime-charset names, we will be fine.

When I don't find a coding-system with the given name, I am using
'undecided, which is what I think you reocmmended.  This at least gets
us out of the unibyte string problem, even though what is produced is
normally gibberish.

> > However, OP reports that the frame title says "bad coding" or some
> > such incantation, even though the buffer name shows up correctly
> > inside Emacs.  Perhaps it is a problem in the interface between Emacs
> > and the OS?
> 
> No, that's our way to defend ourselves against buffer names that are
> unibyte strings, to avoid a crash that was the trigger for this bug.
> If the unibyte buffer name is now solved, the "bad coding" text will
> never show up.

That is what I thought.  But the OP is getting the "bad coding" text
even if a multibyte string is used as the buffer name.  So, perhaps
there is a still problem there.

The problem should show up if you do

(generate-new-buffer "שולח דואר אלקטרוני")

and switch to that buffer Emacs.

(I hope my string makes it through VM + mail-mode without corruption!)

Cheers,
Uday