.bbdb getting corrupted by coding system in MULE

Aidan Kehoe kehoea at parhasard.net
Wed Sep 5 09:37:43 EDT 2007


 Ar an cúigiú lá de mí Méan Fómhair, scríobh Michael Sperber: 

 > Thanks for the prompt response!
 > 
 > Aidan Kehoe <kehoea at parhasard.net> writes:
 > 
 > >  Ar an cúigiú lá de mí Méan Fómhair, scríobh Michael Sperber: 
 > >
 > >  > My .bbdb sporadically gets saved in "ISO7", when it's supposed to be
 > >  > "Noconv".
 > >  > 
 > >  > I literally see this happen in front of my eyes:
 > >  > 
 > >  > I edit the .bbdb buffer.  It says "Noconv" in the modeline, then I press
 > >  > C-x C-s, and it switches to "ISO7".  Ideas, anyone?  This is very
 > >  > annoying.
 > >
 > > What value do you have for bbdb-file-coding-system ? 
 > 
 > None so far. :-)  (Didn't even know it existed.)

It’s not a user option; it’s supposed to be constant. 

Now that I look at the code more closely, it will always be nil (=
no-conversion) on non-Mule XEmacs, and iso-2022-7bit on Mule XEmacs.

 > Still, it seems strange that it would get switched spontaneously, and
 > sporadically, as far as I can tell.  (It never happened until maybe
 > three weeks agao.)

You normally don’t use a Mule XEmacs, though, AIUI?

 > > If your data sticks to Latin 1, and you want to share it with a
 > > non-Mule XEmacs, changing it to iso-2022-8 might do what you want.
 > 
 > Just to make sure I understand---why iso-2022-8 and not, say,
 > iso-8859-1?

Because iso-8859-1 will entirely trash iso-8859-15 data, whereas iso-2022-8
will only mostly trash it, such that a mule emacs can read it but
essentially nothing else can. I should move the iso-8859-. coding systems to
using the make-8-bit-coding-system infrastructure to make this less of a
problem.

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)



More information about the XEmacs-Beta mailing list