Some remarks on org-contacts

Some remarks on org-contacts

[Sven Bretfeld]

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

Re: Some remarks on org-contacts

[Sebastien Vauban]

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

Re: Some remarks on org-contacts

[Štěpán Němec]

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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: Some remarks on org-contacts

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]