[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org-contacts development
From: |
Daimrod |
Subject: |
Re: [O] org-contacts development |
Date: |
Mon, 26 May 2014 12:21:38 +0900 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
Alexis <address@hidden> writes:
> Daimrod <address@hidden> 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, (continued)
- Re: [O] org-contacts development, Alexis, 2014/05/24
- Re: [O] org-contacts development, Alexander Baier, 2014/05/24
- Re: [O] org-contacts development, Bastien, 2014/05/24
- Re: [O] org-contacts development, Alexis, 2014/05/24
- Re: [O] org-contacts development, Rasmus, 2014/05/24
- Re: [O] org-contacts development, Alexis, 2014/05/24
[O] Org-contacts standardization (was: org-contacts development), Karl Voit, 2014/05/24
Message not available
Re: [O] org-contacts development, Daimrod, 2014/05/24
Re: [O] org-contacts development, Michael Strey, 2014/05/26