.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