(see also EmacsMuse)
Proposed format for one entry:
Name :: Alex Schroeder
Email :: kensanata@gmail.com
Email :: alex@gnu.org
Phone :: 078 6125175
Address :: Zürich
:: Switzerland
WWW :: http://www.emacswiki.org/alex/
Nick :: kensanata
Notes :: Also maintains [[Oddmuse]] and CommunityWiki.
Speaks German and some French.
FSF and FSFE member, interested in GPL3.
Hangs out on #emacs and #wiki.
:: about?:: Switzerland above. The formatting when I publish such a list to HTML is an extra indent that looks weird to me. Is the idea to continue the current record but provide some format instruction via line breaks?auto-mode-alist, but that’s not a good solution. PlannerMode does it because it is a minor mode. Is there something that can be put in the contact project definition to facilitate this, or a muse hook to use?contacts-create, which would either create a new file for the contact if you like the one-file-per-contact scheme, or add to the global contacts file.No code has been released for this project yet. MichaelOlson is trying to focus on getting Muse 3.03 released first.
AlexSchroeder likes all contacts to be in one file because he likes to use ‘C-s’ and ‘M-x occur’. Every definition would then describe one contact. Text not belonging to a definition list would be comments.
The alternative is to have one contact per file.
JohnSullivan tested with 5000 copies of this record in one file. There was no noticeable delay from the fontification when entering a new record. Publishing did take a few minutes, though. This was done on a 1.2 GHz processor with 512MB RAM.
Still, he is leaning toward one file per contact, with a meta page that calls a Muse function to generate a list of contacts.
MichaelOlson thinks that at least for the case of browsing contacts, it might be possible to support both the all-contacts-on-one-page or one-contact-per-page setups. When asking for a name to browse to, search all files in the Contacts project for a Name field, then make a list of ‘((name page position) …). Perhaps even omit the position and search ahead for “Name ::” on the correct page when a name is chosen.
JimOttaway: It might be useful for some purposes to have several files containing multiple entries: personal, work, students, etc. So perhaps the arrangement of files and entries should be as flexible as possible. By the way, I think this is a marvelous project!
SethFalcon: One advantage of one contact per file is not having to have record delimiters (see questions on format above).
XavierMaillard: it would be cool to have all contacts in one big file. I also want something like a contact log which could be a separate file (each contact log in a different file with sort of a pointer in the contact file).
I also think we should not depend on EmacsMuse to have contact.el but stay as general as possible.
Name :: Xavier Maillard
Email :: zedek@gnu.org
Phone :: +33 (0) 668-046-437
Address :: Reims
:: France
WWW :: http://www.lolica.org
Nick :: zedek
Notes :: President de LoLiCA.
Blah blah blah
Blah blah blah
Blah blah blah
Log :: #hash (eg. 1234567890)
Log would be then a file with file name hash
Contact Log file will be then free-form and independant from contact.el (could be an OrgMode file or an EmacsMuse file or whatever you want).
MichaelOlson is currently in favor of having the result of this spec be called contacts.el. A quick google search does not reveal any other package that uses this name. Functions, variables, and options would be prefixed with contacts-.
MichaelOlson is looking for suggestions on how to handle different kinds of addresses, like Home and Office. Some possibilities follow.
Name :: John Doe
Home ::
Address :: 100 Sample St
:: Tinytown, WY 00000
Phone :: 111-111-1111
Office ::
Address :: BRNG 0000
:: School of Hard Knocks
:: Complete, IN 00010
Phone :: #1111
Name :: John Doe
Address (Home) :: 100 Sample St
:: Tinytown, WY 00000
Phone (Home) :: 111-111-1111
Address (Office) :: BRNG 0000
:: School of Hard Knocks
:: Complete, IN 00010
Phone (Office) :: #1111
I’ve also seen some comment that bbdb’s code is not fun to work with. Is there anything else, really? --BrianPalmer
Reminds me of the format for entries in the FreeSoftwareDirectory? (See sample file entry). – AaronHawley
I would to need write some code to see whether I could make BBDB into the sort of nearly free-form contact management tool I would like to use. That in turn would require me to look into BBDB internals again, which I hesitate to do.
I would also need to write some importing and exporting functions to get it to the point where I can really merge and compare all my contacts on Gmail, Thunderbird, and BBDB. When I worked on the vCard export a while back, I did not enjoy it. See BbdbExporters and Lisp:bbdb-vcard-export.el. This again requires me to look at a lot of BBDB code.
I’m no longer interested in structured information. I guess I could remove practically all fields from BBDB display and input and improve the multiline input to get it to the point I’d like it to be.
Having a package with signed papers would make it a candidate for inclusion into Emacs, too. That is not possible for BBDB, I assume, with JamieZawinski being the original author. – AlexSchroeder
This is a great idea ! For exporting the bbdb→xml convertor works well http://www.cs.utah.edu/~karra/ps94/bbdb-xml-print.el . I recently wrote a style sheet to allow me to create printable “views” of my bbdb database, but having everything integrated into muse would be even better. – ChrisLowis
It would be great if the database code could be made general enough that it would be possible to use it for other kinds of free-form database too. – JimOttaway
YAML might be a source of ideas/inspiration. (http://www.yaml.org/) A lot of work went into making data human-readable yet machine-parseable.
By all means, consider using YAML!. Your contact files will be immediately loadable in native Perl/Python/Ruby… datastructures. Let’s not invet a new minilanguage, YAML is very well thought out and has support for schemas. Contact data do not require mixed content, which makes YAML entirely appropriate. And it can be used for a general plain-text based database system inside Muse, like Jim wants.
YAML Example:
--- !clarkevans.com/^invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments: >
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338.
Who’s going to write the requirsite Gnus hack to provide it the ability to look addresses up in MuseContacts like it currently does in bbdb
--PaulLussier
Has anybody started hacking on MuseContacts or is it just a dead project ?
I would be interested in earing (good) news about this too
--XavierMaillard