From: Daimrod <daimrod@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: org-contacts development
Date: Mon, 26 May 2014 12:21:38 +0900 [thread overview]
Message-ID: <87bnulfcn1.fsf@tanger.home> (raw)
In-Reply-To: <87fvjzgjan.fsf@gmail.com> (Alexis's message of "Sun, 25 May 2014 03:48:00 +1000")
[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]
Alexis <flexibeast@gmail.com> writes:
> Daimrod <daimrod@gmail.com> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
next prev parent reply other threads:[~2014-05-26 3:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 4:07 org-contacts development Alexis
2014-05-23 9:06 ` Rasmus
2014-05-23 10:30 ` Alexander Baier
2014-05-24 4:02 ` Xebar Saram
2014-05-24 10:27 ` Alexis
2014-05-24 10:15 ` Alexis
2014-05-24 14:18 ` Alexander Baier
2014-05-24 14:55 ` Bastien
2014-05-24 15:05 ` Alexis
2014-05-24 15:43 ` Rasmus
2014-05-24 16:10 ` Alexis
2014-05-23 12:45 ` Bastien
2014-05-23 15:46 ` Rasmus
2014-05-24 10:04 ` Alexis
2014-05-24 12:17 ` Bastien
2014-05-24 14:07 ` Alexis
2014-05-24 9:00 ` Org-contacts standardization (was: org-contacts development) Karl Voit
[not found] ` <878ups27km.fsf@gmx.us>
2014-05-24 9:59 ` org-contacts development Alexis
2014-05-24 16:51 ` Daimrod
2014-05-24 17:48 ` Alexis
2014-05-26 3:21 ` Daimrod [this message]
2014-05-26 4:06 ` Alexis
2014-05-26 15:20 ` Michael Strey
2014-05-27 9:27 ` Michael Strey
2014-05-29 3:19 ` Daimrod
2014-06-03 10:23 ` Michael Strey
2014-06-05 4:26 ` Daimrod
2014-07-23 13:40 ` Karl Voit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnulfcn1.fsf@tanger.home \
--to=daimrod@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).