Re: [O] org-contacts development
* Alexis wrote:
>
> Hi all,
Hi!
> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE
>
> A search of this list's archives for references to 'org-contacts':
>
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate
>
> suggests that org-contacts is something people are using heavily enough
> that they're writing code, ad-hoc, to provide functionality they
> require, e.g.
>
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html
My current solution:
http://article.gmane.org/gmane.emacs.orgmode/57231/ and
http://article.gmane.org/gmane.emacs.orgmode/75346/
> i'm wondering if it might now be appropriate for org-contacts to become
> part of org-mode proper, rather than simply a contrib, to reduce
> unnecessary duplication of efforts.
Absolutely.
Lacking any standard here, I created my own and meanwhile I do even
generate spam-filters and whitelist items out of my org-contacts
file. Also handy: when I filled out :ITOLDTHEM_EMAIL: my mail client
is using the specified "from"-email-address instead of my normal one
whenever I compose an email to this contact :-)
> Fleshing out an extended spec for org-contacts data could be part of the
> process of making org-contacts a first-class citizen of org-mode, and
> provide a more solid foundation on which people can build (and share)
> the org-contacts functionality they're after. And in my own particular
> case, it would greatly facilitate my work in org-contacts / Android
> Contacts integration. :-)
>
> What do people think?
Absolutely! I copy that.
My current yasnippet for a contact:
,
| # name : Org-contacts template for a person
| # --
| ** $1 $2 :$1$2:
| :PROPERTIES:
| :TYPE: ${3:$$(yas/choose-value '("person" "company"))}
| :TITLE:
| :EMAIL: $4
| :URL:
| :MOBILE: 0043/
| :HOMEPHONE:
| :WORKPHONE:
| :PHONE:
| :COMPANY:
| :STREET:
| :POSTALCODE:
| :CITY:
| :COUNTRY: Österreich
| :PHOTOGRAPH: [[photo:$1$2.jpg]]
| :BORN:
| :ITOLDTHEM_EMAIL:
| :ITOLDTHEM_ADDRESS:
| :ITOLDTHEM_PHONE:
| :ADDRESS_CHANGE_METHOD:
| :END:
|
| - first met at: $0
`
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] org-contacts development
Michael Strey writes: > Hi Daimrod, > > On 2014-05-29, Daimrod wrote: > >> Hmm, I kinda like this. It seems a bit verbose but it's better than >> having multiple values per properties (IMHO). >> >> Though, if we adopt this scheme, we would need to add some helper >> bindings/functions so that we don't have to fill this by hands. > > I'm using yasnippets and have snippets for organizations, job-related > contacts and private contacts. > > I have attached them. Thank you! > C-c C-x p helps to fill in optional properties. > > I have all my contacts in one buffer with the following settings > > > #+BEGIN_SRC org > * Buffer settings > #+STARTUP: overview > #+STARTUP: hidestars > #+STARTUP: indent > #+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s) > #+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFNGER(m) HOCHSCHULE(h) > NETZBETREIBER(n) SYSTEM(y) B2B B2C REG > #+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR > #+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN > #+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c) > #+PROPERTY: Contact_Type_ALL individual organization > #+PROPERTY: Language_ALL de en ru > #+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile > #+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile > #+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile > #+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile > #+PROPERTY: Address_1_Type_ALL Work Home Post > #+PROPERTY: Address_2_Type_ALL Work Home Post > #+PROPERTY: Address_3_Type_ALL Work Home Post > #+PROPERTY: Website_1_Type_ALL Work Home > #+PROPERTY: Website_2_Type_ALL Work Home > #+END_SRC > > > >>> Other user defined properties can be added and mapped to the appropriate >>> user defined keys during export. >> >> I'm not sure to understand what you mean. Could you give more details >> and maybe an example? > > Actually, my statement was trivial. Orgmode allows to define and add > every kind of additional properties. What I wanted to say was that it > is possible to export those additional properties to Google Contacts as > well. Ok. > I have for instance the property :Language: that is not part of the > Google API. I use it to store the preferred language of correspondence > for my job-related contacts for mailing actions. > > Google Contacts accepts such fields in the CSV file to import and > creates user defined fields from them. > > >>> Please note that org-collector tries to convert property values from >>> strings into numbers if possible. For postal codes with leading Zeros >>> this can lead to unexpected results. I did not find any other way to >>> solve this problem than to add a national code like in the following >>> example >>> >>> :Address_1_Code: 01169 >>> would lead to "1169" in the propview table. >>> >>> so I replaced it with >>> :Address_1_Code: DE-01169 >> >> What is `org-collector' and when does it happen? > > From the Orgmode manual: > > "An alternative way to capture and process property values into a table > is provided by Eric Schulte's org-collector.el which is a contributed > package. It provides a general API to collect properties from entries > in a certain scope, and arbitrary Lisp expressions to process these > values before inserting them into a table or a dynamic block." > > I'm using org-collector to create a table that can be exported to CSV > for import into Google Contacts (and maybe other contact managers). Ok, I wasn't aware of this. >> I've done a quick test and the 0 appears in `org-contacts-db'. > > Yes, everything is fine with org-contacts. The problem comes only from > org-collector. The reason is org-collector's feature to allow Lisp > expressions to process property values. Therefore it uses the function > `org-babel-read' that detects Lisp expressions and converts strings into > numbers. > > So this remark is only relevant for those who want to follow my track with the > org-collector export. I see. Thanks for you detailed explanation, I'll look at it more carefully this weekend (hopefully). Best, -- Daimrod/Greg
Re: [O] org-contacts development
Hi Daimrod,
On 2014-05-29, Daimrod wrote:
> Hmm, I kinda like this. It seems a bit verbose but it's better than
> having multiple values per properties (IMHO).
>
> Though, if we adopt this scheme, we would need to add some helper
> bindings/functions so that we don't have to fill this by hands.
I'm using yasnippets and have snippets for organizations, job-related
contacts and private contacts.
I have attached them.
C-c C-x p helps to fill in optional properties.
I have all my contacts in one buffer with the following settings
#+BEGIN_SRC org
* Buffer settings
#+STARTUP: overview
#+STARTUP: hidestars
#+STARTUP: indent
#+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s)
#+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFÄNGER(m) HOCHSCHULE(h)
NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
#+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
#+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
#+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
#+PROPERTY: Contact_Type_ALL individual organization
#+PROPERTY: Language_ALL de en ru
#+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
#+PROPERTY: Address_1_Type_ALL Work Home Post
#+PROPERTY: Address_2_Type_ALL Work Home Post
#+PROPERTY: Address_3_Type_ALL Work Home Post
#+PROPERTY: Website_1_Type_ALL Work Home
#+PROPERTY: Website_2_Type_ALL Work Home
#+END_SRC
>> Other user defined properties can be added and mapped to the appropriate
>> user defined keys during export.
>
> I'm not sure to understand what you mean. Could you give more details
> and maybe an example?
Actually, my statement was trivial. Orgmode allows to define and add
every kind of additional properties. What I wanted to say was that it
is possible to export those additional properties to Google Contacts as
well.
I have for instance the property :Language: that is not part of the
Google API. I use it to store the preferred language of correspondence
for my job-related contacts for mailing actions.
Google Contacts accepts such fields in the CSV file to import and
creates user defined fields from them.
>> Please note that org-collector tries to convert property values from
>> strings into numbers if possible. For postal codes with leading Zeros
>> this can lead to unexpected results. I did not find any other way to
>> solve this problem than to add a national code like in the following
>> example
>>
>> :Address_1_Code: 01169
>> would lead to "1169" in the propview table.
>>
>> so I replaced it with
>> :Address_1_Code: DE-01169
>
> What is `org-collector' and when does it happen?
>From the Orgmode manual:
"An alternative way to capture and process property values into a table
is provided by Eric Schulte's org-collector.el which is a contributed
package. It provides a general API to collect properties from entries
in a certain scope, and arbitrary Lisp expressions to process these
values before inserting them into a table or a dynamic block."
I'm using org-collector to create a table that can be exported to CSV
for import into Google Contacts (and maybe other contact managers).
> I've done a quick test and the 0 appears in `org-contacts-db'.
Yes, everything is fine with org-contacts. The problem comes only from
org-collector. The reason is org-collector's feature to allow Lisp
expressions to process property values. Therefore it uses the function
`org-babel-read' that detects Lisp expressions and converts strings into
numbers.
So this remark is only relevant for those who want to follow my track with the
org-collector export.
--
Michael Strey
www.strey.biz
#name : Contact Individual
#key : contact
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
${1:surname}, ${2:name}
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d")`]
:END:
:PROPERTIES:
:Contact_Type: individual
:Organization_1_Type: company
:Organization_1_Value: ${3:organisation}
:Organization_1_Department: ${4:devision}
:Organization_1_Title: ${5:title}
:FN: $2 $1
:Given_Name: $2
:Family_Name: $1
:Nickname: $19 $1
:Address_1_Type: Work
:Address_1_Street: ${6:adr1}
:Address_1_Box: ${7:adr2}
:Address_1_Extension: ${8:adr3}
:Address_1_City: ${9:city}
:Address_1_Region: ${10:state}
:Address_1_Code: ${11:zip_code}
:Address_1_Country: ${12:country}
:Email_1_Type: Work
:Email_1_Value: ${13:company_email}
:Phone_1_Type: Work
:Phone_1_Value: ${14:tel}
:Phone_2_Type: Mobile
:Phone_2_Value: ${15:mobile}
:Phone_3_Type: Fax
:Phone_3_Value: ${16:fax}
:Website_1_Type: Work
:Website_1_Value: http://$17
:Language: $18
:END:
$0
#name : Contact Individual (private)
#key : privat
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
${1:surname}, ${2:name} :NEW:
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d
Re: [O] org-contacts development
Michael Strey writes: Hi Michael, > Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties > I just realised that my clumsy property keys are against the rules since > they are containing whitespace characters. > > Nevertheless I still like the idea of having a Type, a number and a > Value for every property that can occur multiple. Thus the properties > can be easily mapped to the VCard scheme as well as to any other scheme. > > Thus, what I would like to propose is the following scheme: > > > #+BEGIN_SRC org > :PROPERTIES: > :Contact_Type: individual or organisation > :Organization_1_Type: company > :Organization_1_Name: The company name > :Organization_1_Department: department, business unit, division > :Organization_1_Title: job title of an individual > :FN: The full name > :GivenName: > :FamilyName: > :Name_Prefix: > :Name_Suffix: > :Nickname: > :Email_1_Type: Work > :Email_1_Value: n...@company.fr > :Address_1_Type: Work > :Address_1_Street: The street can contain multiple lines \\ second line > :Address_1_Box: Postal box > :Address_1_Extension: other extensions that can occur in addresses > :Address_1_City: The city > :Address_1_Region: Region, federal state etc. > :Address_1_Code: 12100 > :Address_1_Country: France > :Phone_1_Type: Work > :Phone_1_Value: +33 565 623740 > :Phone_2_Type: Fax > :Phone_2_Value: +33 565 623070 > :Website_1_Type: Work > :Website_1_Value: http://www.domain.fr > :Birthday: > :Language: en > :Salutation: > :END: > #+END_SRC > Hmm, I kinda like this. It seems a bit verbose but it's better than having multiple values per properties (IMHO). Though, if we adopt this scheme, we would need to add some helper bindings/functions so that we don't have to fill this by hands. > Other user defined properties can be added and mapped to the appropriate > user defined keys during export. I'm not sure to understand what you mean. Could you give more details and maybe an example? > > [snip] > > Please note that org-collector tries to convert property values from > strings into numbers if possible. For postal codes with leading Zeros > this can lead to unexpected results. I did not find any other way to > solve this problem than to add a national code like in the following > example > > :Address_1_Code: 01169 > would lead to "1169" in the propview table. > > so I replaced it with > :Address_1_Code: DE-01169 What is `org-collector' and when does it happen? I've done a quick test and the 0 appears in `org-contacts-db'. Best, -- Daimrod/Greg
Re: [O] org-contacts development
Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties
I just realised that my clumsy property keys are against the rules since
they are containing whitespace characters.
Nevertheless I still like the idea of having a Type, a number and a
Value for every property that can occur multiple. Thus the properties
can be easily mapped to the VCard scheme as well as to any other scheme.
Thus, what I would like to propose is the following scheme:
#+BEGIN_SRC org
:PROPERTIES:
:Contact_Type: individual or organisation
:Organization_1_Type: company
:Organization_1_Name: The company name
:Organization_1_Department: department, business unit, division
:Organization_1_Title: job title of an individual
:FN: The full name
:GivenName:
:FamilyName:
:Name_Prefix:
:Name_Suffix:
:Nickname:
:Email_1_Type: Work
:Email_1_Value: n...@company.fr
:Address_1_Type: Work
:Address_1_Street: The street can contain multiple lines \\ second line
:Address_1_Box: Postal box
:Address_1_Extension: other extensions that can occur in addresses
:Address_1_City: The city
:Address_1_Region: Region, federal state etc.
:Address_1_Code: 12100
:Address_1_Country: France
:Phone_1_Type: Work
:Phone_1_Value: +33 565 623740
:Phone_2_Type: Fax
:Phone_2_Value: +33 565 623070
:Website_1_Type: Work
:Website_1_Value: http://www.domain.fr
:Birthday:
:Language: en
:Salutation:
:END:
#+END_SRC
Other user defined properties can be added and mapped to the appropriate
user defined keys during export.
Further remarks regarding my last e-mail:
> #+BEGIN: propview :id "39584cda-bff0-4b8a-9460-4fefb5b5922c" :cols (Given\
> Name Family\ Name ITEM Name\ Prefix Name\ Suffix Nickname EMAIL Phone\ 1\ -\
> Type Phone\ 1\ -\ Value Phone\ 2\ -\ Type Phone\ 2\ -\ Value Phone\ 3\ -\
> Type Phone\ 3\ -\ Value Phone\ 4\ -\ Type Phone\ 4\ -\ Value Address\ 1\ -\
> Type Address\ 1\ -\ Street Address\ 1\ -\ PO\ Box Address\ 1\ -\ Extended\
> Address Address\ 1\ -\ City Address\ 1\ -\ Region Address\ 1\ -\ Postal\ Code
> Address\ 1\ -\ Country Address\ 2\ -\ Type Address\ 2\ -\ Street Address\ 2\
> -\ PO\ Box Address\ 2\ -\ Extended\ Address Address\ 2\ -\ City Address\ 2\
> -\ Region Address\ 2\ -\ Postal\ Code Address\ 2\ -\ Country Address\ 3\ -\
> Type Address\ 3\ -\ Street Address\ 3\ -\ PO\ Box Address\ 3\ -\ Extended\
> Address Address\ 3\ -\ City Address\ 3\ -\ Region Address\ 3\ -\ Postal\ Code
> Address\ 3\ -\ Country Organization\ 1\ -\ Name Birthday Organization\ 1\ -\
> Title Organization\ 1\ -\ Department Website\ 1\ -\ Type Website\ 1\ -\ Value
> LANG TAGS) :colnames ("Given Name" "Family Name" "Name" "Name Prefix" "Name
> Suffix" "Nickname" "E-mail 1 - Value" "Phone 1 - Type" "Phone 1 - Value"
> "Phone 2 - Type" "Phone 2 - Value" "Phone 3 - Type" "Phone 3 - Value" "Phone
> 4 - Type" "Phone 4 - Value" "Address 1 - Type" "Address 1 - Street" "Address
> 1 - PO Box" "Address 1 - Extended Address" "Address 1 - City" "Address 1 -
> Region" "Address 1 - Postal Code" "Address 1 - Country" "Address 2 - Type"
> "Address 2 - Street" "Address 2 - PO Box" "Address 2 - Extended Address"
> "Address 2 - City" "Address 2 - Region" "Address 2 - Postal Code" "Address 2
> - Country" "Address 3 - Type" "Address 3 - Street" "Address 3 - PO Box"
> "Address 3 - Extended Address" "Address 3 - City" "Address 3 - Region"
> "Address 3 - Postal Code" "Address 3 - Country" "Organization 1 - Name"
> "Birthday" "Oganization 1 - Title" "Organization 1 - Department" "Website 1 -
> Type" "Website 1 - Value" "Language" "org-tags") :defaultval "" :inherit
> (TAGS) :conds ((stringp KIND)) :match "-ARCHIVE" :noquote t
Here I forgot to copy the #+END:
Please note that org-collector tries to convert property values from
strings into numbers if possible. For postal codes with leading Zeros
this can lead to unexpected results. I did not find any other way to
solve this problem than to add a national code like in the following
example
:Address_1_Code: 01169
would lead to "1169" in the propview table.
so I replaced it with
:Address_1_Code: DE-01169
--
Michael Strey
mailto:mst...@strey.biz
http://www.strey.biz
https://twitter.com/michaelstrey
Re: [O] org-contacts development
On 2014-05-23, Alexis wrote:
> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE
I have been following a VCard-like naming scheme for org-contacts
properties for a longer time.
see
https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01224.html
Recently, because of the lack of support for properties in MobileOrg and
the lost support for links in properties, I finally decided to export my
contact data to Google Contacts and -- just in order to try it -- to
BBDB. I accomplished this by creating a table with org-collector and
exporting it to CSV that can be imported by Google Contacts and BBDB.
Therefore I had to change the naming scheme. It is now similar to that
of Google Contacts.
Here is the appropriate code:
#+BEGIN_SRC org
# -*- mode: org; org-cycle-hook: (org-cycle-hide-archived-subtrees
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
org-optimize-window-after-visibility-change) -*-
* Contacts
:PROPERTIES:
:CATEGORY: Contacts
:ID: 39584cda-bff0-4b8a-9460-4fefb5b5922c
:END:
** A - Contacts :CONTACT:
:PROPERTIES:
:CATEGORY: Contacts
:END:
*** Actia Sodielec :DAB:DVB:EMPFÄNGER:noexport:
:PROPERTIES:
:KIND: org
:Organization 1 - Name: Actia Sodielec
:Address 1 - Type: Work
:Address 1 - Street:
:Address 1 - PO Box: Site Aveyron
:Address 1 - Extended Address: BP-9 Route de Mayres
:Address 1 - City: Saint Georges de Luzen\c{c}on
:Address 1 - Region:
:Address 1 - Postal Code: 12100
:Address 1 - Country: France
:Phone 1 - Type: Work
:Phone 1 - Value: +33 565 623740
:Phone 2 - Type: Fax
:Phone 2 - Value: +33 565 623070
:Website 1 - Type: Work
:Website 1 - Value: http://www.actiasodielec.fr
:LANG: en
:END:
Saint Georges de Luzenḉon
Carsac, Sara
:PROPERTIES:
:KIND: individual
:Organization 1 - Name: Actia Sodielec
:Organization 1 - Department: Broadcast, Rail & Transport (BTF)
:Organization 1 - Title: Responsable Commercial, Sales Manager
:FN: Sara Carsac
:Family Name: Carsac
:Given Name: Sara
:Nickname: Dear Sara
:EMAIL: s.car...@actiasodielec.fr
:Phone 1 - Type: Work
:Phone 1 - Value: +33 618 12345
:Phone 3 - Type: Mobile
:Phone 3 - Value: +33 668 12345
:Phone 2 - Type: Fax
:Phone 2 - Value: +33 565 12345
:Website 1 - Type: Work
:Website 1 - Value: http://actiasodielec.fr
:LANG: en
:END:
** B - Contacts :CONTACT:
:PROPERTIES:
:CATEGORY: Contacts
:END:
*** BTI Technologieagentur Dresden GmbH :ADMIN:
Naumann, Michael
:PROPERTIES:
:KIND: individual
:Organization 1 - Name: BTI Technologieagentur Dresden GmbH
:Organization 1 - Department: EU Forschung und Technologie
:FN: Michael Naumann
:Family Name: Naumann
:Given Name: Michael
:Nickname: Sehr geehrter Herr Naumann
:Address 1 - Type: Work
:Address 1 - Street: Gostritzer Str. 61-63
:Address 1 - PO Box:
:Address 1 - Extended Address:
:Address 1 - City: Dresden
:Address 1 - Region:
:Address 1 - Postal Code: DE-01217
:Address 1 - Country: Germany
:EMAIL: eu-forsch...@bti-dresden.de
:Phone 1 - Type: Work
:Phone 1 - Value: +49 351 871 7560
:Website 1 - Type: Work
:Website 1 - Value: http://www.bti-dresden.de
:LANG: de
:END:
* Export
** Export for Google Contacts
- C-c C-c on line #+BEGIN: updates the table
- place cursor within the table
- M-x org-table-export
#+BEGIN: propview :id "39584cda-bff0-4b8a-9460-4fefb5b5922c" :cols (Given\ Name
Family\ Name ITEM Name\ Prefix Name\ Suffix Nickname EMAIL Phone\ 1\ -\ Type
Phone\ 1\ -\ Value Phone\ 2\ -\ Type Phone\ 2\ -\ Value Phone\ 3\ -\ Type
Phone\ 3\ -\ Value Phone\ 4\ -\ Type Phone\ 4\ -\ Value Address\ 1\ -\ Type
Address\ 1\ -\ Street Address\ 1\ -\ PO\ Box Address\ 1\ -\ Extended\ Address
Address\ 1\ -\ City Address\ 1\ -\ Region Address\ 1\ -\ Postal\ Code Address\
1\ -\ Country Address\ 2\ -\ Type Address\ 2\ -\ Street Address\ 2\ -\ PO\ Box
Address\ 2\ -\ Extended\ Address Address\ 2\ -\ City Address\ 2\ -\ Region
Address\ 2\ -\ Postal\ Code Address\ 2\ -\ Country Address\ 3\ -\ Type Address\
3\ -\ Street Address\ 3\ -\ PO\ Box Address\ 3\ -\ Extended\ Address Address\
3\ -\ City Address\ 3\ -\ Region Address\ 3\ -\ Postal\ Code Address\ 3\ -\
Country Organization\ 1\ -\ Name Birthday Organization\ 1\ -\ Title
Organization\ 1\ -\ Department Website\ 1\ -\ Type Website\ 1\ -\ Value LANG
TAGS) :colnames ("Given Name" "Family Name" "Name" "Name Prefix" "Name Suffix"
"Nickname" "E-mail 1 - Value" "Phone 1 - Type" "Phone 1 - Value" "Phone 2 -
Type" "Phone 2 - Value" "Phone 3 - Type" "Phone 3 - Value" "Phone 4 - Type"
"Phone 4 - Value" "Address 1 - Type" "Address 1 - Street" "Address 1 - PO Box"
"Address 1 -
Re: [O] org-contacts development
Daimrod writes:
> Sure, but then how would we define the map? with a fixed set of rules?
> with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
> ("EMAIL_WORK" -> "EMAIL;TYPE=work")))?
More the latter. My initial (again, brainstorming!) thinking has an
user-modifiable data structure along the lines of the following:
+---+++
| elisp var |org property| ~ vCard equivalent |
+---+++
| org-contacts-email-work-property |EMAIL_WORK |EMAIL;TYPE=work |
| org-contacts-mobile-work-property |MOBILE_WORK |TEL;CELL;TYPE=work |
+---+++
English-language properties for the org property column could be
provided by default, but users who wanted to use non-English property
names could do so by modifying the relevant entries.
> I'm not saying that it's impossible nor that we shouldn't do it but that
> we need to think about it first. :)
Oh 100% agreed! That's why i've started this discussion here, so as to
get input, feedback, and hopefully at least rough consensus, on how to
approach all this. :-)
> Well, if people are willing to help, I'll see if I can come up with a
> proposal.
:-) Sounds good!
Alexis.
Re: [O] org-contacts development
Alexis writes:
> Daimrod writes:
>
>> So, as you said, we would need to define and document a specification
>> for org-contacts. And we need to be clear from the beginning about
>> what it can do and what it can not do. For example, it is unlikely
>> that org-contacts will be a 1:1 mapping with the vCard format in its
>> current form because vCard properties can have values.
>>
>> e.g.
>> PROP1;PROP2=VAL:FOO BAR
>> ^
>
> Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which
> is how my Android phone vCard-exports a mobile number) to
> e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like
> e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just
> brainstorming, however. :-)
Sure, but then how would we define the map? with a fixed set of rules?
with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
("EMAIL_WORK" -> "EMAIL;TYPE=work")))?
I'm not saying that it's impossible nor that we shouldn't do it but that
we need to think about it first. :)
>> An approach would be to keep using properties whenever it's possible
>> to keep the format simple when possible and use subtree instead of
>> properties when necessary.
>>
>> e.g.
>> #+BEGIN_SRC org
>> ,* Contact Name
>> ,** PHONE
>> :PROPERTIES:
>> :TYPE: WORK
>> :END:
>> - num1
>> - num2
>> #+END_SRC
>>
>> But then we would need a special property to indicate that a subtree
>> is a contact and ignore subtree without this property (just like it
>> does with the EMAIL property ATM).
>>
>> #+BEGIN_SRC org
>> ,* Contact Name
>> :PROPERTIES:
>> :TYPE: org-contacts
>> :END:
>>
>> ,** PHONE
>> :PROPERTIES:
>> :TYPE: WORK
>> :END:
>> - num1
>> - num2
>> #+END_SRC
>>
>> And of course it would be nice if we could keep as much compatibility
>> with the current format :)
>
> Well, to me this looks broadly similar to what Esben has proposed:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html
>
> Although i like the idea of such a format in principle, my concern (as i
> noted in my reply to Esben) is that this might require a substantial
> modification of org-contacts.el, both to accommodate this format and to
> ensure backwards-compatibility. If this is indeed the case, and someone
> else is willing to commit to being the lead on undertaking that work,
> then i'll certainly support that work and write relevant MobileOrg code
> to work with both the new and old formats. Otherwise, from my
> perspective of wanting to simply add some more fields and be able to
> transfer contact details between MobileOrg and my phone's Contacts
> system, it's more than i'm willing to take on at this point.
Well, if people are willing to help, I'll see if I can come up with a
proposal.
--
Daimrod/Greg
signature.asc
Description: PGP signature
Re: [O] org-contacts development
Daimrod writes: > So, as you said, we would need to define and document a specification > for org-contacts. And we need to be clear from the beginning about > what it can do and what it can not do. For example, it is unlikely > that org-contacts will be a 1:1 mapping with the vCard format in its > current form because vCard properties can have values. > > e.g. > PROP1;PROP2=VAL:FOO BAR > ^ Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which is how my Android phone vCard-exports a mobile number) to e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just brainstorming, however. :-) > An approach would be to keep using properties whenever it's possible > to keep the format simple when possible and use subtree instead of > properties when necessary. > > e.g. > #+BEGIN_SRC org > ,* Contact Name > ,** PHONE > :PROPERTIES: > :TYPE: WORK > :END: > - num1 > - num2 > #+END_SRC > > But then we would need a special property to indicate that a subtree > is a contact and ignore subtree without this property (just like it > does with the EMAIL property ATM). > > #+BEGIN_SRC org > ,* Contact Name > :PROPERTIES: > :TYPE: org-contacts > :END: > > ,** PHONE > :PROPERTIES: > :TYPE: WORK > :END: > - num1 > - num2 > #+END_SRC > > And of course it would be nice if we could keep as much compatibility > with the current format :) Well, to me this looks broadly similar to what Esben has proposed: https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html Although i like the idea of such a format in principle, my concern (as i noted in my reply to Esben) is that this might require a substantial modification of org-contacts.el, both to accommodate this format and to ensure backwards-compatibility. If this is indeed the case, and someone else is willing to commit to being the lead on undertaking that work, then i'll certainly support that work and write relevant MobileOrg code to work with both the new and old formats. Otherwise, from my perspective of wanting to simply add some more fields and be able to transfer contact details between MobileOrg and my phone's Contacts system, it's more than i'm willing to take on at this point. Alexis.
Re: [O] org-contacts development
Alexis writes: > Hi all, Hi, > [snip...] > > Fleshing out an extended spec for org-contacts data could be part of the > process of making org-contacts a first-class citizen of org-mode, and > provide a more solid foundation on which people can build (and share) > the org-contacts functionality they're after. And in my own particular > case, it would greatly facilitate my work in org-contacts / Android > Contacts integration. :-) > > What do people think? IMHO, the "problem" with org-contacts isn't that it isn't part of org-mode, but that its format isn't well defined enough. Some fields accept only one value, some multiple values, with different separators, etc... And on top of that, there is no easy way to access the database (`car', `cadr', `caddr', ...) which makes it difficult to read and write code. So, as you said, we would need to define and document a specification for org-contacts. And we need to be clear from the beginning about what it can do and what it can not do. For example, it is unlikely that org-contacts will be a 1:1 mapping with the vCard format in its current form because vCard properties can have values. e.g. PROP1;PROP2=VAL:FOO BAR ^ And AFAIK we can't do that with org-mode properties. An approach would be to keep using properties whenever it's possible to keep the format simple when possible and use subtree instead of properties when necessary. e.g. #+BEGIN_SRC org ,* Contact Name ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC But then we would need a special property to indicate that a subtree is a contact and ignore subtree without this property (just like it does with the EMAIL property ATM). #+BEGIN_SRC org ,* Contact Name :PROPERTIES: :TYPE: org-contacts :END: ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC And of course it would be nice if we could keep as much compatibility with the current format :) -- Daimrod/Greg
Re: [O] org-contacts development
Rasmus writes: > Check here: > > https://f-droid.org/repository/browse/?fdfilter=carddav&fdpage=1&page_id=0 > > DAVdroid works very well. Oh okay, i didn't realise DAVdroid was FOSS. DAVdroid makes use of the ez-vcard library, which is BSD-licensed, and certainly seems like it might be useful. However, i'm not sure to what extent the sync-specific functionality of DAVdroid can be separated from the rest of the app; superficially, it seems like it's fairly tightly integrated. But if nothing else, it does show how it can be done! Thank you. :-) Alexis.
Re: [O] org-contacts development
Alexis writes: > There might already be > a FOSS CardDAV library for Android out there that could be used for > syncing, but i've not researched that yet. Check here: https://f-droid.org/repository/browse/?fdfilter=carddav&fdpage=1&page_id=0 DAVdroid works very well. -- Sådan en god dansk lagereddike kan man slet ikke bruge mere
Re: [O] org-contacts development
Alexander Baier writes: > For what it's worth, I would love to help out in any way I can. I use > org-contacts myself and know elisp well enough to also do some > implementing. But I wouldn't mind writing some documentation, either. Thank you! At this point i'm studying RFC 6350 (vCard 4) and the org-contacts.el source, trying to work out how to bring more of the former to the latter with a minimal amount of work and fuss. :-) > I, however, don't know much about Android programming or the syncing > aspect of this task. *nod* i'm not sure how much work is involved in the syncing aspect, and so my first priority is to at least be able to export individual contacts from MobileOrg to an individual vCard file that can be imported into the Android Contacts system, and vice versa. There might already be a FOSS CardDAV library for Android out there that could be used for syncing, but i've not researched that yet. Alexis.
Re: [O] org-contacts development
Hi Alexander, Alexander Baier writes: > For what it's worth, I would love to help out in any way I can. I use > org-contacts myself and know elisp well enough to also do some > implementing. But I wouldn't mind writing some documentation, either. > I, however, don't know much about Android programming or the syncing > aspect of this task. I'm adding Greg (Daimrod) to this thread, as I remember he was kinda unofficial org-contacts.el maintainer for a while -- you may both collaborate on org-contacts.el to speed up development. Thanks in any case! -- Bastien
Re: [O] org-contacts development
On 2014-05-24 12:15 Alexis wrote: > Alexander Baier writes: > >> About the spec, might it make sense to use a standard already in >> existence as a starting point or even a major inspiration? Something >> like vCard for example? > > Yeah, i like the idea of building on top of vCard, given how widely it's > used and supported, and that it doesn't seem to be a horrible format > Those who feel otherwise are going to need to speak up soon or > forever hold their peace. :-) > > > Alexis. For what it's worth, I would love to help out in any way I can. I use org-contacts myself and know elisp well enough to also do some implementing. But I wouldn't mind writing some documentation, either. I, however, don't know much about Android programming or the syncing aspect of this task. Regards, -- Alexander Baier
Re: [O] org-contacts development
Bastien writes: > Alexis writes: > >> *nod* Good point i'd be happy to assign copyright to the FSF, >> myself, but i know that doing so is an issue for many people. > > Here you go! > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt > > :) Heh, thank you! i'll definitely make sure to complete that form and send it in. :-) Alexis.
Re: [O] org-contacts development
Alexis writes: > *nod* Good point i'd be happy to assign copyright to the FSF, > myself, but i know that doing so is an issue for many people. Here you go! http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt :) -- Bastien
Re: [O] org-contacts development
Xebar Saram writes: > This sounds awesome, i would love syncing org contacts with my android > phone :-) It's good to know i'm not the only one wanting this functionality - gives me more incentive to actually implement it! Alexis.
Re: [O] org-contacts development
Alexander Baier writes: > About the spec, might it make sense to use a standard already in > existence as a starting point or even a major inspiration? Something > like vCard for example? Yeah, i like the idea of building on top of vCard, given how widely it's used and supported, and that it doesn't seem to be a horrible format Those who feel otherwise are going to need to speak up soon or forever hold their peace. :-) Alexis.
Re: [O] org-contacts development
Bastien writes: > Improving org-contacts.el and making it part of Org core are two > separate issues -- not everything that is part of Org core gets a > lot of attention, and some contributed packages do. Oh okay, fair enough! > I'd say: go ahead with whatever conventions you want to enforce > and the community will step up -- or just applaud :) Heh, okay. :-) > PS: Actually, being part of Org core sometimes slow down things, > because substantial contributions then need to come from people > who assign their copyright to the Free Software Foundation. *nod* Good point i'd be happy to assign copyright to the FSF, myself, but i know that doing so is an issue for many people. Alexis.
Re: [O] org-contacts development
Rasmus writes: > You could also put yourself a slightly different challenge: map > between the org-contacts-format and an carddav server that you > establish as a backend on your phone. E.g. google contacts is a > carddav server, I think. > > I use DAVdroid for syncing my calendar and my contacts with my > OwnCloud and it very, very well! I sync my agenda with my OwnCloud > using org-caldav, which works great except when you have multiple time > stamps per heading. For contacts I tried Asynk to sync my bbdb > contacts with OwnCloud, but I was using too many fields unknown to it, > and my contacts got messed up. > > Mayhaps you already thought of this approach. I think it is more > future-proof. i wasn't aware of CardDAV - thanks for pointing it out! My thoughts of how to deal with org-contacts data have indeed been revolving around vCard though, so this approach looks interesting indeed. :-) Alexis.
Re: [O] org-contacts development
Hi Alexis This sounds awesome, i would love syncing org contacts with my android phone thx alot! z On Fri, May 23, 2014 at 1:30 PM, Alexander Baier < alexander.ba...@mailbox.org> wrote: > Hello Alexis, > > On 2014-05-23 06:07 Alexis wrote: > > [...] > > > What would be useful would be an 'official', fleshed-out spec for > > org-contacts data, which handles a greater range of contact-related > > info. At the moment, for example, my org-contacts file makes use of the > > properties: > > > > #+PROPERTY: LANDLINE > > #+PROPERTY: MOBILE > > #+PROPERTY: POST > > #+PROPERTY: RESIDENCE > > > > [...] > > > Fleshing out an extended spec for org-contacts data could be part of the > > process of making org-contacts a first-class citizen of org-mode, and > > provide a more solid foundation on which people can build (and share) > > the org-contacts functionality they're after. And in my own particular > > case, it would greatly facilitate my work in org-contacts / Android > > Contacts integration. :-) > > > > What do people think? > > I, for one, would love to see org-contacts being improved in any way. > Integrating this with MobileOrg would be an extremely helpful and > something I have wanted since the day I started using org-contacts. > > About the spec, might it make sense to use a standard already in > existence as a starting point or even a major inspiration? Something > like vCard for example? > > Regards, > -- > Alexander Baier > >
Re: [O] org-contacts development
Hello Alexis, On 2014-05-23 06:07 Alexis wrote: [...] > What would be useful would be an 'official', fleshed-out spec for > org-contacts data, which handles a greater range of contact-related > info. At the moment, for example, my org-contacts file makes use of the > properties: > > #+PROPERTY: LANDLINE > #+PROPERTY: MOBILE > #+PROPERTY: POST > #+PROPERTY: RESIDENCE > [...] > Fleshing out an extended spec for org-contacts data could be part of the > process of making org-contacts a first-class citizen of org-mode, and > provide a more solid foundation on which people can build (and share) > the org-contacts functionality they're after. And in my own particular > case, it would greatly facilitate my work in org-contacts / Android > Contacts integration. :-) > > What do people think? I, for one, would love to see org-contacts being improved in any way. Integrating this with MobileOrg would be an extremely helpful and something I have wanted since the day I started using org-contacts. About the spec, might it make sense to use a standard already in existence as a starting point or even a major inspiration? Something like vCard for example? Regards, -- Alexander Baier
Re: [O] org-contacts development
Bastien writes: > PS: Actually, being part of Org core sometimes slow down things, > because substantial contributions then need to come from people > who assign their copyright to the Free Software Foundation. PPS: This is a feature. -- ツ
Re: [O] org-contacts development
Hi Alexis, Alexis writes: > What do people think? Improving org-contacts.el and making it part of Org core are two separate issues -- not everything that is part of Org core gets a lot of attention, and some contributed packages do. I'd say: go ahead with whatever conventions you want to enforce and the community will step up -- or just applaud :) PS: Actually, being part of Org core sometimes slow down things, because substantial contributions then need to come from people who assign their copyright to the Free Software Foundation. -- Bastien
Re: [O] org-contacts development
Alexis writes: > What i'd now like to do is to add support for transferring data back and > forth between my org-contacts file and the Contacts store on my > phone. The challenge is the mapping between these two systems. You could also put yourself a slightly different challenge: map between the org-contacts-format and an carddav server that you establish as a backend on your phone. E.g. google contacts is a carddav server, I think. I use DAVdroid for syncing my calendar and my contacts with my OwnCloud and it very, very well! I sync my agenda with my OwnCloud using org-caldav, which works great except when you have multiple time stamps per heading. For contacts I tried Asynk to sync my bbdb contacts with OwnCloud, but I was using too many fields unknown to it, and my contacts got messed up. Mayhaps you already thought of this approach. I think it is more future-proof. > What would be useful would be an 'official', fleshed-out spec for > org-contacts data, which handles a greater range of contact-related > info. At the moment, for example, my org-contacts file makes use of > the properties: I would go for whatever properties are supported by Carddav, if there's a limit. -- Sådan en god dansk lagereddike kan man slet ikke bruge mere
[O] org-contacts development
Hi all, i use org-contacts as my primary system for contact management. Consequently, i'd love to be able to make use of my org-contacts data on my Android phone. To that end, i recently wrote some code for MobileOrg-Android which adds basic PROPERTIES drawer support: https://github.com/matburt/mobileorg-android/pull/434 What i'd now like to do is to add support for transferring data back and forth between my org-contacts file and the Contacts store on my phone. The challenge is the mapping between these two systems. For example, org-contacts provides only one EMAIL property, which can contain multiple addresses separated by spaces, whereas Android's ContactsContract.CommonDataKinds.Email class is able to distinguish between different addresses for different purposes: http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.Email.html What would be useful would be an 'official', fleshed-out spec for org-contacts data, which handles a greater range of contact-related info. At the moment, for example, my org-contacts file makes use of the properties: #+PROPERTY: LANDLINE #+PROPERTY: MOBILE #+PROPERTY: POST #+PROPERTY: RESIDENCE A search of this list's archives for references to 'org-contacts': https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate suggests that org-contacts is something people are using heavily enough that they're writing code, ad-hoc, to provide functionality they require, e.g. http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html i'm wondering if it might now be appropriate for org-contacts to become part of org-mode proper, rather than simply a contrib, to reduce unnecessary duplication of efforts. i suspect that, at the moment, a number of people interested in making use of org-contacts might be reluctant to do so (or do so more heavily) because it's not an 'official' part of org-mode. Yet contacts management seems to me to be functionality well within org-mode's remit. Fleshing out an extended spec for org-contacts data could be part of the process of making org-contacts a first-class citizen of org-mode, and provide a more solid foundation on which people can build (and share) the org-contacts functionality they're after. And in my own particular case, it would greatly facilitate my work in org-contacts / Android Contacts integration. :-) What do people think? Alexis.
