emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Standardize #+BIBLIOGRAPHY line
Date: Mon, 22 Jul 2013 18:46:21 +0530	[thread overview]
Message-ID: <87ip02wx96.fsf@gmail.com> (raw)
In-Reply-To: <87hafn55l0.fsf@gmail.com> (Nicolas Goaziou's message of "Mon, 22 Jul 2013 11:03:55 +0200")


Nicolas

Getting Citation right to cater to general needs is going to be complex.
This is mainly because 

    1. Org's object syntax is very rudimentary and not "extensible" 
    2. "real-world" citations may need some annotations page number etc.

I think it is good to *atleast make a move* in standardizing the cite
elements.  My gut feeling is that cite objects - for now - should be
coded as \cite { } latex objects.  This specifically means that link
syntax for cite should NOT BE ENCOURAGED (or STRONGLY DISCOURAGED).

----------------------------------------------------------------

As an aside, I am inclined to think of cite objects as "special class"
of "footnote" elements.  Footnotes are unique in that it "interlinks"
both object and element worlds.  Elements can have attributes attached
to them.  Consider for example, a syntax like this.

    Joshu's "Mu" [cite: blyth_zen_1966] is a koan that a practioner must
    break through.

    #+ATTR_PAGE:  :page 17
    [cite:blyth_zen_1966]  Zen and Zen Classics, Volume 4, Mumonkan

Now what goes within the brackets - "blyth_zen_1966" - is just a label.
The attributes of that object are set in a paragraph that is
"introduced" with that label (as above).

> However, I think it ought to be merged in ox-bibtex.el instead.

Does the author have copyright assignments for contributing to Emacs?

        Taru Karttunen <taruti@taruti.net>

As a personal policy, I don't want to touch a file which wouldn't end up
in Emacs proper.  

Any changes that I make to Emacs - that includes Org-mode - is
*guaranteed* to end up in Emacs proper.  It's going to happen in it's
own time.

> "ox-bibtex" name is misleading as it is not directly related to "bibtex"
> program. At its core, it merely introduces a BIBLIOGRAPHY keyword and
> [[cite:...]] links. It also provides accessors and predicates wrt them:
>
>  - org-bibtex-get-file
>  - org-bibtex-get-style
>  - org-bibtex-get-arguments
>  - org-bibtex-citation-p
>  - org-bibtex-get-citation-key

These wouldn't be necessary if the reader syntax is improved.  

Why not create an ox-cite.el, make yourself the author and move your own
changes to that file.  You can also FAKE a `citation-reference' object
so that the backend consumers are totally unaware of how these objects
are represented in the Org document.


We can have separate ox-bibtex.el and ox-jabref.el - I call them as
"citation processors".  They will be providing the "standard"
transcoders - `org-CITATION-PROCESSOR-citation-reference' and
`org-CITATION-PROCESSOR-bibliography'.  As noted in previous mail,
having first class transcoders will help, in switching an export backend
to switch to someother citation processor.  One just has to switch the
translators.


> Maybe all of this calls for a generalization of the reader function.
> Something like "stuff everything before the first keyword as the value
> of a generic keyword". IOW,
>
>   #+keyword: :a val :b val2    =>    (:a "val" :b "val2")
>   #+keyword: text :a val       =>    (:head "text" :a "val")
>   #+keyword: text :head other  =>    not good

How about, making the keyword itself as a property, if the option string
DOESN'T is not introduced by a symbol.

        #+keyword: :a val :b val2    =>    (:a "val" :b "val2")
        #+keyword: text :a b :c d    =>    (:keyword text :a b :c d)

>   #+toc: headlines :levels 4

        (:toc headlines :levels 4)

>   #+BEAMER_THEME: Madrid

        (:beamer-theme Madrid)

>   #+BEAMER_THEME: Rochester [height=20pt]

        (:beamer-theme Rochester [height=20pt])

These all will become "values" of a `keyword' element.

> Regards,

  reply	other threads:[~2013-07-22 13:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  7:25 Standardize #+BIBLIOGRAPHY line Jambunathan K
2013-07-22  9:03 ` Nicolas Goaziou
2013-07-22 13:16   ` Jambunathan K [this message]
2013-07-22 13:19     ` Jambunathan K
2013-07-22 13:31     ` Nicolas Goaziou
2013-07-22 13:47       ` Jambunathan K
2013-07-22 13:58         ` Nicolas Goaziou
2013-07-22 16:09           ` Jambunathan K
2013-07-22 19:33           ` Jambunathan K
2013-07-22 14:15       ` Rasmus
2013-07-22 16:29         ` Jambunathan K
2013-07-22 21:51           ` Rasmus
2013-07-25  8:47             ` Jambunathan K
2013-07-22 17:01         ` Jambunathan K
2013-07-22 19:34           ` Jambunathan K

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=87ip02wx96.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.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).