Re: Unintuitive behaviour with find-file and empty files.

Hi,=20

 Ar an t-ocht=C3=BA l=C3=A1 de m=C3=AD I=C3=BAil, scr=C3=ADobh Stephen J.=
 Turnbull:=20

 > >>>>> "Aidan" =3D=3D Aidan Kehoe <[email protected]> writes:
 >=20
 >     Aidan> At point [3], buffer-file-coding-system is hz-gb-2312, not
 >     Aidan> iso-8859-2, which I, at least, would na=C3=AFvely expect. I=
MHO,
 >     Aidan> this isn't very intuitive behaviour; is there a good reason
 >     Aidan> for it?
 >=20
 > No, although it's not 100% obvious to me that iso-8859-2 is the
 > "right" answer there.

Some coding system that stores every character available would be
preferable? In that case, the documentation for find-file should mention =
it,
I think.=20

 > My guess is just that it's boundary behavior that pretty rarely comes
 > up.  Mule is heavily biased toward guessing right, and not really very
 > friendly to users who know (or think they know) what they're doing.

Hmmm. My experience is that the Mule XEmacs builds that I do myself
invariably initialise default-buffer-file-coding-system to nil, which eve=
n
the documentation (for buffer-file-coding-system) considers inadvisable. =
In
which case you have to know what you're doing, to the extent that you mus=
t
set it to something else.

The reason I'm even trying to learn what I'm doing is that VM's
vm-mail-send-and-exit was double-encoding a mail buffer whose coding syst=
em
was UTF-8. (So, for example, U+00E1 was reaching sendmail as
\303\203\302\241. ) I've fixed it locally, but if I'm going to submit a
decent patch, I should get my head around Mule to some extent.

 > I'll think about fixing it at some point.

Thanks,=20

	- Aidan=20
--=20
I don't care if it rains or freezes/'Long as I got my Plastic Jesus
Riding on the dashboard of my car.