[elpa] externals/ebdb 969c44c 303/350: Small tweaks to README

[Eric Abrahamsen]

branch: externals/ebdb
commit 969c44c9fee7f05003a1d02d3ffd641b27a6ed53
Author: Eric Abrahamsen <address@hidden>
Commit: Eric Abrahamsen <address@hidden>

    Small tweaks to README
    
    * README.org: Various small edits.
---
 README.org | 33 +++++++++++++--------------------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/README.org b/README.org
index a28143e..32c984d 100644
--- a/README.org
+++ b/README.org
@@ -22,8 +22,7 @@ options.
 ** Okay, But What's Cool About It Right Now?
 EBDB as it stands provides a few enhancements over BBDB.
 
-1. Multiple databases. It's possible to load contacts from more than
-   one database.
+1. Multiple databases.
 2. Records are identified by UUID. Combined with multiple database
    support, this means that single records can live in more than one
    database. The loading routine checks for duplicate records and does
@@ -44,23 +43,18 @@ EBDB as it stands provides a few enhancements over BBDB.
    with generic functions can use them to fundamentally alter the
    behavior and appearance of EBDB with very little code, and fairly
    low risk of breakage. Want to prepend the string "Hi my name is "
-   to all the contact names in your *BBDB* buffer? That would be three
+   to all the record names in your EBDB buffer? That would be three
    lines of code.
-7. A native Vcard database class is on its way. A native CardDav
+7. A native vCard database class is on its way. A native CardDav
    database class is following at a significant distance.
 ** What Are the Drawbacks?
 
-Buggy code! Potential data loss! This is still very much alpha. Many
-of the auxiliary packages also haven't been updated to work with the
-new system.
+Buggy code! Potential data loss! This is still very much beta.
 
-Also, many of the customization options are likely to change as the
-package gets through beta to something stable.
-
-Other than that, load and save times are a bit slow, and the database
-persistence file is significantly larger than it was in BBDB. It's
-likely that optimizations can be made to reduce load times, and the
-size of the persistence file.
+Other than that, loading is a bit slow, and the database persistence
+file is significantly larger than it was in BBDB. It's likely that
+optimizations can be made to reduce load times, and the size of the
+persistence file.
 ** I Still Want to Try This, Is There a Migration Scheme?
 Yes, EBDB will read and migrate from a BBDB v3 data file. Actually,
 EBDB preserves the BBDB's old migration routines, so theoretically you
@@ -69,20 +63,19 @@ wouldn't recommend that, though. To migrate:
 
 1. Load the EBDB code while your BBDB customizations are still in
    place -- specifically, the `bbdb-file' option should point to your
-   existing BBDB v3 file.
+   existing BBDB file.
 2. Back up that file.
 3. Set `ebdb-sources' to a non-existent file name, where you'd like to
    keep the new database.
 4. Run `ebdb-load'. You'll be prompted to create the new database, and
    migrate to the new format. It will take a surprisingly long time.
-5. If there were any migration failures, you'll get a "*BBDB
-   Migration*" buffer containing the records which couldn't be
-   migrated. Migration bug reports are very welcome.
+5. If there were any migration failures, you'll get a "BBDB Migration"
+   buffer containing the records which couldn't be migrated. Migration
+   bug reports are very welcome.
 
 Once you're migrated, load MUA interaction by simply requiring the
 relevant libraries, ie ebdb-gnus or ebdb-message. There's no more
 `initialize' or `auto-update-init'.
 
 Many of the customization options have changed: there are fewer of
-them, for a start. Please see ebdb.org (the nascent Info manual), for
-details.
+them, for a start. Please see the manual for details.