Re: [BBDB] Changelog 2010-04-10
On 2011-04-22 04:39 +0800, Ted Zlatanov wrote: Oh, I see, you want to have a general record category and then filter on that category. Don't call it export-class though. It's just class or category I think. That should be trivial and we can even offer completion based on the categories already specified in the BBDB entries. Then you just need to filter the BBDB entries using a category filter. A `tag' field would seem useful. Leo -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
What's the intention of the DEGREE field?
Hello, As stated in the subject line. I still find the firstname + lastname + degree not able to cover some use cases. For example: Professor Sir (Robert) Brian Heap CBE FRS. vCard has N type that has: surname, given name, additional, prefix, suffix which is more accommodating. Leo -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: BBDB beginners guide?
Brett Presnell presn...@stat.ufl.edu writes: Leo sdl@gmail.com writes: On 2011-04-06 15:22 +0800, Didier Verna wrote: Not everybody agrees with this necessarily. I'm using BBDB much more often on my computers than anywhere else and I'm happy to update them manually from time to time on other devices. Sure. But these users can still use BBDB the way they intend to. Support for an external format doesn't force them to use it. Have to agree with this. I'm a long-time user of BBDB, but it has always been frustrating (and basically impossible) to try to sync information between BBDB and other contact database (essentially only BBDB to other is practical; true syncing just doesn't work). I recently picked up the ancient bbdb-syncml[1] to see if it can be fixed to work reliably. I adjusted it to use bbdb-vcard[2], and fixed some minor issues. Currently a slow sync into an empty syncevolution is working, sync with changes in syncevolution fails because bbdb-vcard currently does not provide a way to to insert records the way I need it -- getting this working shouldn't be a big change, though. In case anybody wants to take a look, it's hosted at gitorious: https://gitorious.org/bbdb-syncml/bbdb-syncml Bernd Footnotes: [1] http://savannah.nongnu.org/projects/bbdb-syncml [2] https://github.com/trebb/bbdb-vcard pgpGycS2nmX3N.pgp Description: PGP signature -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: What's the intention of the DEGREE field?
On Fri Apr 22 2011 Leo wrote: As stated in the subject line. Good catch! The degree field is possibly not named in the best way. For me, the motivation has been in academics (which is a significant part of my bbdb database). Yet I could envision other uses, too. I still find the firstname + lastname + degree not able to cover some use cases. For example: Professor Sir (Robert) Brian Heap CBE FRS. vCard has N type that has: surname, given name, additional, prefix, suffix which is more accommodating. I don't know whether it's worth the effort to break this down in such a fairly complicated way. I guess it's fair to say that most names *can* be broken down into first and last name. When I travel around the world, these are the fields I need to fill out on the forms when entering a country. So whatever someone's name is, he or she knows how to break it down to squeeze it into two such fields. From a rather different perspective, I can say here that I am also maintaining bibtex-mode for GNU Emacs (how am I ending up with all this database modes for Emacs???). BibTeX likewise assumes that names are essentially made out of essentially two pieces, first and last names, though it offers a fair amount of flexiblity to squeeze prefixes and suffixes into its scheme based on first and last names. In that sense, I'd guess it would get rather complicated and probably not worth the effort to have lots of additional fields associated with the name of a person. A rather different question is more related to the BBDB internals. In BDBB, names are entered into a hash table that is used for things like completion (which, by the way, would also become much more complicated if the name consisted of more than two fields). The idea of the degree field has been that it is outside these name-related mechanisms of BBDB. You could say: this is just what note fields are for. Yes, that's right. But then my thinking has been that note fields are normally displayed at the end of each record, which is rather far away. So I thought it would be good to have one field displayed closer to the name. A more generic name for this field would probably be better. Name-additional sounds rather clumsy, but it is kind of what it could be. All these thought are not 100% mature and final. Suggestions welcome! From a different perspective, I want to add that if someone doesn't care about this field, he or she can completely ignore it and should never notice that it is available. Roland -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: What's the intention of the DEGREE field?
On 2011-04-22 23:36 +0800, Roland Winkler wrote: All these thought are not 100% mature and final. Suggestions welcome! From a different perspective, I want to add that if someone doesn't care about this field, he or she can completely ignore it and should never notice that it is available. How about replace DEGREE field with two fields: PREFIX and SUFFIX. They can be ignored if the user doesn't want to use them so in a sense they don't get in the way. And these field names are much more general than DEGREE. Leo -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: What's the intention of the DEGREE field?
* Leo fqy@tznvy.pbz [2011-04-23 03:46:05 +0800]: On 2011-04-22 23:36 +0800, Roland Winkler wrote: All these thought are not 100% mature and final. Suggestions welcome! From a different perspective, I want to add that if someone doesn't care about this field, he or she can completely ignore it and should never notice that it is available. How about replace DEGREE field with two fields: PREFIX and SUFFIX. They can be ignored if the user doesn't want to use them so in a sense they don't get in the way. And these field names are much more general than DEGREE. there can be only one prefix but many suffixes, right? I suggest keeping them in a list where first is the prefix and rest are the suffixes, so that simple records without any prefixes suffixes will have just nil there. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X 11.0.60900031 http://truepeace.org http://thereligionofpeace.com http://palestinefacts.org http://camera.org http://dhimmi.com http://www.PetitionOnline.com/tap12009/ Democrats, get out of my wallet! Republicans, get out of my bedroom! -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: What's the intention of the DEGREE field?
On 2011-04-23 03:52 +0800, Sam Steingold wrote: there can be only one prefix but many suffixes, right? I suggest keeping them in a list where first is the prefix and rest are the suffixes, so that simple records without any prefixes suffixes will have just nil there. There can be many prefixes too, for example, 'Prof. Dr. xx'. Leo -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
TAB should move from field to field
Hello, I have one suggestion. I think making TAB move from field to field is useful. For example, in the following record, assume point at `R'ichard, TAB could move from R - F - m - n - next record Richard Stallman - FSF mail: r...@gnu.org notes: The best hacker, founder of GNU Leo -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: What's the intention of the DEGREE field?
On Sat Apr 23 2011 Leo wrote: On 2011-04-23 03:52 +0800, Sam Steingold wrote: there can be only one prefix but many suffixes, right? I suggest keeping them in a list where first is the prefix and rest are the suffixes, so that simple records without any prefixes suffixes will have just nil there. There can be many prefixes too, for example, 'Prof. Dr. xx'. I am tempted to say that all this can easily become fairly complicated depending on the cultural habits for which you want to use such a scheme, so that at best it will always only make a few people happy. Always the question is not only about storing such information but making practical use of it in a way that is appropriate for the information recorded in such fields. From a different perspective, I want to note that the degree field (which can get a better name) is designed to be a list of strings. So if someone feels the need for keeping name prefixes and/or suffixes in BBDB separate from the names themselves, it is fairly straightforward to develop customized versions of the BBDB display functions to make use of this information in whatever way that matches the user's needs / taste. But I am rather hesitant to implement such a scheme as part of default BBDB. Roland -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
