Re: [O] Citations, continued

[Erik Hetzner]

Hi Richard,

On Mon,  2 Feb 2015 at 20:41:06 PST,
Richard Lawrence  wrote:
> 
> Hi Erik and all,
> 
> Actually, I totally agree.  For my own use, I would be completely happy
> with just using the Pandoc syntax for citations in Org, without any
> modifications.

Great!

> The only reason I proposed anything else was that it seemed like other
> people already know that they need more than the Pandoc syntax provides.
> I think the main realistic cases are those where, in LaTeX, you'd use
> commands like \citetitle, \citedate, or \citejournal -- citation
> commands that pull in just a particular field from the reference,
> because that is what the context around the citation requires.  I don't
> see a way to do that in the Pandoc syntax.  (But am I missing
> something?)  Hence my proposed field-selectors extension.

If this is needed (and I still have a hard time seeing the use cases,
but I am not an academic) perhaps it could mimic the -@doe (suppress
author) syntax already used in pandoc (e.g. +title@doe). But
citeproc-js/hs only support suppress author or author only, so these
would not work in a pandoc export, nor any other that might depend on
citeproc-js.

> Personally, I need commands like these so little that I am happy to do
> without them.  So maybe my proposal was a bit hasty.  Could we hear from
> other people about how badly they need what such commands provide?
> 
> > And if extensions are proposed, it would be best to propose them on
> > the pandoc-discuss mailing list. It would be wonderful for users if
> > the syntax in pandoc-markdown and org-mode could stay aligned.
> 
> Yes, I again totally agree.  If people here settle on a syntax that is
> close, but not quite the same as, Pandoc's, I will certainly do that.

Again, this is great. I really do appreciate your getting this
proposal out there. I hope that I can finish porting my pandoc parser
to elisp within a week or so, so we can have an implementation to
start with.

best, Erik
--
Sent from my free software system .

Re: [O] orgmode as a transcription tool?

[Basile (The Flammable Project)]

Hello,

You should have a look at EMMS. It's suite easy to setup on linux. But if
you are using a MS Windows OS, it does requiert more settings. But
everything you light ne controlable within Emacs.

Regards,

Basile
Le 3 févr. 2015 06:27, "Russell Adams"  a écrit :

> On Mon, Feb 02, 2015 at 11:23:25PM -0600, Bill White wrote:
> > Today I was looking for a tool to ease my transcription of a recording
> > of a half-hour appointment with a doctor.
> >
> > Googling led to https://transcribe.wreally.com/ for the job - it really
> > works well, and it seems like something orgmode should be able to do.
> >
> > The idea is to unite a media player with a text-editing window.  Certain
> > commands issued *while in the text window* will operate on the media
> > player: pause, go back or ahead 2 seconds, slow down, speed up, etc.
> > Uniting the two eliminates constant switching between a media player and
> > a text editor - it's all integrated and controllable without switching
> > windows.
> >
> > From
> https://transcribe.wreally.com/guide/how-to-transcribe-audio-interviews-faster/
> > > The advantage of using Transcribe over a conventional text editor +
> > > media player approach is that you don’t have to lift your hands-off
> > > the keyboard at all. You can control the audio with your keyboard
> > > while simultaneously typing into the built-in text editor.
> >
> > Could orgmode do something like that?
>
> I don't see why not. Emacs could, or perhaps your audio program or
> window manager. I use xbindkeys and a few commands to control mpd
> (music daemon) and skip tracks, change volume, etc. Emacs has
> frontends to the same.
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>

Re: [O] orgmode as a transcription tool?

[Russell Adams]

On Mon, Feb 02, 2015 at 11:23:25PM -0600, Bill White wrote:
> Today I was looking for a tool to ease my transcription of a recording
> of a half-hour appointment with a doctor.
>
> Googling led to https://transcribe.wreally.com/ for the job - it really
> works well, and it seems like something orgmode should be able to do.
>
> The idea is to unite a media player with a text-editing window.  Certain
> commands issued *while in the text window* will operate on the media
> player: pause, go back or ahead 2 seconds, slow down, speed up, etc.
> Uniting the two eliminates constant switching between a media player and
> a text editor - it's all integrated and controllable without switching
> windows.
>
> From 
> https://transcribe.wreally.com/guide/how-to-transcribe-audio-interviews-faster/
> > The advantage of using Transcribe over a conventional text editor +
> > media player approach is that you don’t have to lift your hands-off
> > the keyboard at all. You can control the audio with your keyboard
> > while simultaneously typing into the built-in text editor.
>
> Could orgmode do something like that?

I don't see why not. Emacs could, or perhaps your audio program or
window manager. I use xbindkeys and a few commands to control mpd
(music daemon) and skip tracks, change volume, etc. Emacs has
frontends to the same.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

[O] orgmode as a transcription tool?

[Bill White]

Today I was looking for a tool to ease my transcription of a recording
of a half-hour appointment with a doctor.

Googling led to https://transcribe.wreally.com/ for the job - it really
works well, and it seems like something orgmode should be able to do.

The idea is to unite a media player with a text-editing window.  Certain
commands issued *while in the text window* will operate on the media
player: pause, go back or ahead 2 seconds, slow down, speed up, etc.
Uniting the two eliminates constant switching between a media player and
a text editor - it's all integrated and controllable without switching
windows.

>From 
>https://transcribe.wreally.com/guide/how-to-transcribe-audio-interviews-faster/
> The advantage of using Transcribe over a conventional text editor +
> media player approach is that you don’t have to lift your hands-off
> the keyboard at all. You can control the audio with your keyboard
> while simultaneously typing into the built-in text editor.

Could orgmode do something like that?

Cheers -

bw
-- 
Bill White . bi...@wolfram.com
"No ma'am, we're musicians."

[O] Bug: ELPA org-plus-contrib package is missing files from the contrib/lisp directory

[Mark A. Flacy]

In particular (comparing the org-plus-contrib-20150202 package against today's 
http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp):

htmlize.el
ob-stata.el
org-colview-xemacs.el  (not that I really care about this one)
org-download.el
org-ebib.el
org-effectiveness.el
org-eldoc.el
org-eww.el
org-index.el
org-license.el
org-passwords.el
orgtbl-sqlinsert.el
ox-extra.el
ox-gfm.el


At the very least, please ensure that htmlize.el gets packaged.

-- 
Mark A. Flacy

[O] How does one search the archives for bug reports?

[Mark A. Flacy]

Greetings,

Entering "bug" results in "References: [ bug: 0 ] 
No document matching your query.".

Entering "+subject:bug" results in "References: [ (Too many documents hit. 
Ignored) ]

No document matching your query."


So, I'm at a loss on how I can tell if someone has already reported my issue 
or not.  I think that Namazu is misconfigured for this mailing list; entering 
"bug" in the guile-devel list gives me 20 pages of hits.

-- 
Mark A. Flacy

Re: [O] Citations, continued

[Richard Lawrence]

Hi Erik and all,

Erik Hetzner  writes:

> I am really, really glad to see people discussing citations in
> org-mode. But I have some concerns about this proposal.
>
> Before extensions are proposed to the pandoc format, I think it is
> important to understand how flexible the combination of pandoc, and
> what citeproc provides. I believe that pandoc can cover most of what
> you want.

> I also believe it would be a mistake to start from the idea of a
> pandoc-style citation syntax that deviates from pandoc. Better instead
> to start from what pandoc does now and find out what isn’t working for
> org-mode users before extending pandoc, especially in ways that are
> not compatible with pandoc.

Actually, I totally agree.  For my own use, I would be completely happy
with just using the Pandoc syntax for citations in Org, without any
modifications.

The only reason I proposed anything else was that it seemed like other
people already know that they need more than the Pandoc syntax provides.
I think the main realistic cases are those where, in LaTeX, you'd use
commands like \citetitle, \citedate, or \citejournal -- citation
commands that pull in just a particular field from the reference,
because that is what the context around the citation requires.  I don't
see a way to do that in the Pandoc syntax.  (But am I missing
something?)  Hence my proposed field-selectors extension.

Personally, I need commands like these so little that I am happy to do
without them.  So maybe my proposal was a bit hasty.  Could we hear from
other people about how badly they need what such commands provide?

> And if extensions are proposed, it would be best to propose them on
> the pandoc-discuss mailing list. It would be wonderful for users if
> the syntax in pandoc-markdown and org-mode could stay aligned.

Yes, I again totally agree.  If people here settle on a syntax that is
close, but not quite the same as, Pandoc's, I will certainly do that.

Best,
Richard

Re: [O] Citations, continued

[Erik Hetzner]

On Mon,  2 Feb 2015 at 10:02:41 PST,
Richard Lawrence  wrote:
> 
> Hi all,
> 
> Here is the citation syntax proposal I have mentioned in a couple of
> posts now.  I have attached it as an Org document for better
> readability, and also reproduced the text below.  Let me know what you
> think!

Hi Richard,

I am really, really glad to see people discussing citations in
org-mode. But I have some concerns about this proposal.

Before extensions are proposed to the pandoc format, I think it is
important to understand how flexible the combination of pandoc, and
what citeproc provides. I believe that pandoc can cover most of what
you want.

I also believe it would be a mistake to start from the idea of a
pandoc-style citation syntax that deviates from pandoc. Better instead
to start from what pandoc does now and find out what isn’t working for
org-mode users before extending pandoc, especially in ways that are
not compatible with pandoc.

And if extensions are proposed, it would be best to propose them on
the pandoc-discuss mailing list. It would be wonderful for users if
the syntax in pandoc-markdown and org-mode could stay aligned.

For more info on the flexibility of pandoc+citeproc, see
http://johnmacfarlane.net/pandoc/README.html#citations and
http://johnmacfarlane.net/pandoc/demos.html. It is also important to
distinguish what are features of the citeproc style (e.g. inline v.
footnote citations) and what are determined by the author and thus
should be present in the syntax (e.g. use or do not use a suffix or
locator).

From the example document:

1.   @item1 says blah.
2.   @item1 [p. 30] says blah.
3.   @item1 [p. 30, with suffix] says blah.
4.   @item1 [-@item2 p. 30; see also @item3] says blah.
5.   A citation group [see @item1 p. 34-35; also @item3 chap. 3].
6.   Another one [see @item1 p. 34-35].
7.   Citation with a suffix and locator [@item1 pp. 33, 35-37, and nowhere 
else].
8.   A citation without locators [@item3].
9.   Citation with suffix only [@item1 and nowhere else].
10.  Like a citation without author: [-@item1], and now Doe with a locator 
[-@item2 p. 44].

How this is rendered depends on the note style. In chicago author date it will 
have:

1.   Doe (2005) says blah.
2.   Doe (2005, 30) says blah.
3.   Doe (2005, 30, with suffix) says blah.
4.   Doe (2005; 2006, 30; see also Doe and Roe 2007) says blah.
5.   A citation group (see Doe 2005, 34–35; also Doe and Roe 2007, chap. 3).
6.   Another one (see Doe 2005, 34–35).
7.   Citation with a suffix and locator (Doe 2005, 33, 35–37, and nowhere else).
8.   A citation without locators (Doe and Roe 2007).
9.   Citation with suffix only (Doe 2005 and nowhere else).
10.  Like a citation without author: (2005), and now Doe with a locator (2006, 
44).

with a bibliography, while in chicago fullnote bibliography everything
will be in footnotes (this is easier to see in HTML:
http://johnmacfarlane.net/pandoc/demo/example24b.html) or attached.

best, Erik





Pandoc with citeproc-hs

1
2
John Doe3 says blah.
ibid.4 says blah.
ibid.5 says blah.
ibid.6 says blah.
In a note.7
A citation group.8
Another one.9
And another one in a note.10
Citation with a suffix and locator.11
Citation with suffix only.12
Now some modifiers.13
With some markup.14


References
Doe, John. “Article.” Journal of Generic Studies 6 (2006): 33–34.
———. First Book. Cambridge: Cambridge University Press, 2005.
Doe, John, and Jenny Roe. “Why Water Is Wet.” In Third Book, edited by Sam Smith. Oxford: Oxford University Press, 2007.




??? ↩
??? ↩
First Book (Cambridge: Cambridge University Press, 2005).↩
30.↩
30, with suffix.↩
“Article,” Journal of Generic Studies 6 (2006): 30; see also John Doe and Jenny Roe, “Why Water Is Wet,” in Third Book, ed. Sam Smith (Oxford: Oxford University Press, 2007).↩
A citation without locators Doe and Roe, “Why Water Is Wet..↩
See Doe, First Book, 34–35; also Doe and Roe, “Why Water Is Wet,” chap. 3. ↩
See Doe, First Book, 34–35. ↩
Some citations see Doe, “Article,” chap. 3; Doe and Roe, “Why Water Is Wet”; Doe, First Book.↩
Doe, First Book, 33, 35–37, and nowhere else. ↩
Ibid. and nowhere else. ↩
Like a citation without author: , and now Doe with a locator “Article,” 44.↩
See Doe, First Book, 32. ↩




--
Sent from my free software system .

Re: [O] Citations, continued

[Vikas Rawal]

Org-ref is very functional and has so far been able to deal with much of my 
needs. So, I just hope we are not trying to fix something that is not broken.

The real need in the context of citations is to somehow extend the 
bibtex/biblatex integration to other export formats (odt/html, most 
importantly). Will all the new stuff that is being proposed take us in that 
direction? 

Vikas



> On 03-Feb-2015, at 7:26 am, Richard Lawrence  
> wrote:
> 
> Hi Rasmus and all,
> 
> Thanks for your comments!
> 
> Rasmus  writes:
> 
>>> ** Backend-agnostic formatting properties
>>> *** Selecting specific fields
>>> Selecting specific fields to display could be done by appending field
>>> names to cite keys after colons, much like Org tags:
>>> #+BEGIN_QUOTE
>>> [See @Doe99, pp. 34--45; also @Doe00:year, section 6] 
>>> 
>>> [See their article in @Doe99:journal:year.] 
>>> #+END_QUOTE

Re: [O] Citations, continued

[Richard Lawrence]

Hi Rasmus and all,

Thanks for your comments!

Rasmus  writes:

>> ** Backend-agnostic formatting properties
>> *** Selecting specific fields
>> Selecting specific fields to display could be done by appending field
>> names to cite keys after colons, much like Org tags:
>> #+BEGIN_QUOTE
>> [See @Doe99, pp. 34--45; also @Doe00:year, section 6] 
>>
>> [See their article in @Doe99:journal:year.] 
>> #+END_QUOTE
>
> First, I think we should use @key for inline and (@key) for parenthesis
> expressions.  This give us two short keys.  [@Key ⋯] can be reserved for
> complicated references.

That sounds fine to me.  I think you may be using `inline' differently
than me, though: do you mean `author's name appears in the text (not in
parentheses)'?  (I was using it to talk about where the citation
definition appears in the document, not where the author's name appears
relative to parentheses.)

> I don't like "@Doe99:journal:year".  It's too unlike existing syntax.

I agree it's a little clunky, but I think most of the time there would
just be one selector.  I was thinking of this on analogy with heading
properties and tags...is there a better existing syntax to refer to a
property value?

> Rather, I'd just introduce types as hinted previously, [@Doe99 :type
> my-journal-year-type].  Org can provide as many predefined :type as we
> care for, and let the user define the rest as necessary.

I don't like this, because it seems like a lot more work for me as a
user to achieve something that should be simple, and it trades 
specifying /what/ data I want for describing it more indirectly.

Suppose I'm writing a document, and I know I just want to reference the
journal and year of a particular publication, in that order.  Being a
studious keeper of my org-bibtex database, I already know that these
fields are called "journal" and "year".  But if, in addition to
reference database field names, I have to remember names for /types/ of
/combinations/ of field names, that's too much.  I'll end up taking
endless trips to the manual to figure out which type I need in this
case.  Do I need :type journal-before-year? :type journal-and-year?
etc.  This feels a bit too much like having to remember (or look up) all
the different LaTeX citation commands.

I expect that many of the common cases would have the same name, but
then I still have to remember which of my uses are `common'.  And
[@Doe99:year] is less verbose than [@Doe99 :type year].

What about just separating the field names off, as keys?  Like:

[See Doe's review @Doe99 :journal :year]

>> When specific fields are requested, ONLY data from those fields should
>> appear in the exported document.  Backends would choose how to export
>> these citations based on the selected fields.
>
> What happens when a field is undefined?

I guess I would suggest the same thing as happens in LaTeX: you get a
nice, bold "??" in the output where the missing data should be. 

>> *** Non-cited works that should appear in the bibliography
>> A special field selector `:nocite' would be one way to achieve
>> citations that, for whatever reason, should appear in the Org source
>> and in the exported bibliography, but should not appear in the
>> exported text where they are placed.  This would allow referencing
>> them at relevant places in the document, like:
>> #+BEGIN_QUOTE
>> Smith said a lot of things, but no one can remember what they
>> were. [@Smith79:nocite]
>> #+END_QUOTE
>
> I think R-markdown uses something like [-@Smith79].  Again, I don't like
> the [@key:nocite].

Doesn't [-@Smith79] mean something different, namely, "cite @Smith79
without the author name"?  It produces output like: "(1979)".

The idea is that the :nocite selector produces no output, like LaTeX's
\nocite.  I don't know how important it is to have this, though.

>> *** Backend-specific formatting
>> In general, it would be nice to avoid formatting properties which are
>> specific to a particular export backend when a backend-agnostic
>> solution is available, but some backend-specific formatting needs are
>> probably inevitable, so we need a syntax for specifying them.
>>
>> Another advantage of the non-inline citation syntax is that it would
>> allow using the existing #+ATTR_BACKEND syntax to specify
>> backend-specific formatting properties, since the citation definitions
>> would be block-level elements:
>> #+BEGIN_QUOTE
>> * Citations
>>
>> #+ATTR_LATEX: :command citet
>> #+ATTR_HTML: :class my-citation
>> [cite:1] See @Doe99, pp. 34--45; @Foobar2000, ch.1.
>> #+END_QUOTE
>
> Why not.  Since footnote-definition is a greater element it /does/ take
> affiliated keywords, but I have never seen this used.

Right, that's the point here...(were you disagreeing?)

> For inline maybe something like this:
> [@Key :type_html my-citation :type_latex citet] 

Actually, this is a lot like the syntax I was thinking about for the
inline case, but in the end I thought it was too complicated and new to
be worth 

Re: [O] Citations, continued

[John Kitchin]

Thanks! I had been thinking about how to do that for a while, and seeing
Samuel's idea crytallized it for me. Thanks Samuel, and Tom for
remembering it from long ago.

yes that should also be possible. once you open the rabbit hole of
embedded lisp, many things are possible ;) even beyond citations.

One note might be related to security that is worth thinking about. org
is conservative in the beginning in making you choose to turn off the
questions asking do you want to run this for babel, shell and elisp. In
your example, you are opening a hole I think. Suppose this is buried
deep in the document ;)

[[slink:kitchin-2010 (:pre "See for example" :post "page 47" :type cite
:follow (lambda (x) (message-box "I could be a shell command. please
please please click me or export me!")))]]

I tried it, and indeed it runs that function.

... Anyway, that is totally possible by many other means right now with
links, so it is not totally new, but it is probably worth thinking about
a little since code execution like this could make it out to the export.

Anyway, I look forward to seeing where it goes!


Thomas S. Dye writes:

> Hi John,
>
> Wow.  It's inspiring to see Samuel's idea in action.
>
> Presumably, something like this would also be possible?
>
> ;;  follow function
> (lambda (path)
>   (let* ((data (read (concat "(" path ")")))
>  (head (car data))
>  (plist (cadr data)))
> (funcall (plist-get plist :follow) head)))
>
> [[slink:kitchin-2010 (:pre "See for example" :post "page 47" :type
> cite :follow #'ebib-open-org-link)]]
>
> All the best,
> Tom
>
> John Kitchin  writes:
>
>>> I'm glad you like Samuel's idea about extensible syntax for links.  I
>>> don't know if it is practical or not, but it was one of those ideas that
>>> seemed right on when I first read it.
>>
>> I am glad you mentioned, it was an inspiration! Although this is sure to
>> move away from a standard new syntax, it is straightforward to subvert a
>> link like the following example to get more readable pre/post text
>> example. The quotes are necessary to get the list read
>> correctly. Whether this is useful remains to be seen, but it was fun to
>> work it out.
>>
>> #+BEGIN_SRC emacs-lisp :results silent
>> (org-add-link-type
>>  "slink"
>>  ;;  follow function
>>  (lambda (path)
>>(let* ((data (read (concat "(" path ")")))
>>   (head (car data))
>>   (plist (cadr data)))
>>  (message-box "%s\n%s\n%s" head plist  (plist-get plist :type
>>  ;; format function
>>  (lambda (path description backend)
>>(let* ((data (read (concat "(" path ")")))
>>   (head (car data))
>>   (plist (cadr data)))
>>  (format "\\%s[%s][%s]{%s}"
>>  (plist-get plist :type)
>>  (plist-get plist :pre)
>>  (plist-get plist :post)
>>  head
>> #+END_SRC
>>
>>
>>
>> Exports to:
>>
>> #+BEGIN_EXAMPLE
>> \cite[See for example][page 47]{kitchin-2010}
>> #+END_EXAMPLE
>>
>>
>>
>>
>>>
>>> All the best,
>>> Tom
>>
>> --
>> Professor John Kitchin
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> @johnkitchin
>> http://kitchingroup.cheme.cmu.edu
>>
>>

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Citations, continued

[Thomas S. Dye]

Hi John,

Wow.  It's inspiring to see Samuel's idea in action.

Presumably, something like this would also be possible?

;;  follow function
(lambda (path)
  (let* ((data (read (concat "(" path ")")))
 (head (car data))
 (plist (cadr data)))
(funcall (plist-get plist :follow) head)))

[[slink:kitchin-2010 (:pre "See for example" :post "page 47" :type
cite :follow #'ebib-open-org-link)]]

All the best,
Tom

John Kitchin  writes:

>> I'm glad you like Samuel's idea about extensible syntax for links.  I
>> don't know if it is practical or not, but it was one of those ideas that
>> seemed right on when I first read it.
>
> I am glad you mentioned, it was an inspiration! Although this is sure to
> move away from a standard new syntax, it is straightforward to subvert a
> link like the following example to get more readable pre/post text
> example. The quotes are necessary to get the list read
> correctly. Whether this is useful remains to be seen, but it was fun to
> work it out.
>
> #+BEGIN_SRC emacs-lisp :results silent
> (org-add-link-type
>  "slink"
>  ;;  follow function
>  (lambda (path)
>(let* ((data (read (concat "(" path ")")))
>   (head (car data))
>   (plist (cadr data)))
>  (message-box "%s\n%s\n%s" head plist  (plist-get plist :type
>  ;; format function
>  (lambda (path description backend)
>(let* ((data (read (concat "(" path ")")))
>   (head (car data))
>   (plist (cadr data)))
>  (format "\\%s[%s][%s]{%s}"
>  (plist-get plist :type)
>  (plist-get plist :pre)
>  (plist-get plist :post)
>  head
> #+END_SRC
>
> 
>
> Exports to:
>
> #+BEGIN_EXAMPLE
> \cite[See for example][page 47]{kitchin-2010}
> #+END_EXAMPLE
>
>
>
>
>>
>> All the best,
>> Tom
>
> --
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Citations, continued

[Rasmus]

John Kitchin  writes:

> #+BEGIN_SRC emacs-lisp :results silent
> (org-add-link-type
>  "slink" ...)
> #+END_SRC

Thanks John, this is great!

I managed to chop down my citation setup to the following:

[[cite:key :pre pre :post post :type type]]

with reasonable support for other backends.  I only use bibtex and I used
to separate pre/post with ";" so there's some legacy code in there.
Everything is hard-coded to my system/taste, written quickly and (very)
lightly tested, but maybe it will still be useful to somebody. . .

—Rasmus


(with-eval-after-load 'org
  (require 'reftex-cite)
  
  (defmacro rasmus/org-bib-add-type (type)
;; TODO: maybe this can be made more effective?
;; Seems to work OK...
`(org-add-link-type
  ,type
  'rasmus/org-bib-follow
  ,(lambda (path description backend)
 (funcall 'rasmus/org-bib-format path description backend
  ;; cite defaults to textcite
  (if (equal type "cite") "textcite" type)
  
  (mapc (lambda (type) (funcall 'rasmus/org-bib-add-type type))
'("cite" "textcite" "parentcite" "citeyear" "citeauthor"))
  
  (defun rasmus/org-bib-follow (path)
"Find the pdf version of citation."
(let* ((stream (read (format "(%s)" path
  (rasmus/find-lit (car head

  (defun rasmus/find-lit (key)
"Open pdf file associated with KEY from `reftex-default-bibliography'."
(let* ((bib (file-name-directory (car reftex-default-bibliography)))
   (file (concat bib path (concat "/" key ".pdf"
  (when (file-exists-p file) (find-file file

  (defun rasmus/org-bib-format (path description backend &optional type*)
"Format a org-link citation.

Support links of the type

[[type*:key :pre PRE :post POST :type TYPE**]]

Or

[[Key*:key][POST;PRE]]

Based on John K's great post here:
http://permalink.gmane.org/gmane.emacs.orgmode/94575";
(let* ((key
;; key is a single symbol by assumption
(and (string-match "\\` *\\([^ ]+\\) *" path)
 (prog1 (match-string 1 path)
   (setq path (replace-match "" nil nil path)
   ;; generate plist
   (data (read (format "(%s)"
   (replace-regexp-in-string
"\\(:\\w+\\) \\([^:]+\\) ?" "\\1 \"\\2\" "
path
   (type (or (plist-get data :type) type* "textcite"))
   (pre  (org-trim (or (plist-get data :pre)
   ;; support my "old" syntax
   (and description
(cadr (split-string description ";"))) "")))
   (post (org-trim
  (or (funcall (lambda (txt)
 (and txt
  (let ((res (string-to-number txt)))
(if (zerop res) txt
  (concat (if (> (length txt) 1)  "pp." 
"p.") " " txt)
   (plist-get data :post))
  (and description
   (car (split-string description ";")))
  "")))
   (entry (or (save-window-excursion
(bibtex-search-entry key t 0)
(bibtex-parse-entry))
  (error (format "unknown key: %s" key
   (author (or (reftex-format-citation entry "%2a") ""))
   (year (or  (reftex-format-citation entry "%y") "")))
  (if (org-export-derived-backend-p backend 'latex)
  (format "\\%s[%s][%s]{%s}" type pre post key)
;; TODO: This should probably be wrapped in . with html...
(cl-case (intern type)
  (parencite
   (format "(%s %s %s %s)"
   pre author
   (or (and (org-string-nw-p year) (concat year ", ")) "")
   post))
  (citeyear
   (format "%s %s %s" pre year post))
  (citeauthor
   (format "%s %s %s" pre author post))
  (fullcite
   (reftex-format-citation entry reftex-cite-view-format))
  (t ;; textcite
   (format "%s (%s%s%s)"
   author
   (and (org-string-nw-p pre) (concat pre " "))
   year
   (and (org-string-nw-p post) (concat ", " post)


-- 
Dung makes an excellent fertilizer

[O] Bug: agenda interaction with org-agenda-dim-blocked-tasks, org-agenda-max-entries and org-enforce-todo-dependencies [8.3beta (release_8.3beta-785-gb5d9f4 @ /Users/yn/dotfiles/org.emacs.d/org-mode/

[Yuri Niyazov]

Consider the following org file:
* Tasks
** Ordered Tasks
:PROPERTIES:
:ORDERED:  t
:END:
*** TODO Module 1
 TODO Item 1
SCHEDULED: <2015-02-01 Sun>
 TODO Item 2
SCHEDULED: <2015-02-01 Sun>
*** TODO Module 2
 TODO Item 3
SCHEDULED: <2015-02-01 Sun>
 TODO Item 4
SCHEDULED: <2015-02-01 Sun>
** Other Tasks
*** TODO Random Task 1
SCHEDULED: <2015-02-01 Sun>
*** TODO Random Task 2
SCHEDULED: <2015-02-01 Sun>

What I would expect to happen: loading up the agenda shows four items:
Item 1, Item 2, Random Task 1, Random Task 2

What actually happens: The agenda shows only two items:
Item 1, Item 2.

This starts happening when org-agenda-dim-blocked-tasks is set to
invisible. What seems to happen is that the blocked tasks, even though
they are invisible, are still counted towards org-agenda-max-entries.


Emacs  : GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS
apple-appkit-1265.21)
 of 2014-10-22 on burry.local
Package: Org-mode version 8.3beta (release_8.3beta-785-gb5d9f4 @
/Users/yn/dotfiles/org.emacs.d/org-mode/lisp/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-agenda-max-entries 4
 org-default-notes-file "Capture.org"
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-dim-blocked-tasks 'invisible
 org-mode-hook '(org-clock-load
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-show-block-all
append
local]
   5]
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook
org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 auto-indent-turn-on-org-indent)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-directory "~/dotfiles/org.emacs.d/org-files-debug/"
 org-enforce-todo-dependencies t
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
 org-agenda-files '("~/dotfiles/org.emacs.d/org-files-debug/")
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] Citations, continued

[Rasmus]

Hi,

Richard Lawrence  writes:

> Here is the citation syntax proposal I have mentioned in a couple of
> posts now.

Thanks.  I think it's a good start, but I find it too far away from Org in
some respects.  Hence comments follow.

> ** Backend-agnostic formatting properties
> *** Selecting specific fields
> Selecting specific fields to display could be done by appending field
> names to cite keys after colons, much like Org tags:
> #+BEGIN_QUOTE
> [See @Doe99, pp. 34--45; also @Doe00:year, section 6] 
>
> [See their article in @Doe99:journal:year.] 
> #+END_QUOTE

First, I think we should use @key for inline and (@key) for parenthesis
expressions.  This give us two short keys.  [@Key ⋯] can be reserved for
complicated references.

I don't like "@Doe99:journal:year".  It's too unlike existing syntax.

Rather, I'd just introduce types as hinted previously, [@Doe99 :type
my-journal-year-type].  Org can provide as many predefined :type as we
care for, and let the user define the rest as necessary.

> Note that this would make for an extension of Pandoc syntax.  This
> extension is not a strict superset, since Pandoc allows internal `:'
> characters in cite keys, and thus would treat `@Doe99:journal:year' as
> a single key, rather than treating the key as ending at the first
> colon, with other data afterward.

Compatibility with pandoc is a non-issue IMO.  If that's necessary we can
use ox.

> When specific fields are requested, ONLY data from those fields should
> appear in the exported document.  Backends would choose how to export
> these citations based on the selected fields.

What happens when a field is undefined?

> *** Non-cited works that should appear in the bibliography
> A special field selector `:nocite' would be one way to achieve
> citations that, for whatever reason, should appear in the Org source
> and in the exported bibliography, but should not appear in the
> exported text where they are placed.  This would allow referencing
> them at relevant places in the document, like:
> #+BEGIN_QUOTE
> Smith said a lot of things, but no one can remember what they
> were. [@Smith79:nocite]
> #+END_QUOTE

I think R-markdown uses something like [-@Smith79].  Again, I don't like
the [@key:nocite].


> One drawback of this syntax is that it does not provide an easy way to
> list all the nocite references, since the user would have to add
> `:nocite' to each one individually.  This is not a huge problem for
> small numbers of refernces, but it would also be nice to have some
> equivalent of LaTeX's \nocite{*}.  On this point, see the proposal for
> non-inline citation definitions below.

#+NOCITE: key1 ⋯ keyN

> ** Non-inline citation definitions and backend-specific formatting
> [...]
> #+BEGIN_QUOTE
> Doe provides an interesting analysis. [cite:1]
> ...
> * Citations
> [cite:1] See @Doe99, pp. 34--45; also @Doe2000:year, ch. 1.
> #+END_QUOTE

This is cool.  I'd use it in some cases.

> That is, a citation /pointer/ would occur inline in the document text,
> which refers (via a number or a label) to a citation /definition/ in a
> specially-named subtree.

It would refer to it anywhere.  No reason to make it different from
footnotes.

> *** Backend-specific formatting
> In general, it would be nice to avoid formatting properties which are
> specific to a particular export backend when a backend-agnostic
> solution is available, but some backend-specific formatting needs are
> probably inevitable, so we need a syntax for specifying them.
>
> Another advantage of the non-inline citation syntax is that it would
> allow using the existing #+ATTR_BACKEND syntax to specify
> backend-specific formatting properties, since the citation definitions
> would be block-level elements:
> #+BEGIN_QUOTE
> * Citations
>
> #+ATTR_LATEX: :command citet
> #+ATTR_HTML: :class my-citation
> [cite:1] See @Doe99, pp. 34--45; @Foobar2000, ch.1.
> #+END_QUOTE

Why not.  Since footnote-definition is a greater element it /does/ take
affiliated keywords, but I have never seen this used.

For inline maybe something like this:
[@Key :type_html my-citation :type_latex citet] 


> *** Bibliography-only entries
> Non-inline definitions would also provide a convenient place to list
> non-cited references that should appear in the bibliography.  For
> example:
> #+BEGIN_QUOTE
> * Citations
> ...
> [nocite:] @Doe99; @Foobar2000; @Baz98.
> #+END_QUOTE

As stated above, I find #+NOCITE more in line with current syntax.

> * Document metadata
> In addition to the syntax of citations themselves, the Org document
> would also need to represent the following metadata to support
> citations:
> 7. [@7] a pointer to one or more backend reference databases,
>including in-document databases in org-bibtex format

If org-bibtex entries are present they should just take precedence.  That
way you can easily insert new entries and customize them for your project
and have a portable document.

> 8. a referen

Re: [O] Citations, continued

[John Kitchin]

> I'm glad you like Samuel's idea about extensible syntax for links.  I
> don't know if it is practical or not, but it was one of those ideas that
> seemed right on when I first read it.

I am glad you mentioned, it was an inspiration! Although this is sure to
move away from a standard new syntax, it is straightforward to subvert a
link like the following example to get more readable pre/post text
example. The quotes are necessary to get the list read
correctly. Whether this is useful remains to be seen, but it was fun to
work it out.

#+BEGIN_SRC emacs-lisp :results silent
(org-add-link-type
 "slink"
 ;;  follow function
 (lambda (path)
   (let* ((data (read (concat "(" path ")")))
  (head (car data))
  (plist (cadr data)))
 (message-box "%s\n%s\n%s" head plist  (plist-get plist :type
 ;; format function
 (lambda (path description backend)
   (let* ((data (read (concat "(" path ")")))
  (head (car data))
  (plist (cadr data)))
 (format "\\%s[%s][%s]{%s}"
 (plist-get plist :type)
 (plist-get plist :pre)
 (plist-get plist :post)
 head
#+END_SRC

[[slink:kitchin-2010 (:pre "See for example" :post "page 47" :type cite)]]

Exports to:

#+BEGIN_EXAMPLE
\cite[See for example][page 47]{kitchin-2010}
#+END_EXAMPLE




>
> All the best,
> Tom

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Citations, continued

[John Kitchin]

You can color your own links like this:

 (highlight-regexp "cite:\\([a-zA-Z0-9]*[-_:]*\\)*" 'dired-warning)

 (highlight-regexp "citenum:\\([a-zA-Z0-9]*[-_:]*\\)*" 'dired-marked)

The regexps are not as robust as what org uses, the plain link on my
system looks like:

"\\<\\(Autocite[*s]?\\|Cite\\(?:a\\(?:l[pt]\\|uthor\\*?\\)\\|[pst]\\)?\\|Gls\\(?:pl\\)?\\|Notecite\\|P\\(?:arencites?\\|notecite\\)\\|ResearcherID\\|Smartcites?\\|Textcites?\\|a\\(?:dd\\(?:bibresource\\|ressbook\\)\\|ns\\|ssignment\\|ttachfile\\|utocite[*s]?\\)\\|b\\(?:bdb\\|ib\\(?:entry\\|liography\\(?:style\\)?\\|tex\\)\\)\\|cite\\(?:a\\(?:l\\(?:[pt]\\*\\|[pt]\\)\\|uthor\\*?\\)\\|date\\*?\\|num\\|p\\*\\|t\\(?:\\*\\|ext\\|itle\\*?\\)\\|url\\|year\\*?\\|[*pst]\\)?\\|do\\(?:cview\\|i\\)\\|e\\(?:l\\(?:feed\\|isp\\)\\|qref\\|xercise\\)\\|f\\(?:ile\\(?:\\+\\(?:\\(?:emac\\|sy\\)s\\)\\)?\\|notecite\\|oot\\(?:cite\\(?:s\\|texts?\\)?\\|fullcite\\)\\|tp\\|u\\(?:llcite\\|nc\\)\\)\\|g\\(?:ls\\(?:pl\\)?\\|nus\\|oogle\\)\\|https?\\|i\\(?:d\\|n\\(?:dex\\|fo\\)\\|rc\\)\\|l\\(?:abel\\|ist-of-\\(?:\\(?:figur\\|tabl\\)es\\)\\)\\|m\\(?:a\\(?:c-outlook\\|ilto\\)\\|c\\|essage\\|he\\|od\\|sx\\|u4e\\)\\|n\\(?:ameref\\|ew\\(?:glossaryentry\\|s\\)\\|ihmsid\\|o\\(?:bibliography\\|\\(?:te\\)?cite\\)\\)\\|orcid\\|p\\(?:a\\(?:geref\\|rencite[*s]?\\)\\|m\\(?:c?id\\)\\|notecite\\|rint\\(?:bibliography\\|index\\)\\|ydoc\\)\\|r\\(?:ef\\|mail\\)\\|s\\(?:hell\\|kim\\|link\\|martcites?\\|olution\\|upercites?\\)\\|t\\(?:extcites?\\|q-index\\)\\|x-together-item\\):\\([^
\n()<>]+\\(?:([[:word:]0-9_]+)\\|\\([^[:punct:]
\n]\\|/\\)\\)\\)"


But, if you put that in init files, then your links will be colored the
way you want them.

Thomas S. Dye writes:

> Hi John,
>
> John Kitchin  writes:
>
>>> Now, I agree with you that Org mode links are not ideal for citations.
>>> Parsing the description is humbug and error-prone, and the descriptions
>>> look ungainly in the Org mode document.  I never remember to click
>>> citation links in the "right" place!  There is much room for improvement
>>> here.
>>
>> I am not sure how much better it could get. What did you have in mind? I
>> could imagine for a cite link with several citations the click action
>> could give you an ido-completing/helm selection buffer and you choose
>> what you want to do from there. In org-ref the click action is user
>> definable, so you can get what you want.
>
> I didn't mean to imply any criticism of org-ref, which I haven't used.
> I've been using my own home-grown solution for several years now, have
> grown used to its limitations, and of course now have all those legacy
> documents to support ...
>
> It would be nice to have the link syntax extended or generalized to
> indicate pre- and post-note text, so my home-grown system would use
> links compatible with org-ref, say.  I really like the direction Richard
> is heading for this reason.  If the distinctions needed for citations
> were recognized in the Org mode core, then citation links used by
> different systems might be compatible with one another.
>
> More control over how links are displayed would be nice (perhaps let the
> user pass in a function?).  When I first worked on setting up citations,
> I thought it would be great to color citation links differently from
> other links, and I still kind of like that idea.  Also, in my setup, I
> don't want to see the full link because the bibtex keys are long and the
> full links really break up the flow of the text.  Among other things,
> this means I can't be sure just looking at the buffer in its typical
> state what kind of link I'm using (footcite, parencite, textcite, etc.).
> A little indicator of some kind would be really nice here, but I haven't
> found an easy way to display one.
>
> I'm glad you like Samuel's idea about extensible syntax for links.  I
> don't know if it is practical or not, but it was one of those ideas that
> seemed right on when I first read it.
>
> All the best,
> Tom

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Citations, continued

[Thomas S. Dye]

Hi John,

John Kitchin  writes:

>> Now, I agree with you that Org mode links are not ideal for citations.
>> Parsing the description is humbug and error-prone, and the descriptions
>> look ungainly in the Org mode document.  I never remember to click
>> citation links in the "right" place!  There is much room for improvement
>> here.
>
> I am not sure how much better it could get. What did you have in mind? I
> could imagine for a cite link with several citations the click action
> could give you an ido-completing/helm selection buffer and you choose
> what you want to do from there. In org-ref the click action is user
> definable, so you can get what you want.

I didn't mean to imply any criticism of org-ref, which I haven't used.
I've been using my own home-grown solution for several years now, have
grown used to its limitations, and of course now have all those legacy
documents to support ...

It would be nice to have the link syntax extended or generalized to
indicate pre- and post-note text, so my home-grown system would use
links compatible with org-ref, say.  I really like the direction Richard
is heading for this reason.  If the distinctions needed for citations
were recognized in the Org mode core, then citation links used by
different systems might be compatible with one another.

More control over how links are displayed would be nice (perhaps let the
user pass in a function?).  When I first worked on setting up citations,
I thought it would be great to color citation links differently from
other links, and I still kind of like that idea.  Also, in my setup, I
don't want to see the full link because the bibtex keys are long and the
full links really break up the flow of the text.  Among other things,
this means I can't be sure just looking at the buffer in its typical
state what kind of link I'm using (footcite, parencite, textcite, etc.).
A little indicator of some kind would be really nice here, but I haven't
found an easy way to display one.

I'm glad you like Samuel's idea about extensible syntax for links.  I
don't know if it is practical or not, but it was one of those ideas that
seemed right on when I first read it.

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] Citations, continued

[Rasmus]

Hi,

Richard Lawrence  writes:

> Hi Rasmus and all,
>
> Rasmus  writes:
>
>> Richard Lawrence  writes:
>
>>> Within a citation, each reference to an individual work needs to be
>>> capable of containing:
>>>   1) a database key that references the cited work
>>>   2) prefix / pre-text
>>>   3) suffix / post-text
>>>   4) references to page/chapter/section/whatever numbers and ranges.
>>>  This is likely part of the prefix or suffix, but might be worth
>>>  parsing separately for localization or link-following behavior.
>>>   5) a way of indicating backend-agnostic formatting properties.
>>>  Examples of some properties users might want to specify are:
>>
>>>  - displaying only some fields (or suppressing some fields) from a
>>>reference record (e.g., journal, date, author)
>>
>> Would this not be properties of the bibliography and not the citation?
>
> No, I mean things that can vary from one citation to the next -- like
> what you'd write in LaTeX as
>
> \citet{Doe99} once thought foo, but in his \citeyear{Doe2014}, he
> revises his position to bar.

Okay, I misunderstood you then.q I though you wanted something like
\AtEveryBibitem (of biblatex) which literally alters fields, e.g.:
\AtEveryBibitem{\clearfield{month}}.

>>> Citations as a whole also need:
>>>   6) [@6] a way of indicating formatting properties for specific export
>>>  backends.
>> I think the idea would be /not/ to have to consider specific backends.  If
>> you want special properties (say bold) for HTML could it not be solved by
>> a macro or a filter?  Probably I'm misunderstanding.
> [...]
> use a particular citation command for this citation, or the HTML backend
> to use/add a particular CSS class.  Maybe this could be done with macros
> or filters, but I think that would prove complicated for all but the
> simplest cases, since citations have argument structure that filters
> might not necessarily `see'.

I see.  It's possible via macros.  I don't have strong opinions on this.

>>>   8) a reference to a citation style or style file
>>
>> How does this work outside of LaTeX?
>
> Well, Pandoc for example processes citations using the citeproc-hs

It seems to use pandoc-citeproc which is based on citeproc-hs.

> implementation of the Citation Style Language, which is an XML format
> that allows describing how citations and bibliographies should be
> formatted.  Thus, for example, you could tell Pandoc to process your
> citations in APA style, or any of the other styles in this repo:
>
> https://www.zotero.org/styles
>
> CSL is an XML format, and I shudder to think about implementing it in
> Elisp, but that's how its done.  In fact, Pandoc uses this even for
> LaTeX output, rather than trying to map citations to the various \cite
> commands.

I wonder if Zotero can be used to format such citations.  It can do
something for rtf at least:

https://www.zotero.org/support/rtf_scan

—Rasmus

-- 
A page of history is worth a volume of logic

Re: [O] Citations, continued

[Richard Lawrence]

Hi all,

Here is the citation syntax proposal I have mentioned in a couple of
posts now.  I have attached it as an Org document for better
readability, and also reproduced the text below.  Let me know what you
think!

Best,
Richard


#+TITLE: A Proposal for Org citation syntax
#+AUTHOR: Richard Lawrence

* Introduction
In brief, the proposal is:

1. Use the Pandoc syntax for basic, inline citations.
2. Extend the Pandoc syntax modestly to accommodate backend-agnostic
   formatting of inline citations.
3. Also allow non-inline citation definitions, with a syntax
   comparable to non-inline footnotes, to accommodate
   backend-specific formatting.

Basing this proposal on the Pandoc syntax is a `merely practical'
choice.  It might not be the most Org-like, and it might produce too
much conceptual divergence between citations and links.  But it is a
syntax that is already well-tested and known to work elsewhere, and
which has easily-scriptable tools for processing it (namely, Pandoc's
own), which Org users could rely on in the meantime, while Org's own
implementation of this syntax catches up.

Beyond the features provided by the basic Pandoc syntax, I have tried
to ensure that the other features are as Org-like as possible, are
already in use in Org documents, and (I hope) could be implemented
with minimal work.

* Citation syntax
(I repeat the list of requirements I posted earlier here, for easy
reference; so far, I don't think anyone has suggested we need any
others.)

A citation is a textual reference to one or more individual works,
together with other information about those works, grouped together in
a single place.

Within a citation, each reference to an individual work needs to be
capable of containing:
1. a database key that references the cited work
2. prefix / pre-text
3. suffix / post-text
4. references to page/chapter/section/whatever numbers and ranges.
   This is likely part of the prefix or suffix, but might be worth
   parsing separately for localization or link-following behavior.
5. a way of indicating backend-agnostic formatting properties.
   Examples of some properties users might want to specify are:
   - displaying only some fields (or suppressing some fields) from a
 reference record (e.g., journal, date, author)
   - indicating that the referenced works should *only* appear in
 the bibliography of the exported document (equivalent of LaTeX
 \nocite)

Citations as a whole also need:
6. [@6] a way of indicating formatting properties for specific export
   backends.  Examples of some properties that users might want to
   specify are:
   - a citation command to use for each individual reference (LaTeX;
 others?)
   - a multi-cite command to apply to all references together
 (LaTeX)
   - CSS or other styling class (HTML and derived backends; also
 ODT?)
   - properties describing how to treat emphasis and other
 formatting that cannot appear in plain text (ASCII and other
 plain text backends)

** Starting point
I assume, to start, the basic Pandoc [ ... @key1 ...; ... @key2 ...]
syntax for inline citations, documented 
[[http://pandoc.org/README.html#citations][here]].  This defines a syntax
for inline citations that allows grouping multiple individual
references together between brackets, with semicolons as separators.

Previous discussions have suggested beginning citation definitions
with a tag, like [cite: ...] or [citation: ...], by analogy with
footnotes and links.  As far as I can see, the tag doesn't really
provide any advantages for inline citations, and is just unnecessary
markup.  This is because the syntax of citations is (or should be)
more constrained than footnotes or links; a citation is already
recognizable, and parseable as such, by the required presence of a
reference key.  The tag would also immediately break compatibility
with the basic Pandoc syntax if it were required for inline citation
definitions, a result which I am trying to avoid in this proposal.

A syntax for /non-inline/ citation definitions, however, comparable to
the syntax for footnotes, would make good use of such a tag.  This is
what I propose below.

** Backend-agnostic formatting properties
*** Selecting specific fields
Selecting specific fields to display could be done by appending field
names to cite keys after colons, much like Org tags:
#+BEGIN_QUOTE
[See @Doe99, pp. 34--45; also @Doe00:year, section 6] 

[See their article in @Doe99:journal:year.] 
#+END_QUOTE
Note that this would make for an extension of Pandoc syntax.  This
extension is not a strict superset, since Pandoc allows internal `:'
characters in cite keys, and thus would treat `@Doe99:journal:year' as
a single key, rather than treating the key as ending at the first
colon, with other data afterward.  (More compatible but uglier
alternatives for the field selector include `!', `{', `}', and `^'.
If an alternative is desired, I suggest `@Doe99{journal,year}'.)

When specific fields are requested, ONL

Re: [O] Citations, continued

[Richard Lawrence]

Hi Rasmus and all,

Rasmus  writes:

> Richard Lawrence  writes:

>> Within a citation, each reference to an individual work needs to be
>> capable of containing:
>>   1) a database key that references the cited work
>>   2) prefix / pre-text
>>   3) suffix / post-text
>>   4) references to page/chapter/section/whatever numbers and ranges.
>>  This is likely part of the prefix or suffix, but might be worth
>>  parsing separately for localization or link-following behavior.
>>   5) a way of indicating backend-agnostic formatting properties.
>>  Examples of some properties users might want to specify are:
>
>>  - displaying only some fields (or suppressing some fields) from a
>>reference record (e.g., journal, date, author)
>
> Would this not be properties of the bibliography and not the citation?

No, I mean things that can vary from one citation to the next -- like
what you'd write in LaTeX as

\citet{Doe99} once thought foo, but in his \citeyear{Doe2014}, he
revises his position to bar.

The second citation should only display the year, since the author's
name has already been mentioned in the sentence.  This type of
formatting information would be nice to represent regardless of export
backend.

>> Citations as a whole also need:
>>   6) [@6] a way of indicating formatting properties for specific export
>>  backends.
>
> I think the idea would be /not/ to have to consider specific backends.  If
> you want special properties (say bold) for HTML could it not be solved by
> a macro or a filter?  Probably I'm misunderstanding.

I agree that we should probably want to minimize and segregate
backend-specific formatting information, but it is inevitable that
someone will need this ability; and I'm a `provide reasonable defaults,
but also an escape hatch when you need it' kind of guy.

The things I have in mind are things like telling the LaTeX backend to
use a particular citation command for this citation, or the HTML backend
to use/add a particular CSS class.  Maybe this could be done with macros
or filters, but I think that would prove complicated for all but the
simplest cases, since citations have argument structure that filters
might not necessarily `see'.

>> In addition to the syntax of citations themselves, the Org document
>> would also need to represent the following metadata to support
>> citations:
>>   7) [@7] a pointer to one or more backend reference databases,
>>  including in-document databases in org-bibtex format
>
> This would be a huge win.
>
>>   8) a reference to a citation style or style file
>
> How does this work outside of LaTeX?

Well, Pandoc for example processes citations using the citeproc-hs
implementation of the Citation Style Language, which is an XML format
that allows describing how citations and bibliographies should be
formatted.  Thus, for example, you could tell Pandoc to process your
citations in APA style, or any of the other styles in this repo:

https://www.zotero.org/styles

CSL is an XML format, and I shudder to think about implementing it in
Elisp, but that's how its done.  In fact, Pandoc uses this even for
LaTeX output, rather than trying to map citations to the various \cite
commands.
 
>>   9) a reference to a locale file
>
> There's already a #+BIBLIOGRAPHY or #+REFERENCES in ox-bibtex.el.  But
> it's quite limited.

Yes, I think we should leverage this but modify its syntax a bit.

Best,
Richard

Re: [O] Bug: 8.2.10 fails to insert diary entry [as opposed to 8.3beta (release_8.3beta-785-gb5d9f4 @ /home/grfz/src/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Gregor Zattler  writes:

> Dear org-mode developers,
>
> from the agenda I want to add an entry to the diary.  When I do
>
> emacs24 -Q -nw
> M-x org-mode
> M-x org-agenda
> a
> i
> d
>
> I get:
>
> Diary entry: [d]ay [w]eekly [m]onthly [y]early [a]nniversary [b]lock [c]yclic
> org-agenda-diary-entry: Wrong type argument: commandp,
>
> and nothing happens.

Could you provide a more complete backtrace, possibly with
a non-compiled Org (C-u M-x org-reload)?

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-agenda-diary-entry messes with datetree in org-agenda-diary-file [8.3beta (release_8.3beta-785-gb5d9f4 @ /home/grfz/src/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Gregor Zattler  writes:

> Dear org-mode developers,
>
> adding a date to the datetree in the org-agenda-diary-file
> produces a mess:
>
> - emacs-snapshot -Q -L /home/grfz/src/org-mode/lisp/ -nw –eval (setq 
> org-agenda-diary-file "/tmp/diary.org")
> - Mx org-agenda
> - a
> - i
> - d
> - error
>
> gives:
>

>
> * 2015
> ** 2015-02 Februar
> <2015-02-01 So>*** 2015-02-01 Sonntag
>  error
>
> 
>
>
> instead of:
>

> * 2015
> ** 2015-02 Februar
> *** 2015-02-01 Sonntag
>  error
> <2015-02-01 So>
> 

This should be fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Citations, continued

[Richard Lawrence]

t...@tsdye.com (Thomas S. Dye) writes:

> You and others are advocating a separate syntax for links and citations,
> which might indeed be the way to go.  I can see it being much nicer than
> the current state of affairs with Org mode links.  The downside is that
> it will mean learning another set of rules, in addition to the existing
> rules for links.

Yes, I agree, and I see the import of this concern.  Links and citations
have enough similarities that some more generalized syntax could
probably cover them both, as you suggest below.

The main upside, as I see it, of adopting a totally different syntax for
citations is that we have the option to adopt a syntax that is already
known to be good enough (for some set of uses) and to work with other
tools (like Pandoc).  But this is a `merely practical' concern and maybe
does not outweight the considerations above.

> Several years ago, Samuel Wales suggested an extensible syntax example
> using link features
> (https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html).
> At the time it seemed to me that this was a Lisp-y approach because it
> solved particular problems by generalizing or abstracting a language
> feature to include particulars that had previously fallen outside its
> ken.  I wanted something like this while I was working on implementing
> citation links for export to LaTeX.
>
> Would it be feasible to generalize Org mode's link syntax, or make it
> extensible, so the overlap of link with citation is complete?  

This is an interesting idea!

I think the minimal change that would be necessary would be to allow the
new extended links (call them `elinks' for short) to be defined in such
a way that they can have varying numbers of significant parts, depending
on the type.  An elink definition for a given type would specify a
number and order of parts.  All elinks would use the same syntax to
delimit the parts.  To keep things simple and more or less consistent
with the existing syntax, we could just surround each part with square
brackets, and assume that only the first part is required.

Thus, the relevant definitions could look like:

href: URL DESCRIPTION
cite: KEY PRE-TEXT POST-TEXT 

with examples like:

[href: [http://www.google.com]]
[href: [http://www.google.com][Evil search engine]]

[cite: [Smith99]]
[cite: [Smith99][Cf.]]
[cite: [Smith99][Cf.][for a discussion]]

though this doesn't quite solve the readability problem with having
optional pre and post text appear after the key.

In theory, this syntax could even allow complicated nestings:

multi-cite: CITE-ELINK ...

[multi-cite: [cite: [Smith99]]
 [cite: [Doe2000]]
 [cite: [Foobar2014][a summary appears in]]
 [cite: [Baz2014][][which is available at [href: [http://baz.org

though that might quickly get unwieldy (especially for non-Lispers). :)

Link handlers would become functions that accept one argument plus a
&rest list, and the choice of link handler would dispatch on the type.

An alternative to the brackets would be to use something like plist
syntax for the optional arguments (as Samuel originally suggested and
Rasmus has echoed).  Links would really just start to look like Lisp
function calls. 

I'm just spitballing here; not sure I'd ultimately endorse something
like this, but I think it's worthwhile to explore the question of how
link and citation syntax could usefully be generalized.

Best,
Richard

Re: [O] org-agenda-other-frame

[Kyle Meyer]

torys.ander...@gmail.com (Tory S. Anderson) wrote:
> I have a key which calls `gnus-other-frame`, a handy function that not
> only pops up a gnus frame, but also kills the frame when I exit
> gnus. I'd like something similar with my org agenda; the following
> function is used to pop it up, but I'm not sure how to kill the frame
> when I hit close the agenda (i.e. hitting `q`). The result should work
> whether I'm using sticky agenda or not. Any suggestions?

Does 

(setq org-agenda-window-setup 'other-frame)

do what you want?

-- 
Kyle

Re: [O] Citations, continued

[Erik Hetzner]

On Sat, 31 Jan 2015 at 10:26:05 PST,
Richard Lawrence  wrote:
> 
> Hi all,
>
> […]
>
> As I mentioned in the earlier thread, I think the Pandoc syntax is a
> good place to start, and I think it would be valuable to have the two
> syntaxes be compatible.  But even Pandoc's citation syntax might not be
> general enough to satisfy everyone's needs, so the first step for
> introducing citation syntax to Org should be compiling a list of all the
> things such a syntax should represent.

Hi Richard,

It would probably be worth reviewing the discussions that led to the
pandoc citation syntax:

  https://groups.google.com/d/msg/pandoc-discuss/v54VxMXtoWM/7ezu4xDSN8gJ

Of the requirements you later mentioned:

>   1) a database key that references the cited work
>   2) prefix / pre-text
>   3) suffix / post-text
>   4) references to page/chapter/section/whatever numbers and ranges.
>  This is likely part of the prefix or suffix, but might be worth
>  parsing separately for localization or link-following behavior.
>   5) a way of indicating backend-agnostic formatting properties.
>  Examples of some properties users might want to specify are:
>  - displaying only some fields (or suppressing some fields) from a
>reference record (e.g., journal, date, author)
>  - indicating that the referenced works should *only* appear in
>the bibliography of the exported document (equivalent of LaTeX
>\nocite)

pandoc syntax handles 1, 2, 3, 4 (locator, which is separate from
suffix) and some of 5 (author suppression; I’m not sure the use cases
for journal/date/etc. suppression). It does not handle \nocite, but
this is something that they have discussed in the past and could
easily be supported in org-mode using, e.g. a #+NO_CITE block.
Personally I feel this covers the 99% of uses while being human
readable and writable.

I agree that citekey management is something that should be handle
separately, as this will depend on the backend (bibtex file, zotero,
etc.) Whether these citekeys are also links doesn’t really matter that
much either and could depend on the backend.

best, Erik
--
Sent from my free software system .

Re: [O] Citations, continued

[Matt Price]

I have very little of substance to say, but many thanks to Richard for
raising the level of discourse to a much more sophisticated one than I was
able to achieve in my initial post.

I don't feel qualified to comment on whether links or a new citation syntax
is appropriate.  But I do think that Richard and the rest of you have
identified the key features that any future syntax should follow.  I guess
I would emphasize that Richard's insistence on the experience of a document
writer is very important -- it should be straightforward to add citations
from whatever sources we use, to read and work with those citations in org
itself, and to export them painlessly to the other major formats in which
our work is shared (I think the main ones right now and for the foreseeable
future are LaTex, ODT/Docx, and HTML). And that should be true even for
people who are not so good at fiddling with presentation details.

>From my perspective, citation support is really the only writerly feature
"missing" from org; if it can be put in place, I will be thrilled and
thankful.

Finally, I did want to describe one other syntax I've recently learned
about, which is used by Zotero's odf-scan plugin (
http://zotero-odf-scan.github.io/zotero-odf-scan/); these are text
citations of this type:

{pre | -Author (Date) | p. XX | post | ZOTEROKEY }

The scanner will convert these to ODT citations, and multiple citations
strung together will be formatted as a multi-source citation.

I find these pretty easy to read, though there is certainly room for
improvement.

On Sat, Jan 31, 2015 at 1:26 PM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:

> Hi all,
>
> I wanted to continue the discussion that began in this thread about
> adding citation support to Org:
> http://thread.gmane.org/gmane.emacs.orgmode/94352/focus=94412
>
> Here are some thoughts I have after reviewing that discussion:
>
> 1) Lots of people seem to need/want better support for citations in Org
> documents.  Other projects (Pandoc among them) already have support for
> citations which is good enough that at least some people are using them
> to fill this perceived gap in Org's support.
>
> 2) There are at least several different backend reference database
> formats (BibTeX, Zotero, etc.) used by Orgsters.  Not all such databases
> use human-readable keys.  Org also has a nice internal format for
> storing reference information: org-bibtex.
>
> 3) There are also several different frontend solutions for making
> citations in Org documents (org-ref, various `home-brewed' solutions,
> raw LaTeX \cite commands, etc.).  The variety here is at least in part
> due to our different requirements for the format of exported documents:
> e.g., some people only care about exporting to LaTeX, others need
> something that will work for HTML or ODT; some people need to specify
> pre- and post-text for citations; some people need to specify citation
> types.
>
> 4) Because individual Orgsters have widely varying needs, there is some
> disagreement about what `proper' citation support should look like.  (Do
> we need new syntax, or can existing syntax be used?  Which features need
> to be supported by Org, and which can be provided by external tools?
> etc.)
>
> It seems there are three distinct but related problems:
>   - representing citations in Org documents
>   - exporting citations in an Org document to a backend document format
> like LaTeX, ODT, or HTML
>   - searching for and manipulating keys in a reference database from
> within Org, and otherwise fostering good communication between
> such a database and citations in Org documents
>
> Here's my personal opinion about how we might solve them.
>
> As for the first problem, I think a good case can be made for adding new
> syntax to Org to represent citations, instead of repurposing/extending
> existing syntax (most notably, the link syntax).
>
> Here's why.  Citations are complicated, and it's clear that some sort of
> new syntax is needed to represent them.  Even link-based solutions
> introduce new syntax `inside' the link syntax, such as using `::' to
> separate pre-text and post-text in a link description, as org-ref does.
> Thus, the issue is not *whether* there should be additional syntax, but
> just *how constrained* it should be.  In particular, the question is
> whether we want to make citation syntax a subset of link syntax, or
> whether citations and links should be distinct types of syntactic
> elements.
>
> It seems to me that the needs of citation users are wide enough and
> complicated enough that it is worth shedding the constraints imposed by
> the link syntax.  Eventually, packing all the representations we need
> for a general solution (citation type, pre- and post-text, suppressing
> author name, etc. etc.) into the link syntax will tend to make citations
> unreadable.
>
> Moreover, citations are not really links, even though it is often useful
> to treat them (or parts of them) as links.  F

[O] org-agenda-other-frame

[Tory S. Anderson]

I have a key which calls `gnus-other-frame`, a handy function that not only 
pops up a gnus frame, but also kills the frame when I exit gnus. I'd like 
something similar with my org agenda; the following function is used to pop it 
up, but I'm not sure how to kill the frame when I hit close the agenda (i.e. 
hitting `q`). The result should work whether I'm using sticky agenda or not. 
Any suggestions? 

--8<---cut here---start->8---
(defun go-or-make-agenda (&optional new-frame)
  (interactive "P")
  (let ((buffer org-agenda-buffer-name)
(my-switch-function (if new-frame 'switch-to-buffer-other-frame 
'switch-to-buffer)))
(if (get-buffer buffer)
(funcall my-switch-function buffer)
  (org-agenda-list
--8<---cut here---end--->8---

Re: [O] Citations, continued

[Rasmus]

t...@tsdye.com (Thomas S. Dye) writes:

> You and others are advocating a separate syntax for links and citations,
> which might indeed be the way to go.  I can see it being much nicer than
> the current state of affairs with Org mode links.  The downside is that
> it will mean learning another set of rules, in addition to the existing
> rules for links.

So we bump the version number?  The [[cite:key]] would not stop working.

> Several years ago, Samuel Wales suggested an extensible syntax example
> using link features
> (https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html).
> At the time it seemed to me that this was a Lisp-y approach because it
> solved particular problems by generalizing or abstracting a language
> feature to include particulars that had previously fallen outside its
> ken.  I wanted something like this while I was working on implementing
> citation links for export to LaTeX.
>
> Would it be feasible to generalize Org mode's link syntax, or make it
> extensible, so the overlap of link with citation is complete?  

I like :key entry-links and it would be powerful.  Certain like types
would also need to support custom display functions.  You could then
implement a cite-operator '@' as a handler for a generalized link.

—Rasmus

-- 
Governments should be afraid of their people

Re: [O] Citations, continued

[Rasmus]

John Kitchin  writes:

> See cite:Doe1999 for an overview; a more extensive discussion is in
> cite:Foobar2000

This is ok and supported by ox-bibtex.el.

> if the pre/post text is really critical somehow, you can do this.
>
> [[cite:Doe1999][See::for an overview]]; a more extensive discussion is in
> cite:Foobar2000

This is displayed as "See::for an overview" with an underline, which is
not really good enough.

> I guess this would also be ok in orgref:
> [[cite:Doe1999][See::for an overview]][[cite:Foobar2000][; a more extensive
> discussion is in]]

Which is displayed as 

See::for an overview; a more extensive discussion is in

Which is formidably unreadable!


> How does the pandoc syntax handle different link types.

We can make it more powerful as necessary.

> We never use pre/post text in citations in our work, and they don't even
> make sense with all citation formats, e.g. superscripted numbers. Maybe
> someone could provide some real life citation examples that links can't
> handle?

[[cite:key][prenote postnote]]

Per your examples above. 

> I suspect a lot of pre/post text issues can be solved manually as:
>
> (see cite:key1, pg33-4; also cite:key2, chapter 3)
> and you will get what you want in the output.

Note that \parencite[pre][post]{key} becomes (see author, year post).  I
don't know how to construct this in a simple way as (see author (year) post) 
is not good enough.

> In word, I suppose there are little fields in the main document, and you
> run some function that fires up zotero/endnote/mendeley, etc... that does
> the formatting.

I guess...

>>
>> The other problems, I think, must wait until a stable citation syntax
>> emerges -- export support in particular.  (Using an existing syntax from
>> another project could help ease the transition here: if people can
>> export citations using an existing tool, they'll be able to switch to
>> that syntax immediately, and use the external tool in the meantime while
>> Org-internal support for it catches up.)
>>
>> I hope this is a useful starting point for further discussion!
>>
>
> So, after working through all that, I still think links are good enough for
> a large portion of citations.

Not surprisingly I disagree.

It "breaks" whenever you have pre and post notes.  Author-Year is pretty
common and pre and post is pretty damn important.  Readability is
important and links fail at this step for any citation but the most simple
ones.

Links are "hard" to type outside of Emacs and logically/syntax-wise
unpleasant and are displayed poorly within Emacs.

—Rasmus

-- 
The second rule of Fight Club is: You do not talk about Fight Club

Re: [O] Citations, continued

[Rasmus]

Richard Lawrence  writes:

> Nicolas Goaziou  writes:
>
>> Richard Lawrence  writes:
>>
>>> ...so the first step for introducing citation syntax to Org should be
>>> compiling a list of all the things such a syntax should represent.
>>
>> See also 
>>
>>   
>
> Within a citation, each reference to an individual work needs to be
> capable of containing:
>   1) a database key that references the cited work
>   2) prefix / pre-text
>   3) suffix / post-text
>   4) references to page/chapter/section/whatever numbers and ranges.
>  This is likely part of the prefix or suffix, but might be worth
>  parsing separately for localization or link-following behavior.
>   5) a way of indicating backend-agnostic formatting properties.
>  Examples of some properties users might want to specify are:

>  - displaying only some fields (or suppressing some fields) from a
>reference record (e.g., journal, date, author)

Would this not be properties of the bibliography and not the citation?


> Citations as a whole also need:
>   6) [@6] a way of indicating formatting properties for specific export
>  backends.

I think the idea would be /not/ to have to consider specific backends.  If
you want special properties (say bold) for HTML could it not be solved by
a macro or a filter?  Probably I'm misunderstanding.

>  ...
>  - CSS or other styling class (HTML and derived backends; also
>ODT?)

The user solves this by writing CSS.  Of course citations would be wrapped
in a span or whatever.

>  - properties describing how to treat emphasis and other
>formatting that cannot appear in plain text (ASCII and other
>plain text backends)

IMO this is solved by ox-ascii.el already.

> In addition to the syntax of citations themselves, the Org document
> would also need to represent the following metadata to support
> citations:
>   7) [@7] a pointer to one or more backend reference databases,
>  including in-document databases in org-bibtex format

This would be a huge win.

>   8) a reference to a citation style or style file

How does this work outside of LaTeX?

>   9) a reference to a locale file

There's already a #+BIBLIOGRAPHY or #+REFERENCES in ox-bibtex.el.  But
it's quite limited.

>   10) an indication of where the bibliography should be found in the
>   exported document (equivalent to \printbibliography, etc. in
>   LaTeX)


> I would like to know if others can think of anything else that should go
> on this list.  I am particularly interested in hearing from people who
> use (or want to use) citations with non-LaTeX export backends, since I
> am least familiar with how citations work in those types of documents.

I would use citations in html and even odt.  Put it's a hard problem
'cause there's nothing quite like bib(la)tex (to the best of my
knowledge).

> I have also been working on a proposal for citation syntax that I think
> will meet these requirements, which I will post separately.

Cool!  Let me know if I can help.  

I have mainly worked on regexps for the syntax I proposed in another email.

—Rasmus

-- 
The second rule of Fight Club is: You do not talk about Fight Club

Re: [O] Citations, continued

[John Kitchin]

Thomas S. Dye writes:

> Aloha Richard,
>
> Richard Lawrence  writes:
>
>> My point is not that the link syntax *can't* do enough.  Rather, my
>> point is that citations are conceptually distinct from links, and if we
>> are going to adopt an official syntax for them, that syntax should
>> reflect this conceptual distinction.  This is better for document
>> authors, because it is less work for us.  It gives us the right tool for
>> this particular job, instead of re-purposing a tool that, despite its
>> power, is designed for a different job.  It is thus better for the Org
>> community as a whole.
>
> I agree that citations are conceptually distinct from links, but at the
> same time they share many features.  Both can refer to something outside
> the Org mode document.  Both can be replaced in the Org mode export with
> something from outside the Org mode document.  The fact that links can
> be made to handle most users' citation needs is practical proof that the
> similarities are more than superficial.
>
> Now, I agree with you that Org mode links are not ideal for citations.
> Parsing the description is humbug and error-prone, and the descriptions
> look ungainly in the Org mode document.  I never remember to click
> citation links in the "right" place!  There is much room for improvement
> here.

I am not sure how much better it could get. What did you have in mind? I
could imagine for a cite link with several citations the click action
could give you an ido-completing/helm selection buffer and you choose
what you want to do from there. In org-ref the click action is user
definable, so you can get what you want.

>
> You and others are advocating a separate syntax for links and citations,
> which might indeed be the way to go.  I can see it being much nicer than
> the current state of affairs with Org mode links.  The downside is that
> it will mean learning another set of rules, in addition to the existing
> rules for links.
>
> Several years ago, Samuel Wales suggested an extensible syntax example
> using link features
> (https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html).
> At the time it seemed to me that this was a Lisp-y approach because it
> solved particular problems by generalizing or abstracting a language
> feature to include particulars that had previously fallen outside its
> ken.  I wanted something like this while I was working on implementing
> citation links for export to LaTeX.
>

I am totally for this idea! I have been pondering how to make a link
element with extra data in it for a while.


> Would it be feasible to generalize Org mode's link syntax, or make it
> extensible, so the overlap of link with citation is complete?
>
> All the best,
> Tom

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Include another org-document without settings

[Stefan Nobis]

Nicolas Goaziou  writes:

> You can skip the first lines of an INCLUDEd file with :line parameter.
> You can also only include a section.  See manual for details.

Thank you for the hint. I used something like

   #+INCLUDE "a.org" :lines 3-

but still got duplicate keywords (the KEYWORDS option is in line 2 of
my example).

It seems, I got the syntax wrong. The correct version is

   #+INCLUDE: a.org :lines "3-"

so the quotations marks around the parameter are mandatory and not
optional. Using the correct syntax everything works as expected.

--
Until the next mail...,
Stefan.

Re: [O] Citations, continued

[Rasmus]

Richard Lawrence  writes:

> 2) There are at least several different backend reference database
> formats (BibTeX, Zotero, etc.) used by Orgsters.  Not all such databases
> use human-readable keys.  Org also has a nice internal format for
> storing reference information: org-bibtex.

Human readable keys are not a deal-breaker IMO.  Important is bibtex and
an entity-like display (e.g. Org displays \alpha as α etc.).

> 4) Because individual Orgsters have widely varying needs, there is some
> disagreement about what `proper' citation support should look like.  (Do
> we need new syntax, or can existing syntax be used?  Which features need
> to be supported by Org, and which can be provided by external tools?
> etc.)
>
> It seems there are three distinct but related problems:

>   1. representing citations in Org documents

>   2. exporting citations in an Org document to a backend document format
>  like LaTeX, ODT, or HTML

>   3. searching for and manipulating keys in a reference database from
>  within Org, and otherwise fostering good communication between
>  such a database and citations in Org documents

I would add:

4a. Support backends  ...
4b. ... and represent them internally.

5. Formatting of citations.

6. Nice representation in org-mode similar to entities.

As John K said, it is much preferable to have external tools handle 5.  If
there exist an external tool that can format handle formatting based on a
given backend, problem 2. and 5. disappear more or less.

If 5. is solved in elisp (e.g. using bibtex.el), problem 2. is "easy"
across all backends, but results might only be easily clickable/dynamic in
html.

1  → is an org-element.el problem.
3  → is easy for bibtex at least via Reftex.  My understanding is that
 Zotero also has well-supported selection functionality.
4b → allows for easy sharing of complete documents.

> I think a good case can be made for adding new syntax to Org to
> represent citations, instead of repurposing/extending existing syntax
> (most notably, the link syntax).

+1.

> For these reasons, I would support a separate citation syntax, but one
> that can behave like a link when useful.  For example, suppose we
> borrowed the Pandoc [ ... @key1 ...; ... @key2 ...] syntax.  When point
> is on `@key1', C-c C-o could be bound to find the key in the reference
> database, or another useful action, depending on the reference database
> format.

I think we should use "almost-pandoc" cf.

  http://permalink.gmane.org/gmane.emacs.orgmode/94412

Namely [@bibtex-key :key value] with handy shortcuts.
E.g. for latex constructs

  @key   → \textcite{key}
  (@key) → \parencite{key}
  [@key :key value]  → ?
  [@key :type mytype]→ \mytype{key}
  [-@key]→ \nocite{key}
  (pre @key post)→ \parencite[pre][post]{key}
  (pre @key post :key value) → ? 
  
Something like (pre1 @key1 post1 pre1 @key2 post2) is hard to represent
though ('cause it disallows).  Perhaps (pre1 @key1 post1) (pre2 @key2
post2) could be merged like how subscripts are collected?

> As I mentioned in the earlier thread, I think the Pandoc syntax is a
> good place to start, and I think it would be valuable to have the two
> syntaxes be compatible.  But even Pandoc's citation syntax might not be
> general enough to satisfy everyone's needs, so the first step for
> introducing citation syntax to Org should be compiling a list of all the
> things such a syntax should represent.

I think allowing for arbitrary keys is abstract enough to solve all
issues.  It would also be easy to add user-written support.

> The other problems, I think, must wait until a stable citation syntax
> emerges -- export support in particular.

+1.

—Rasmus

-- 
It was you, Jezebel, it was you

Re: [O] save folded state

[Phillip Lord]

Worth trying the buffer-invisibility-spec solution. I'd be interested to
know if it works or not. Although I wonder whether the commands that you
are using really should be obeying visibility context.

Phil

John Kitchin  writes:
> yes, I meant programatically. I was having some issue in selecting
> contex using commands that grab what is visible. So for things inside a
> folded section it was not grabbing the right context.
>
> I solved it by doing something similar to what you describe, i.e. a
> tempbuffer.
>
> lentic looks pretty interesting.
>
> Phillip Lord writes:
>
>> You mean programmatically? Is folding not just implemented with
>> invisible overlays? If so, why do you need to change this to get
>> context?
>>
>> You can try setting buffer-invisibility-spec temporarily. For example,
>> run this function in a folded org-mode buffer.
>>
>> (defun temp ()
>>   (interactive)
>>   (message "invisibility spec stuff")
>>   (let ((buffer-invisibility-spec '()))
>> (message "sitting")
>> (sit-for 5))
>>   (message "done"))
>>
>> It unfolds everything but having the display engine ignore all
>> overlays/text properties.
>>
>> If you want to do this interactively, and you will forgive the plug, my
>> own package, lentic, would enable you to do this. You can open up a
>> second buffer which has the same text as the first, but could be folded
>> completely independently of the original. At the moment, you only get
>> one copy, but I'll expand that to any number at some point. When you're
>> finished kill the copy, and all the changed folding goes with it.
>>
>> Phil
>>
>>
>> John Kitchin  writes:
>>
>>> I am trying to map over a buffer with headlines in various states of
>>> folded, and get context around certain elements. I find I need to fully
>>> expand the buffer to get the context in the way I am currently doing it
>>> (e.g. getting the lines around the element), but I would like to put the
>>> buffer back to the way it was when I am finished. This is not done with
>>> the usual macros like save-excursion, save-restriction, etc... Is there
>>> a way to do this other than a temp buffer?
>>>
>>> thanks,
>>>
>>> --
>>> Professor John Kitchin
>>> Doherty Hall A207F
>>> Department of Chemical Engineering
>>> Carnegie Mellon University
>>> Pittsburgh, PA 15213
>>> 412-268-7803
>>> @johnkitchin
>>> http://kitchingroup.cheme.cmu.edu
>
> --
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

Re: [O] org-expiry not compatible with the new drawer syntax

[Samuel Loury]

Nicolas Goaziou  writes:

> Samuel Loury  writes:
>
>> Please find attached the merged patch, as asked for.
>
> Applied, thank you.
>
>> Therefore, the hooks associated to the insertion of a heading will be
>> triggered. Since those hooks may cause the creation of some
>> metadata. `org-end-of-meta-data' is used afterward.
>
> Note that two spaces are required after full stop in commit messages.
Noted, Thank you :-).

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature

Re: [O] http://orgmode.org/worg/code/org-info-js/ broken

[Marco Wahl]

Hello!

>> Svjatoslav Agejenko  writes:
>> 
>> > Button "Show Org source" on page
>> > http://orgmode.org/worg/code/org-info-js/ 
>> > does not work.
>> 
>> You could try the explicit
>> http://orgmode.org/worg/code/org-info-js/index.html instead.  The
>> button's action depends on the concrete form of the URL in particular
>> the substring "html".
>
> That last link with explicit index.html seems to work. Still when
> searching Google for org-mode related things it directed me there:
> http://orgmode.org/worg/code/org-info-js/
>
> And this URL looks valid by itself. No hints anywhere that I shall use
> index.html suffix.

BTW also many other pages on worg have this button also
e.g. http://orgmode.org/worg/.  The relevant code in those pages is

#v+

function rpl(expr,a,b) {
  var i=0
  while (i!=-1) {
 i=expr.indexOf(a,i);
 if (i>=0) {
expr=expr.substring(0,i)+b+expr.substring(i+a.length);
i+=b.length;
 }
  }
  return expr
}

function show_org_source(){
   document.location.href = rpl(document.location.href,"html","org.html");
}

#v-

and it looks like a template.  A reasonable fix to make the button work
for URLs without suffix 'index.html' might be to change this code
accordingly.

Unfortunately my finding-fu was not enough to find the source of that
code.

> I hope whoever is responsible will fix this.

It's the community AFAICS.  Let's hope she will do something.


Best regards,  Marco
-- 
http://www.wahlzone.de
GPG: 0x49010A040A3AE6F2

Re: [O] org-expiry not compatible with the new drawer syntax

[Nicolas Goaziou]

Samuel Loury  writes:

> Please find attached the merged patch, as asked for.

Applied, thank you.

> Therefore, the hooks associated to the insertion of a heading will be
> triggered. Since those hooks may cause the creation of some
> metadata. `org-end-of-meta-data' is used afterward.

Note that two spaces are required after full stop in commit messages.


Regards,

Re: [O] Include another org-document without settings

[Nicolas Goaziou]

Hello,

Stefan Nobis  writes:

> Maybe it would be a helful extension to give #+INCLUDE an option to
> just ignore global settings?

You can skip the first lines of an INCLUDEd file with :line parameter.
You can also only include a section.  See manual for details.


Regards,

-- 
Nicolas Goaziou

Re: [O] Babel support for Processing-language

[Jarmo Hurri]

Jarmo Hurri  writes:

> Yep, I am going to start doing this if no-one is working on it yet.
>
> I woke up in the middle of the night to realize how amazingly easily
> this can be done if I drop out the support for PDF export, that is,
> only leave the option to export as HTML. There is no need to even
> execute the code at export time to draw the image or the animation,
> because in HTML you can just wrap the original Processing code in a
> canvas element and the Processing.js code will draw it in the browser.
>
> http://en.wikipedia.org/wiki/Processing.js
>
> Let me repeat: by just exporting the code suitably embedded in the HTML
> document, the _browser_ will draw the image or the animation. I just
> tested it and it works perfectly.
>
> So I will implement this in Org/Babel so that
> - executing Processing code will result in the image / animation being
>   shown in an external window via processing-java
> - exporting the results of Processing code is only sensible in HTML
>   export, which will produce a web page with the code embedded as
>   described above; the browser does the drawing.
>
> These operations will require the availability of processing-java and
> processing.js in the system where the code is executed/exported.

I posted the quoted message a while back, indicating that I would start
working on Processing support in org mode. I now have the time to start
implementing it. I will take one of the other language support files as
a basis.

If anybody has anything they'd like to add to my idea at this time, feel
free to do so. I will be working on this on and off, but this should be
done by the end of the spring. I will need Processing support in the
autumn in a project.

All the best,

Jarmo