From: Eric S Fraga <e.fraga@ucl.ac.uk>
To: John Kitchin <jkitchin@andrew.cmu.edu>
Cc: Emacs orgmode <emacs-orgmode@gnu.org>
Subject: Re: adding a new org-element?
Date: Tue, 22 Mar 2016 16:25:53 +0000 [thread overview]
Message-ID: <87oaa6qy26.fsf@ucl.ac.uk> (raw)
In-Reply-To: <m2egb2k0uu.fsf@Johns-MacBook-Air.local> (John Kitchin's message of "Tue, 22 Mar 2016 11:07:21 -0400")
Interesting points raised in your last email. And also reminiscent of
the citation discussion... for better or for worse ;-)
org currently has effective support for literate programming with babel;
however, it has only rudimentary support for data: tables and properties
(and maybe tags). More and more we are finding the desire to work with
data more generally outwith the constraints imposed by the current
support.
Links provide another interface to data but also rather rudimentary.
Maybe it is time to generalise some of these concepts while keeping
parsing straightforward.
I would be strongly in favour of some type of structure that supported
the equivalent of JSON in terms of data representation but with programming
functionality for export, interaction and display as provided by links
to some degree.
However, the easiest solution may be to extend the link syntax and
implementation, or maybe just the implementation, to address some of the
current limitations, especially in terms of display but also in terms of
linking to other objects in the org file (or even to other org files)?
At present, links have follow and export functionality. The follow
functionality is a start towards actions on the data and is complete, in
the Turing sense, given that the full power of elisp is there. Likewise
for export. Two things are missing: linking and display.
Linking (confusing terminology: maybe cross-referencing) between "link
objects" could be imposed on the description which can then be processed
by the follow parameter. Nevertheless, it probably would be desirable
to have a naming capability for individual link instances, one of the
aspects discussed in the citation thread IIRC. What is missing entirely
in links is display functionality; this could be added as a third
argument to the link definition.
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.91.1, Org release_8.3.4-626-gb62d55
next prev parent reply other threads:[~2016-03-22 16:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 1:51 adding a new org-element? John Kitchin
2016-03-22 8:24 ` Eric S Fraga
2016-03-22 11:34 ` John Kitchin
2016-03-22 13:59 ` Eric S Fraga
2016-03-22 15:07 ` John Kitchin
2016-03-22 16:25 ` Eric S Fraga [this message]
2016-03-22 19:18 ` John Kitchin
2016-03-22 19:26 ` Eric S Fraga
2016-03-22 18:59 ` Samuel W. Flint
2016-03-22 19:21 ` Eric S Fraga
2016-03-22 21:29 ` [SPAM] " Samuel W. Flint
2016-03-22 19:21 ` John Kitchin
2016-03-22 9:19 ` Rasmus
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oaa6qy26.fsf@ucl.ac.uk \
--to=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.