Re: [O] Some remarks on org-contacts
"Sebastien Vauban" writes: > And the cherry on the cake would be: snarfing data from received email, asking > the user what to do when a new email address is detected for a known contact, > or a new name detected for a known email address... > > Having those definitely would make org-contacts more powerful than BBDB -- > though, I don't know what's planned in v3 of BBDB. Just for anti-mystification's sake: BBDB has had all of the features you mention for (tens of) years. Štěpán
Re: [O] Some remarks on org-contacts
On Wed, Jun 01 2011, Sven Bretfeld wrote: > - The buffers displaying the contacts file(s) get the "changed mark" > whenever something is done with org-contacts. Even if only a name was > searched and no changes have happened at all. Is it a bug or some > feature that I don't understand? I don't see this behaviour, so I don't think it's related to org-contacts directly. One of the only thing it changes is the last mail seen from a user, when used with Gnus. But a search does not do any modification. > - The last-read-mail property is a good idea, but it has the > disadvantage of changing the file. People using Dropbox or other > synchronization tools have a problem here, because they have to > remember to manually save the file before they start to work on > another computer. There should be an auto-save-hook or something > similar. Sounds dangerous, but you can do it yourself anyhow. > - What I deem most important: For quite a few contacts most people will > use to have more than one email address. Org-contacts stores all > addresses under the same property with no preference on one of them > (unlike BBDB which uses the first entry as a default for completion). > It is annoying to hit tab 3 to 4 times before the To-header is > complete. It would perhaps be best to have only one address in the > EMAIL property and to store alternate addresses in another property > (SECONDARY_EMAIL). The SECONDARY_EMAIL could be called by a special > function that could be set to a key different from TAB (maybe C-u > TAB). Maybe it is even possible to expand to the default address by > hitting TAB once, and to give a list of the other addresses by hitting > TAB once again. The Emacs completion code is not that nice. But using only the first address in EMAIL is doable. > - What can you do with ICONS? Arte they only for chatting? It would be > nice to have a small window automatically opening below an Article > buffer in Gnus that displays information about the author including > his/her image. This properties has been set to be used in `org-contacts' search. Problem is the format in `org-contacts' is not changeable because the way it is written in org.el itself. I've tried to enhance that (there's a branch in the org repository about that) but it's really too much work to me right now, so I abandonned for now that part. > - Email, phone numbers and postal address should be displayed in the > Agenda buffer when a name is searched by org-contacts. Maybe it would > be possible to display different information by hitting certain keys: > "m": mobile-phone, "e": email, "b": birthday, "a": all etc. At the > moment one has to switch on follow-mode to display the information. I > deem this not very beautiful. For my taste, the look-and-feel of an > org-file with lots of property lines is not an aesthetic pleasure. A > tabular output (including a picture of the person) would be much > nicer. That is what was planning, as I stated just above. But this is far from doable right now and would require a major rewrite of some part of Org to be done correctly. -- Julien Danjou ❱ http://julien.danjou.info pgpHnzWXpmFkT.pgp Description: PGP signature
Re: [O] Some remarks on org-contacts
Hi Sven and al, "Sven Bretfeld" wrote: > After some days of using org-contacts with Gnus, I would like to make > some comments. I know that this is an early stage of the development, > but I think some views and suggestions by users could help Julien or > other developers to decide what could be done in the next steps of their > work. There seems to be no roadmap on the homepage of the project. > > - The buffers displaying the contacts file(s) get the "changed mark" > whenever something is done with org-contacts. Even if only a name was > searched and no changes have happened at all. Is it a bug or some > feature that I don't understand? > > - The last-read-mail property is a good idea, but it has the > disadvantage of changing the file. People using Dropbox or other > synchronization tools have a problem here, because they have to > remember to manually save the file before they start to work on > another computer. There should be an auto-save-hook or something > similar. > > - What I deem most important: For quite a few contacts most people will > use to have more than one email address. Org-contacts stores all > addresses under the same property with no preference on one of them > (unlike BBDB which uses the first entry as a default for completion). > It is annoying to hit tab 3 to 4 times before the To-header is > complete. It would perhaps be best to have only one address in the > EMAIL property and to store alternate addresses in another property > (SECONDARY_EMAIL). The SECONDARY_EMAIL could be called by a special > function that could be set to a key different from TAB (maybe C-u > TAB). Maybe it is even possible to expand to the default address by > hitting TAB once, and to give a list of the other addresses by hitting > TAB once again. > > - What can you do with ICONS? Arte they only for chatting? It would be > nice to have a small window automatically opening below an Article > buffer in Gnus that displays information about the author including > his/her image. > > - Email, phone numbers and postal address should be displayed in the > Agenda buffer when a name is searched by org-contacts. Maybe it would > be possible to display different information by hitting certain keys: > "m": mobile-phone, "e": email, "b": birthday, "a": all etc. At the > moment one has to switch on follow-mode to display the information. I > deem this not very beautiful. For my taste, the look-and-feel of an > org-file with lots of property lines is not an aesthetic pleasure. A > tabular output (including a picture of the person) would be much > nicer. > > - There should be a function to sort the entries of the same level in > contacts files alphabetically. > > Thank you very much for org-contacts. And the cherry on the cake would be: snarfing data from received email, asking the user what to do when a new email address is detected for a known contact, or a new name detected for a known email address... Having those definitely would make org-contacts more powerful than BBDB -- though, I don't know what's planned in v3 of BBDB. Best regards, Seb -- Sebastien Vauban
[O] Some remarks on org-contacts
Hi to all After some days of using org-contacts with Gnus, I would like to make some comments. I know that this is an early stage of the development, but I think some views and suggestions by users could help Julien or other developers to decide what could be done in the next steps of their work. There seems to be no roadmap on the homepage of the project. - The buffers displaying the contacts file(s) get the "changed mark" whenever something is done with org-contacts. Even if only a name was searched and no changes have happened at all. Is it a bug or some feature that I don't understand? - The last-read-mail property is a good idea, but it has the disadvantage of changing the file. People using Dropbox or other synchronization tools have a problem here, because they have to remember to manually save the file before they start to work on another computer. There should be an auto-save-hook or something similar. - What I deem most important: For quite a few contacts most people will use to have more than one email address. Org-contacts stores all addresses under the same property with no preference on one of them (unlike BBDB which uses the first entry as a default for completion). It is annoying to hit tab 3 to 4 times before the To-header is complete. It would perhaps be best to have only one address in the EMAIL property and to store alternate addresses in another property (SECONDARY_EMAIL). The SECONDARY_EMAIL could be called by a special function that could be set to a key different from TAB (maybe C-u TAB). Maybe it is even possible to expand to the default address by hitting TAB once, and to give a list of the other addresses by hitting TAB once again. - What can you do with ICONS? Arte they only for chatting? It would be nice to have a small window automatically opening below an Article buffer in Gnus that displays information about the author including his/her image. - Email, phone numbers and postal address should be displayed in the Agenda buffer when a name is searched by org-contacts. Maybe it would be possible to display different information by hitting certain keys: "m": mobile-phone, "e": email, "b": birthday, "a": all etc. At the moment one has to switch on follow-mode to display the information. I deem this not very beautiful. For my taste, the look-and-feel of an org-file with lots of property lines is not an aesthetic pleasure. A tabular output (including a picture of the person) would be much nicer. - There should be a function to sort the entries of the same level in contacts files alphabetically. Thank you very much for org-contacts. Best, Sven
