[-- Attachment #1: Type: text/plain, Size: 728 bytes --] Hello world, I'm just taking another look at org-contacts. I wonder what the best practice is for dealing with multi-line properties like postal addresses. I can just make them part of the entry, of course, not in a property, but that seems oddly different from the other properites. Have I overlooked something obvious? Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | A man may fulfill the object of his http://nwalsh.com/ | existence by asking a question he | cannot answer, and attempting a task he | cannot achieve.--Oliver Wendell Holmes [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 186 bytes --]
[-- Attachment #1: Type: text/plain, Size: 772 bytes --] On Wednesday 13 November 2013 14:23:17 Norman Walsh wrote: > Hello world, > > I'm just taking another look at org-contacts. I wonder what the best > practice is for dealing with multi-line properties like postal > addresses. I store addresses like that :PROPERTIES: :ADDRESS: street no, postal-code city, country :END: That way of formatting is supported by the vCard export and should work fine with the Map support (the only two features really supporting Addresses anyway). But it is not very flexible and there is no real way to add several addresses (usually space is used to separate several entries). Overall the org-contacts format is a bit limited and not consistently designed. It could use some refactoring. Regards, Rüdiger [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 230 bytes --]
* Norman Walsh <ndw@nwalsh.com> wrote: > > Hello world, Hello Norman! > I'm just taking another look at org-contacts. I wonder what the best > practice is for dealing with multi-line properties like postal > addresses. I split them up to single lines. > I can just make them part of the entry, of course, not in a property, > but that seems oddly different from the other properites. I am afraid that there is no standard (yet). However, I can give you my personal approach: > ** Firstname Lastname :FirstnameLastname: > :PROPERTIES: > :TYPE: person > :TITLE: > :EMAIL: > :URL: > :MOBILE: 0043/ > :HOMEPHONE: > :WORKPHONE: > :PHONE: > :COMPANY: > :STREET: > :POSTALCODE: > :CITY: > :COUNTRY: Austria > :PHOTOGRAPH: [[photo:FirstnameLastname.jpg]] > :BORN: > :ITOLDTHEM_EMAIL: > :ITOLDTHEM_ADDRESS: > :ITOLDTHEM_PHONE: > :ADDRESS_CHANGE_METHOD: > :END: > > - first contact: ITOLDTHEM_* is used for automatically generating my email filter rules (spam-whitelist) and memorizing the level of information I gave out to companies. ADDRESS_CHANGE_METHOD is used to memorize email addresses, web pages, or contact information on how I am able to update my personal information such as address or phone number. In the next week or so I plan to implement a Python script that generates an iCal file out of my contacts.org so that my Android phone is able to import it (including photographs!). Stay tuned :-) HTH -- 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
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --] Thought about maybe trying to extend AsynK with an org-contacts backend? That'd be ridiculously useful. http://karra-asynk.appspot.com/ On Sat, Nov 16, 2013 at 1:13 PM, Karl Voit <devnull@karl-voit.at> wrote: > * Norman Walsh <ndw@nwalsh.com> wrote: > > > > Hello world, > > Hello Norman! > > > I'm just taking another look at org-contacts. I wonder what the best > > practice is for dealing with multi-line properties like postal > > addresses. > > I split them up to single lines. > > > I can just make them part of the entry, of course, not in a property, > > but that seems oddly different from the other properites. > > I am afraid that there is no standard (yet). > > However, I can give you my personal approach: > > > ** Firstname Lastname > :FirstnameLastname: > > :PROPERTIES: > > :TYPE: person > > :TITLE: > > :EMAIL: > > :URL: > > :MOBILE: 0043/ > > :HOMEPHONE: > > :WORKPHONE: > > :PHONE: > > :COMPANY: > > :STREET: > > :POSTALCODE: > > :CITY: > > :COUNTRY: Austria > > :PHOTOGRAPH: [[photo:FirstnameLastname.jpg]] > > :BORN: > > :ITOLDTHEM_EMAIL: > > :ITOLDTHEM_ADDRESS: > > :ITOLDTHEM_PHONE: > > :ADDRESS_CHANGE_METHOD: > > :END: > > > > - first contact: > > ITOLDTHEM_* is used for automatically generating my email filter > rules (spam-whitelist) and memorizing the level of information I > gave out to companies. > > ADDRESS_CHANGE_METHOD is used to memorize email addresses, web > pages, or contact information on how I am able to update my personal > information such as address or phone number. > > In the next week or so I plan to implement a Python script that > generates an iCal file out of my contacts.org so that my Android > phone is able to import it (including photographs!). Stay tuned :-) > > HTH > > -- > 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 > > > [-- Attachment #2: Type: text/html, Size: 3018 bytes --]
* Kyle Machulis <kyle@nonpolynomial.com> wrote: > > Thought about maybe trying to extend AsynK with an org-contacts backend? > That'd be ridiculously useful. > http://karra-asynk.appspot.com/ This is a great suggestion, indeed. However, I do not have the urge to sync with Outlook, GCal, ... yet. So I pass on this one. -- 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