emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
Date: Fri, 20 Jan 2012 22:48:31 -0700	[thread overview]
Message-ID: <CAJcAo8vFErVhDrfVPqh8ve67MPf8pJZdQMgFAf=x_N6UESxb1g@mail.gmail.com> (raw)
In-Reply-To: <80d3bbv133.fsf@somewhere.org>

FWIW:

It might be the case that we will want to consider the multi-value
property idea and the multi-line property idea together at some point.
 (With or without serialization for the latter.)

I think multi-line properties will eventually be needed (in some form)
in any case for things like org-contacts and they provide a simple way
of allowing more data without imposing semantics.  In other words,
they are usable even if we don't standardize multi-value semantics.

However, Babel and OP both need multi-value properties.

What should a multi-value property be semantically?  Effectively a
vector?  Effectively an alist?  Both are possibilities.

Outside of Babel and OP's case, do we need a layer of semantics on
properties?  Do we want one?  Should we set Babel's interpretation of
multi-value properties in stone for the rest of Org?

Also, should there be an interface to multi-value properties other
than accumulation?  Give me the 3rd value of property?  Give me the
value that matches this string?  Set the 3rd value?  Set (and replace)
the value that matches?

Is accumulation a substitute for multi-line properties?  Or do we want
something nicer for that purpose so that editing and reading are
easier, so that there is no order-dependence of property fields, and
so on?

Just philosophical/design questions.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

      parent reply	other threads:[~2012-01-21  5:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 14:28 Bugs/features of accumulating property values when used with entries (concretely: in org-contacts) Christoph LANGE
2011-12-26 14:16 ` Bastien
2011-12-26 14:50   ` Sebastien Vauban
2011-12-28 18:17     ` Christoph LANGE
2011-12-28 18:47       ` Eric Schulte
2011-12-29  8:03         ` Sebastien Vauban
2011-12-28 18:54       ` Thomas S. Dye
2012-01-21  5:48     ` Samuel Wales [this message]

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='CAJcAo8vFErVhDrfVPqh8ve67MPf8pJZdQMgFAf=x_N6UESxb1g@mail.gmail.com' \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=wxhgmqzgwmuf@spammotel.com \
    /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).