.bbdb getting corrupted by coding system in MULE

[Jeff Mincy]

   From: Aidan Kehoe <kehoea at parhasard.net>
   Date: Wed, 5 Sep 2007 15:37:43 +0200
   
   
    Ar an c,AC:(Bigi,AC:(B l,AC!(B de m,AC-(B M,AC)(Ban F,AC3(Bmhair, scr,AC-(Bobh Michael Sperber: 
   
    > Thanks for the prompt response!
    > 
    > Aidan Kehoe <kehoea at parhasard.net> writes:
    > 
    > >  Ar an c,AC:(Bigi,AC:(B l,AC!(B de m,AC-(B M,AC)(Ban F,AC3(Bmhair, scr,AC-(Bobh 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.)

bbdb-file-coding-system is used by bbdb-write-file-hook-fn which is
on bbdb-write-file-hooks.

   It,Ab€™(Bs not a user option; it,Ab€™(Bs 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,Ab€™(Bt 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.

Can you look at making bbdb-write-file-hook-fn not smash the coding
line at the top?  After the coding system is smashed the rest of the
.bbdb file gets trashed in various ways.  bbdb-write-file-hook-fn is
very antisocial.  In my .bbdb, I have explicitly set the line to:
  ;; -*-coding: iso-8859-1; Mode: emacs-lisp; truncate-lines:t; flyspell-mode:nil -*-
and the coding line started spontaneously mutating into
  ;; -*-coding: iso-2022-7bit
Yuck.


I fixed this locally by smashing over bbdb-write-file-hook-fn.
I changed
    ;; this always rewrites the coding cookie, which is a bit
    ;; wasteful, but safer than alternatives
    (if (looking-at ";; *-\\*-coding:")
        (delete-region (point) (progn (forward-line) (point))))
    (insert-before-markers (format ";; -*-coding: %s;-*-\n"
                                   bbdb-file-coding-system))
to:
    ;;JWM changed this to not smash the coding cookie line
    ;;Leave existing coding line alone, add a coding line if it is not present.
    (if (not (looking-at ";; *-\\*-coding:"))
        (insert-before-markers (format ";; -*-coding: %s;-*-\n"
                                   bbdb-file-coding-system)))

Also, bbdb-file-coding-system should be user settable.

-jeff