Ronan Waide <[EMAIL PROTECTED]> writes:
> On August 10, [EMAIL PROTECTED] said:
>> The current CVS version of bbdb.el has bogusly changed the coding
>> system for .bbdb in Emacs 21 to mule-utf-8. That's not, and never
>> will be, a universal coding system:
>> (memq 'mule-utf-8
>> (find-coding-systems-string (string (make-char 'chinese-gb2312 68 99)
>> (make-char 'chinese-gb2312 58 67))))
>> => nil
I think what Dave is saying is that UTF-8 CANNOT be the right
encoding. No matter what version of Emacs you are talking about,
Unicode or otherwise. That's because some GB2312 characters are not
covered by Unicode. Am I right, Dave?
> ;; iso-2022-7bit should be OK (but not optimal for Emacs, at least --
> ;; emacs-mule would be better) with both Emacs 21 and XEmacs. Emacs
> ;; 22 will really need utf-8-emacs.
Please change the comment, at least :) --- the current CVS Emacs is
going to be 22.1 and it's NOT Unicode Emacs. It DOES have mule-utf-8
encoding in it. Hence the code below breaks things in current CVS
Emacs, as mule-utf-8 is a legal encoding and the file switches from
iso-2022-7bit to mule-utf-8 silently. Hmmm... **I** am using CVS
Emacs and I still have iso-2022-7bit as the encoding of .bbdb. Oh, I
see. I did not bother updating BBDB for a while. On the other hand,
the date stamp seems to be Mar 19. !?!?!?
> (defconst bbdb-file-coding-system (if (fboundp 'coding-system-p)
> (cond ((coding-system-p 'utf-8-emacs)
> 'utf-8-emacs)
> ((coding-system-p 'mule-utf-8)
> 'mule-utf-8)
> (t 'iso-2022-7bit)))
> "Coding system used for reading and writing `bbdb-file'.
> This should not be changed by users.")
>
> The mule-utf-8 stuff was contributed by someone using Emacs 22 (ha,
> and me just ranting about not supporting CVS/unreleased versions)
:)
> Personally I'm leery of touching any of the coding stuff and really
> *would* prefer if it could all be flushed away into a nice tidy pile
> of Unicode without the find-coding-system-for-tying-shoelaces stuff,
> but that's neither here nor that.
It will not. See above. Could be perhaps ask someone who know
something about encodings to look into this? Like Dave? :)
My attitude towards the encodings (in this context) is a bit narrow:
Unless there is some GOOD reason to be able to use something other
than iso-2022-7bit (which appears the all-encompassing encoding, am I
right, Dave?), such as permitting someone use un-Mule
(8-bit-char-only?) Emacs, one should just FIX the encoding and not let
the user pick it. Or put in a warning basically saying that changing
the encoding might make it impossible to save the .bbdb file.
Which brings up a related question: can some sort of limited UNDO be
implemented in the .bbdb database (current session only, maybe?).
This way one can at least undo the changes one at a time and be able
to save the database? Or should one play with the saving mechanism so
that if the file cannot be saved in the current encoding it does
something more intelligent than go to the current default behavior of
offering alternative encodings (say, refuse to write the file if any
characters cannot be encoded... hmmm... that would prevent one from
saving altogether, in bad cases... maybe pick a good encoding AND
rewrite the coding cookie before saving the file... comments?).
--Boris
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/
