* Some remarks on org-contacts
@ 2011-05-31 22:59 Sven Bretfeld
2011-06-01 7:36 ` Sebastien Vauban
2011-06-01 11:59 ` Julien Danjou
0 siblings, 2 replies; 4+ messages in thread
From: Sven Bretfeld @ 2011-05-31 22:59 UTC (permalink / raw)
To: emacs-org
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Some remarks on org-contacts
2011-05-31 22:59 Some remarks on org-contacts Sven Bretfeld
@ 2011-06-01 7:36 ` Sebastien Vauban
2011-06-01 9:41 ` Štěpán Němec
2011-06-01 11:59 ` Julien Danjou
1 sibling, 1 reply; 4+ messages in thread
From: Sebastien Vauban @ 2011-06-01 7:36 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Some remarks on org-contacts
2011-06-01 7:36 ` Sebastien Vauban
@ 2011-06-01 9:41 ` Štěpán Němec
0 siblings, 0 replies; 4+ messages in thread
From: Štěpán Němec @ 2011-06-01 9:41 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
"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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Some remarks on org-contacts
2011-05-31 22:59 Some remarks on org-contacts Sven Bretfeld
2011-06-01 7:36 ` Sebastien Vauban
@ 2011-06-01 11:59 ` Julien Danjou
1 sibling, 0 replies; 4+ messages in thread
From: Julien Danjou @ 2011-06-01 11:59 UTC (permalink / raw)
To: Sven Bretfeld; +Cc: emacs-org
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-06-01 12:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-31 22:59 Some remarks on org-contacts Sven Bretfeld
2011-06-01 7:36 ` Sebastien Vauban
2011-06-01 9:41 ` Štěpán Němec
2011-06-01 11:59 ` Julien Danjou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).