Re: [O] [patch] ox-latex.el: support for pgf files

2013-05-21 Thread Nicolas Goaziou
Hello,

Rasmus ras...@gmx.us writes:

 This patch adds support for pgf files.  pgf is the machine upon which
 tikz is build.  For instance matplotlib (of Python) and printpgf (of
 Octave) both produces pgf files.  It's just a question of recognizing
 the extension.  With this patch the following document exports
 correctly:

 #+TITLE: PGF test
 #+LATEX_HEADER: \usepackage{pgf}
 #+BEGIN_SRC emacs-lisp :exports none
   (set (make-local-variable 'org-latex-pdf-process)
'(xelatex -pdf %f))
 #+END_SRC
 #+BEGIN_SRC python :results raw :exports results
   from matplotlib import pylab as plt
   x, y = plt.rand(2)
   plt.scatter(x, y)
   fig = test.pgf
   plt.savefig(fig) ## utf8 by default
   return(.join([[[file:, fig, ]]]))
 #+END_SRC

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] patch for htmlize.el

2013-05-21 Thread Carsten Dominik
Yes, that is all right at least for now, please go ahead.

Thanks!

- Carsten

On 21 mei 2013, at 02:16, Eric Schulte schulte.e...@gmail.com wrote:

 Hi,
 
 I'd like to commit the following patch which improves htmlize's handling
 of svg image overlays.  I couldn't find an upstream for htmlize, is it
 appropriate to patch htmlize in the Org-mode source tree?
 
 Thanks,
 
 From 4611b177def45bf23c2cfb1caf0b12baa5e0e91b Mon Sep 17 00:00:00 2001
 From: Eric Schulte schulte.e...@gmail.com
 Date: Mon, 20 May 2013 18:15:05 -0600
 Subject: [PATCH] export inline svg images with htmlize
 
 ---
 contrib/lisp/htmlize.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)
 
 diff --git a/contrib/lisp/htmlize.el b/contrib/lisp/htmlize.el
 index c03d605..3bf5949 100644
 --- a/contrib/lisp/htmlize.el
 +++ b/contrib/lisp/htmlize.el
 @@ -601,10 +601,12 @@ list.
  (htmlize-attr-escape (file-relative-name file))
  alt-attr)))
   ((plist-get imgprops :data)
 -   (format img src=\data:image/%s;base64,%s\%s /
 -   (or (plist-get imgprops :type) )
 -   (base64-encode-string (plist-get imgprops :data))
 -   alt-attr)
 +(if (equalp (plist-get imgprops :type) 'svg)
 +(plist-get imgprops :data)
 +  (format img src=\data:image/%s;base64,%s\%s /
 +  (or (plist-get imgprops :type) )
 +  (base64-encode-string (plist-get imgprops :data))
 +  alt-attr))
 
 (defconst htmlize-ellipsis ...)
 (put-text-property 0 (length htmlize-ellipsis) 'htmlize-ellipsis t 
 htmlize-ellipsis)
 -- 
 1.8.2.3
 
 
 -- 
 Eric Schulte
 http://cs.unm.edu/~eschulte




Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

2013-05-21 Thread Alan Schmitt
Rasmus writes:

 I found a bug in that the subject variable should be a list cf. the
 KOMA manual.  This patch fixes this.

 It's pretty complex for something so simple, and I might be inclined
 to admit to the put it in a LCO-file approach might be better.

I'd really like to have a second opinion on this. Viktor?

Best,

Alan



Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

2013-05-21 Thread Sebastien Vauban
Hi John,

John Hendy wrote:
 On Mon, May 20, 2013 at 5:15 PM, John Hendy jw.he...@gmail.com wrote:
 Sorry for the long title, but that's the summary! I fired up a fresh
 Emacs session and used =C-a s search-term RET= to navigate to a
 headline in the results by putting the cursor on the line and pressing
 RET.

 The file text was all black.

 If I visited the file directly, I had the typical color-coded text for
 headlines/keywords. I decided to replicate with a minimal config, and
 I was able to. Here's the context of the min config:

 #+begin_min-config
 ;; set load paths
 ;; set load dirs and global config options
 (add-to-list 'load-path ~/.elisp/org.git/lisp/)
 (add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
 #+end_min-config

 This was on a work file, and I couldn't initially replicate with a
 test file... but it appears it has to do with my header options.
 Here's the test file:

 #+begin_src org
 #+setupfile: ~/org/aux/setupfile.org
 #+options: :t num:t author:t creator:nil tags:t toc:nil date:t
 #+latex_header: \usepackage{lscape}
 #+latex_header: \usepackage{amsmath}

 * Test headline

 Some paragraph just to give me a keyword to search for

 ** Sub headline

 Some more text in the next headline
 #+end_src

 My process:
 - emacs -Q
 - M-x load-file RET ~/path/to/min-config RET
 - C-x C-f /path/to/file.org RET
 - C-c [ to add to agenda list
 - C-x C-k RET to kill buffer
 - M-x org-agenda RET s RET text RET
 - Navigate to test.org matching line RET
 - File looks like attached pic

 I deleted everything but my #+setupfile line and it still does that.

 Last bit of input -- when this behavior is displayed, if I C-c C-c on
 my options block at the top of the file, it returns to fontified
 behavior and stays that way (even if meddling with headlines). It
 appears that navigating to a headline with various #+keyword lines is
 not letting Org recognize something. Refreshing the setup seems to
 handles this. This is on:

 Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @
 /home/jwhendy/.elisp/org.git/lisp/)

 Happy to try anything else or provide more info. For now, I think I've
 made enough noise about this!

 Without any #+ options at the top of the file, it appears in color.

End of last week, after updating Org, I also got lots of fontification
troubles inside Org buffers, but as well in more places (Gnus, in particular).

I restarted Emacs many, many times, used Org in different contexts, and
problems did always appear after some time (a couple of minutes, generally).

I did check out an older version of Org, and all the highlighting problems are
gone.

Currently used version: Org-mode version 8.0.3 (release_8.0.3-114-gab3f45 @
~/Public/Repositories/org-mode/lisp/).

I did not have time yet to bisect the problem, but it _seems_ to be a newly
introduced feature.

Maybe you can try to check out older versions ( 10 days ago), and see whether
you can replicate your problem?

Best regards,
Seb

-- 
Sebastien Vauban




Re: [O] TOC in HTML export - how to change formatting of ToDo levels?

2013-05-21 Thread Sebastien Vauban
Hi David,

David Rogoff wrote:
 I've just started diving back into org-mode. I'm mostly using it for ToDo /
 Status tracking. I've been trying to change the format of the TOC entries with
 little success. I've figured out how to use org-export-html-style to change
 the CSS markup for my customized ToDo levels, but that just affects the
 formatting in the body of the document. The table of contents appears to
 ignore that. I've been digging through org-html.el and the TOC formatting
 (around line 1474) looks to be mostly card-coded with almost no variables to
 control anything. Any ToDo status of done is not marked up at all and anything
 else is just marked as class todo instead of the actual class of the item.

 Am I missing something? The only solution I've found is to write a script to
 fix the HTML after exporting. Any better solution? It's a very big ToDo list
 and I (and others who will look at the document) want to see the actual status
 (preferably with the CSS font/text markups) in the TOC to know which items to
 look into for further details.

You should be able to customize the todo class only within the TOC context
with such a rule:

--8---cut here---start-8---
#table-of-contents .todo {
...
}
--8---cut here---end---8---

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Customizing Org 8.0 Export

2013-05-21 Thread Sebastien Vauban
Hi Scott,

Scott Randby wrote:
 2. I want to put the following in my init.el:

  (add-to-list 'org-latex-classes
  '(notesclass
\\documentclass{article}
(\\section{%s} . \\newsection{%s})
(\\subsection{%s} . \\newsubsection{%s})))

 But when I do, I get the following on startup:

   Warning (initialization): An error occurred while loading
   `/home/srandby/.emacs.d/init.el':

   Symbol's value as variable is void: org-latex-classes

   To ensure normal operation, you should investigate and remove
   the cause of the error in your initialization file.  Start
   Emacs with the `--debug-init' option to view a complete error
   backtrace.

 This means I cannot put the above code in my init.el file where I
 want it to be.

For such cases, I do write:

#+begin_src emacs-lisp
  ;; LaTeX back-end
  (eval-after-load ox-latex
'(progn

  ;; your code...

)) ;; eval-after-load ox-latex ends here
#+end_src

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Best way to make/add tech diagrams/graphics?

2013-05-21 Thread Christopher Witte
Asymptote http://asymptote.sourceforge.net/ would also be another option in
a similar vein to TikZ.


On 18 May 2013 01:14, John Hendy jw.he...@gmail.com wrote:

 On Fri, May 17, 2013 at 6:09 PM, Marcin Borkowski mb...@wmi.amu.edu.pl
 wrote:
  Dnia 2013-05-17, o godz. 11:40:17
  John Hendy jw.he...@gmail.com napisał(a):
 
  On Fri, May 17, 2013 at 10:13 AM, Lawrence Bottorff
  borg...@gmail.com wrote:
   I'd like to embed images into my running org file -- for eventual
   conversion to Latex or html. These would be simple diagram-style
   pictures such as math or technical diagrams that cannot be done
   with gnuplot or other formula-to-picture conversion software.
  
   Examples:
  
 http://www.library.utoronto.ca/see/SEED/Vol5-1/Queiroz_Emmeche_El-Hani_files/image003.gif
  
 http://math.ucr.edu/home/baez/irvine/SBGN_process_description_cropped.jpg
  
 
  A few that come to mind for this sort of thing:
  - ditaa: http://ditaa.sourceforge.net/
  - graphviz/dot: http://www.graphviz.org/
  - my personal favorite, but quite the learning curve, it PFG/TikZ:
  http://www.texample.net/tikz/examples/
 
  Typo: it's PGF, not PFG, just in case you wanted to google it or
  something;).
 

 Oops -- typo on my part.

  I'd also mention Metapost, on which I believe TikZ was modeled (at least
  to some extent).
 
  Since you mentioned embedding in LaTeX, I'd also suggest TikZ; it has a
  huge manual, but /very/ well written, with quite a few tutorials and
  examples. One benefit is that it is tightly integrated into LaTeX,
  but it can also export SVG (though with a few limitations compared to
  the pdfLaTeX-produced output).  Also, you might want to check out the
  gallery of TikZ examples here: http://www.texample.net/tikz/ .
 

 The examples are great. The link I provided goes right to the examples
 vs. that sort of home page screen which only shows the most recent
 couple that have been submitted.

 I'll have to check out metapost, as I'd not heard of that one.


 Thanks,
 John

  Good luck!
  John
 
  Best,
 
  --
  Marcin Borkowski
  http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
  Adam Mickiewicz University
 




Re: [O] Indentation of code blocks within lists

2013-05-21 Thread Francesco Pizzolante
Hi,

May I bump up this thread?

Thanks,
 Francesco

Francesco Pizzolante wrote:
 Hi All,

 I'd like to let you know about issues I'm having while trying to put source
 code blocks within lists.

 Here's my example and how I indent it:

 * First situation

 - My first bullet

   We need to do this:

   #+begin_src emacs-lisp
   (message this is a string)
   (defun x()
 Doc...
 (interactive)
 (message hello))
   #+end_src

 - My second bullet

   #+begin_src emacs-lisp
   test
   #+end_src

   #+results:
   : test

   - Sub-point of second bullet

 We need to do this as well:

 #+begin_src emacs-lisp
 (sort)
 #+end_src

 This way if indenting code blocks has the following advantages:

 - it looks nice;

 - thanks to the indentation, you directly know at which list level the code
   block belongs to;

 - you can easily use Emacs commands (like `C-x TAB') on regions or Org
   promote/demote commands on items or subtrees to edit and reorganize your
   text: relative indentation is preserved in all cases.

 But, I have 2 issues with it:

 - when using `C-c '' (`org-edit-special'), I see spaces before my code, while
   I would expect to see my code starting at column 0 in the edit buffer (the
   reference column for the margin being, here, the column with the '#'
   from '#+begin_src';

 - when exporting, the spaces from column 0 to the start of my code are also
   exported, while I would again expect these spaces to be ignored for the
   export.

 The only way I found to fix these issues is to edit my text like this (and
 make any code to start in column 0):

 - My first bullet

   We need to do this:

   #+begin_src emacs-lisp
 (message this is a string)
 (defun x()
   Doc...
   (interactive)
   (message hello))
   #+end_src

 - My second bullet

   #+begin_src emacs-lisp
 test
   #+end_src

   #+results:
   : test

   - Sub-point of second bullet

 We need to do this as well:

 #+begin_src emacs-lisp
 (sort)
 #+end_src

 But:

 - as you can see, the text does not look anymore as nice as in the previous
   example;

 - I'm no longer able to edit and reorganize the text using Emacs `C-x TAB'
   command. That command becomes forbidden as it can't correctly respect the
   indentation requirements:

   + starting at column 0 for code;

   + relative for list items (depending on their depth);

 - even Org promote/demote commands are buggy in this case: as a simple
   example, when I try to promote (with M-Shift-Left) the last point Sub-point
   of second bullet I get an error (indent-line-to: Wrong type argument:
   wholenump, -2 ) and the following half-baked result:

   - Sub-point of second bullet

 We need to do this:

 #+begin_src emacs-lisp
 (sort)
   #+end_src

   The #+end_src line got misaligned.

 So, my question is the following: is there a way to edit my text as shown in
 the first example and edit/export it ignoring the margin spaces?

 Any help is welcome.

 Thanks a lot,
  Francesco



Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Rasmus
Alan Schmitt alan.schm...@polytechnique.org writes:

 It seems there are some semantic bugs in ox-koma-letter.el in that new
 variables are introduces for SENDER (as opposed to AUTHOR) and a
 separate email variable as well.  This seems like a semantic bug IMO.
 This patch fixes these issues if they in fact are issues.

 Can we still use an lco file to set these after this change?

(I'll also post this on the list).

You can't set
  
  #+SENDER: 

Which seems to be how it was set up before.  You can use 

  #+AUTHOR

So if you decide to convert your document from something you'd export
with the normal LaTeX exporter it would be smoother this way.  Author
now works the same way that it does in the LaTeX exporter (come to
think of it, we probably shouldn't need to mention anything as it
build on top of the LaTeX exporter anyway). 

Thus, unless you disable export of author it wouldn't work with a LCO
file.  But then we could make export of author conditional on
:with-author as in ox-latex.el and you could use LCO files.

The gain is that in the (for me) 99.9% of the cases where I want to
send a letter in my own name the exporter just figures it out without
be having to specify anything (like in the normal exporter).

–Rasmus


-- 
In theory, practice and theory are the same. In practice they are not



Re: [O] patch for htmlize.el

2013-05-21 Thread Bastien
Hi Eric,

Carsten Dominik carsten.domi...@gmail.com writes:

 Yes, that is all right at least for now, please go ahead.

Please also send an email to htmlize.el's author -- I think he's
reading the mailing list, but ensuring he does would be nice.

Best,

-- 
 Bastien



Re: [O] GFDL

2013-05-21 Thread Bastien
Hi Ben,

Ben Finney ben+em...@benfinney.id.au writes:

 It bothers me mostly for the guide, where I did spend a lot of time to
 make it compact, and now something like one fifth of it is license
 text.  We may actually consider to re-release the guide under a
 different license.

 Please use this as an opportunity to seriously consider relicensing the
 entire work (programs, documentation, etc.) of Org-mode under the same
 license: the GNU GPL. It does not have the special problems of the FDL,
 and having the whole work under the same license terms makes it simpler
 and clearer.

Well, relicensing the Org compact guide under GNU GPL is definitely
feasible, but relicensing the Org manual is (sadly) not.  Let's take
the feasible step first?

-- 
 Bastien



Re: [O] Effort entry and confusing effort estimates

2013-05-21 Thread Bastien
Hi Ken,

Ken Mankoff mank...@gmail.com writes:

 But I'm still confused what 'org-set-effort' expects/interprets
 compared to 'org-clock-modify-effort-estimate'. Any clarification
 will be much appreciated.

`org-set-effort' allows you to _set_ the effort value.

`org-clock-modify-effort-estimate' allows you to either set the effort
value (e.g. if you enter 1:30, the old value will be replaced by this
one) or to increment/decrement the effort value by using +mm or
+n[hdwmy] -- e.g. entering +1d will increment the current value by 1
day.  1 day is interpreted depending on `org-effort-durations',
which see.

Hope this clarifies,

-- 
 Bastien



Re: [O] ical2org.py

2013-05-21 Thread Eric S Fraga
aitor aitors2...@gmail.org writes:

 Hi,

 I've implemented a little script which converts ics files to
 org-mode. You can find the script here:

 https://github.com/asoroa/ical2org.py

Aitor,

I would like to try this out but, as I am not a python user, I have no
idea how to get the two bits you indicate being necessary (icalendar,
pytz) installed.  I have installed python-dateutil and python-pycalendar
as these looked the most obvious candidates for icalendar but no
luck.  Searching the repositories for pytz draws a blank as well.

,
| $ ~/git/ical2org.py/ical2org.py 
| Traceback (most recent call last):
|   File /home/ucecesf/git/ical2org.py/ical2org.py, line 5, in module
| from icalendar import Calendar
| ImportError: No module named icalendar
| $ 
`

I am using Ubuntu.

Anyway help would be most welcome.

thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.2-94-g5a1400




Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Alan Schmitt
Rasmus writes:

 Alan Schmitt alan.schm...@polytechnique.org writes:

 It seems there are some semantic bugs in ox-koma-letter.el in that new
 variables are introduces for SENDER (as opposed to AUTHOR) and a
 separate email variable as well.  This seems like a semantic bug IMO.
 This patch fixes these issues if they in fact are issues.

 Can we still use an lco file to set these after this change?

 (I'll also post this on the list).

 You can't set
   
   #+SENDER: 

 Which seems to be how it was set up before.  You can use 

   #+AUTHOR

 So if you decide to convert your document from something you'd export
 with the normal LaTeX exporter it would be smoother this way.  Author
 now works the same way that it does in the LaTeX exporter (come to
 think of it, we probably shouldn't need to mention anything as it
 build on top of the LaTeX exporter anyway). 

 Thus, unless you disable export of author it wouldn't work with a LCO
 file.  But then we could make export of author conditional on
 :with-author as in ox-latex.el and you could use LCO files.

 The gain is that in the (for me) 99.9% of the cases where I want to
 send a letter in my own name the exporter just figures it out without
 be having to specify anything (like in the normal exporter).

OK, sounds good, I've applied it.

Thanks,

Alan



Re: [O] Effort entry and confusing effort estimates

2013-05-21 Thread Lawrence Mitchell
Bastien wrote:
 Hi Ken,

 Ken Mankoff mank...@gmail.com writes:

 But I'm still confused what 'org-set-effort' expects/interprets
 compared to 'org-clock-modify-effort-estimate'. Any clarification
 will be much appreciated.

 `org-set-effort' allows you to _set_ the effort value.

 `org-clock-modify-effort-estimate' allows you to either set the effort
 value (e.g. if you enter 1:30, the old value will be replaced by this
 one) or to increment/decrement the effort value by using +mm or
 +n[hdwmy] -- e.g. entering +1d will increment the current value by 1
 day.  1 day is interpreted depending on `org-effort-durations',
 which see.

I think the problem is slightly more complicated.

org-set-effort does:

read some effort duration

(org-entry-put nil Effort duration-we-just-read)

org-clock-modify-effort-estimate does:

read some effort duration
(org-duration-string-to-minutes value)
convert this duration in minutes back to a string
(org-minutes-to-clocksum-string minutes-corresponding-to-value)
(org-entry-put nil Effort duration-we-just-calculated)

So org-set-effort doesn't do any conversion of the effort string
we enter.

org-clock-modify-effort-estimate does do conversion.  However, it
does it badly.

org-duration-string-to-minutes always uses org-effort-durations
to convert the input string to minutes.  However,
org-minutes-to-clocksum-string /only/ uses org-effort-durations
if org-time-clocksum-use-effort-durations is non-nil (not the
default).

The problem boils down to:

(let ((org-time-clocksum-use-effort-durations nil))
  (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered
 (org-duration-string-to-minutes  ;; what gets inserted
   (org-minutes-to-clocksum-string
 (org-duration-string-to-minutes 3d 2h)

= nil

(let ((org-time-clocksum-use-effort-durations t))
  (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered
 (org-duration-string-to-minutes  ;; what gets inserted
   (org-minutes-to-clocksum-string
 (org-duration-string-to-minutes 3d 2h)

= t

I would argue that

(org-duration-string-to-minutes
  (org-minutes-to-clocksum-string
(org-duration-string-to-minutes some-value)))

Should be a no-op.  But that is only the case if
org-time-clocksum-use-effort-durations is t.


Lawrence

-- 
Lawrence Mitchell we...@gmx.li




Re: [O] ical2org.py

2013-05-21 Thread François Pinard
Eric S Fraga e.fr...@ucl.ac.uk writes:

 I am not a python user [...]

Hi, Eric.  Nobody is perfect :-).  Regards, François



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread François Pinard
Max Mikhanosha m...@openchat.com writes:

 At Mon, 20 May 2013 13:45:48 -0500, Russell Adams wrote:
 What advantages would org-screenshot provide by comparison?

 To me the most useful feature is actually screenshot rotation
 shortcuts,

I also have my own screenshot tool (this was my first own addition to
Org mode, soon after I started to use it, quite a while ago now!) which
is intermediate in features between Russell's and Max's.

One thing I like in Max's approach is this capability of doing a Dired
display, in which one segregates between used screenshots and orphan
ones.  When a document has many screenshots, such diagnostic help eases
eliminating the dead wood and staying clean overall.

François



Re: [O] odt import

2013-05-21 Thread Detlef Steuer
On Sun, 19 May 2013 19:27:49 +0200
Uwe Brauer o...@mat.ucm.es wrote:

  Ethan == Ethan Ligon li...@are.berkeley.edu writes:
 
 Uwe Brauer oub at mat.ucm.es writes:
 
 Uwe Brauer 
 
 
 
 Presumably a reference to
 
 https://bitbucket.org/josemaria.alkala/odt2org/wiki/Home
 
 I haven't used it, and it's rather old (predates org-elements, I think). 
  
 
 Thanks but there are now files for downloading so I presume this project
 is dead.
 

Don't know anything about it but there is something to try:
https://bitbucket.org/josemaria.alkala/odt2org/src

Detlef
 





[O] Let's discuss citation and Org syntax

2013-05-21 Thread Rasmus
Hi, 

Now that 8.0 has shipped let's talk bibliography support.  This
follows directly upon the discussion around March[1].

The essence of the thread was that some people agreed that it would be
nice to have support for citation commands build into Org (I'll
summarize in the next post).  But let me first restate my own take on
the issue.  IMO a nice format would be:

(*)   [KEYWORD PROPERTIES]

I think we should allow for a more general approach than one just for
citation and this is a good thing (IMO).

The in-buffer display of (*) could be governed by
org-buffer-format-KEYWORD (similar to
gnus-user-format-function-LETTER) or just identity if no function is
defined.  Export could be handled by org-BACKEND-KEYWORD or
org-export-KEYWORD.  With officially recognized KEYWORDs something
like citation could be a 'first-class citizen'.  PROPERTIES could be a
string like:

  optional-keyless-entry :prop1 one :prop2 two ... 

Perhaps, treatment of keyword, could even be handled by an
in-buffer Org Babel function in the spirit of e.g. reproducible
research (see below).

This would be different from Org links in that (*) is more like a
functions that allows for (i) pretty and informative display in
buffer/export and (ii) easy user extension.

I think there are many compelling use-cases for such a framework.

1. Citation: Take the keyword citetext which should be an 'official'
   KEYWORD.  So for instance we could have

 [citetext BIBTEX-KEY :prenote note, w/comma :postnote blah].

   In buffers, via org-in-buffer-format-citetext, it would be
   displayed as
   
 BIBTEX-KEY (note, w/comma, YEAR, blah)
   
   or something similar (depending to what extend bibtex.el would be
   leveraged; e.g. BIBTEX-KEY might show the author/editor key and
   YEAR would also depend on parsing a bibtex file) (obviouesly,
   there's some reference to a bibtex file somewhere).  In LaTeX it
   would be exported as
   
 \citetext[note,w/comma][blah]{BIBTEX-KEY}
   
   In html it might utilize some tool that understand bibtex (there's
   a link to such a tool in the next post).  In ASCII it could almost
   use what would be displayed in the buffer.

2. MY-FUN: MY-FUN is some function that does something with some
   properties, perhaps just a string (simple cases: [sc text] is used
   for small caps, or mayhaps [my-treat-dna-string DNA-STRING]).  I
   might use it in a single file that I want to send to people or I
   might just use it in my notes.  Currently it's implemented via
   org-emphasis-alist or as a link.  Changing emphases is a hacks, and
   they are hard to export with the now more robust Org syntax and
   further permit little control over how they are displayed
   in-buffer.  Links are more flexible but lacks display control and
   becomes somewhat painful with many arguments[2].  Also, MY-FUN
   doesn't take a 'description'.  With (*) I could simply write
   
 [MY-FUN PROPERTIES].
   
   Perhaps, I could even define org-BACKEND-MY-FUN in a babel block
   if it's only relevant to the current file.

There's been some work and some discussion on this already, most
notably Aaron already supplied some patches towards this end[3],
but using a slightly different syntax more like the link syntax;
e.g. textcite above would look like

  [[textcite:bibtex-keypre%3Dfoopost%3Dbar][whatever]]

where whatever is ignored.  The state of the discussion is to some
extend summarized in the next post.
  
It would love to hear whether other people find something like this to
be a good idea?  Would anyone find a use such a framework?  Would (*)
conflict with anyone's current usage of Org?  Is (*) too ambitious and
in terms of getting citation support?  Is this is taking a musket to
kill a butterfly?  What are the the flaws in the above.

I'm not a good (lisp) programmer, but I think I have a month off this
summer where I could work on something like the above.

Thanks for reading,
Rasmus

Footnotes: 
[1] http://mid.gmane.org/20130303070635.GA12112%40panahar
[2] my citation links often look like postnote;prenote without
showing the BIBTEX-KEY or citation format.
[2] here http://mid.gmane.org/87lia0s7wi.fsf%40bzg.ath.cx
and here http://mid.gmane.org/87wqthk7vj.fsf%40gmail.com.


-- 
When in doubt, do it!




Re: [O] Effort entry and confusing effort estimates

2013-05-21 Thread Bastien
Hi Lawrence,

Lawrence Mitchell we...@gmx.li writes:

 I would argue that

 (org-duration-string-to-minutes
   (org-minutes-to-clocksum-string
 (org-duration-string-to-minutes some-value)))

 Should be a no-op.  But that is only the case if
 org-time-clocksum-use-effort-durations is t.

Agreed.  Thanks for the clear explanations.  Can you provide a patch
to get the correct behavior?  At the time, I could not closely watch
the side-effect of introducing `org-time-clocksum-use-effort-durations'
and this is clearly one of them.

Thanks in advance!

-- 
 Bastien



Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Rasmus
Alan Schmitt alan.schm...@polytechnique.org writes:

 OK, sounds good, I've applied it.

Thanks.

Let's wait with the rest till Vicktor's had a chance to look over it.

–Rasmus

-- 
Summon the Mothership!




Re: [O] using gnuplot's splot and every commands on org-mode table data

2013-05-21 Thread Eric S Fraga
Achim Gratz strom...@nexgo.de writes:

[...]

 I've implemented calculation separators that register as hlines for
 table formulas, but are ignored when row groups are constructed for
 export.  Your example table would then look like this:

Achim,

just to apologise for not getting back to you earlier on this.  I've
been swamped with work.  I'll try to have a test of your table updates
this week!

thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-144-gf1b99a




Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread Russell Adams
On Tue, May 21, 2013 at 08:03:45AM -0400, François Pinard wrote:
 I also have my own screenshot tool (this was my first own addition to
 Org mode, soon after I started to use it, quite a while ago now!) which
 is intermediate in features between Russell's and Max's.

I can't take credit, that snippet has floated around on the ML for a
while and I only changed the filename format to suit my tastes.

Thanks.

--
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] patch for htmlize.el

2013-05-21 Thread Eric Schulte
Bastien b...@gnu.org writes:

 Hi Eric,

 Carsten Dominik carsten.domi...@gmail.com writes:

 Yes, that is all right at least for now, please go ahead.


Done


 Please also send an email to htmlize.el's author -- I think he's
 reading the mailing list, but ensuring he does would be nice.


Done, Thanks,


 Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Rasmus
A lot of people more clever than me have thought about this topic.
Here I'll just summarize the org-exp-bibtex missing in
git?-thread.  The ordering more or less follows how it was
displayed in my Gnus.  I've tried to stay honest to the people
I've quoted and hopefully I've not failed too badly.  Also, I hope
I've not forgotten valuable suggestions.  I've not quoted Thomas,
but he gave some insights of what one would want in citation here
http://mid.gmane.org/m1a9qczekf.fsf%40tsdye.com.
   

There were approximately three types of suggestions:
1. the new-type approach, which I've tried to generalize more
   above.  Aaron made valueable suggestions here.  Nicolas gave it
   some support.
2. The extending link approach, notably Bastien, Andreas and Aaron
   even supplied patches!
I've also included some quick references to the current frontier
using links.  Lastly, there's some links to implementation in other
formats.

The new-type approach
   - Nicolas: 
 #+BEGIN_QUOTE
 It would be good to integrate citations in export framework
 [...]
 Maybe something like [cite:]. org-element could parse this, and
 ox.el provide some tools to access data. Then each back-end could deal
 with them.
 [...]
 I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter
 (link syntax) implies a (optional) description part. I don't think
 a description is ever meaningful in citations.
 #+END_QUOTE
 Ref: http://mid.gmane.org/87ehfwwgdd.fsf%40gmail.com and
 http://mid.gmane.org/874ngkzjt6.fsf%40gmail.com

   - Much of my discussion in the previoues post is similar to Aaron's
 response to my original post
 #+BEGIN_QUOTE
 So, a citation like [cite:doi:parens:some-doi:key=valkey2=val2] would be
 displayed by:
 1. call (org-lookup-cite-doi some-doi) - (:author Foo :title bar 
...)
 2. call (org-display-cite-parens '(:author Foo :title bar ...)) -
 (Foo 2000)
 3. (font-lock puts an overlay over the citation markup, with the
 returned string)
   
 If you click on the citation, org would open the location (URL or local
 file) returned by (org-resolve-cite-doi some-doi)
   
 A citation could exported by calling (org-export-cite-parens 'doi
 some-doi (:author foo :title bar) current-backend).  This function
 could just return \parencite{foo} if exporting to latex and the citation
 was already in a bibtex file.  But it could also just return “Foo 2000”
 as a static string for dumb backends like ASCII, or write the
 information to a temporary bibtex file (so that latex can atomatically
 use the bibliographic info looked up from a DOI citation).
 #+END_QUOTE
 Ref: http://mid.gmane.org/87txolk7qk.fsf%40gmail.com


- Jamuthan's take on viewing citation as footnotes
 #+BEGIN_QUOTE
 I view Citations as closer to Footnotes.  The syntax should parallels
 footnotes syntax.
 
 1. PROPERTIES should be opaque to Org.  It is a key or a list of
keys possibly bibtex but Org doesn't take stand on how it
looks like.
   
 2. There will be a org-BACKEND-citation-reference.
 3. There will be a org-BACKEND-bibliography.
   
 2, 3 more likely with interface with respective citation processor
 (citation processor as opposed to a database) via CLI.  Citation
 processor could be whatever org-exp-bibtex interfaces with right now.  I
 also have some proof-of-concept - see zotcite - for zotero.
   
 2, 3 will parallel footnote-reference and footnote-section callbacks in
 HTML backend.
   
 4. Footnotes can be introduced with either fn: prefix or cite:
prefix.  There should be a way to put fn: and cite: in same
enumeration context.  There should be a way to put fn: and
cite: in different enumeration context.  The former case could
be a degenerate mode where Org can transcode what is seen in
the buffer where everything is footnotes.  The latter case
will result in Citations and Bibliography being generated by
the above backend transcoders.
   
 5. Citation definitions in Org buffer will be *ignored*.  (It
could be considered when the exporter works in a degenerate
footnote only mode where plain text transcoding is resorted to
because there is no suitable application available for the
backend format.)  Plain text citation definitions are only to
help the author have a glimpse of what he is doing, it has
only UI-value but no contents value.
   
 6. There may be an advisory citation style - say APA, Chicago
etc - which the backends may honor or ignore.
  #+END_QUOTE


The extend-link suggestions:

   - Andreas Leha suggest something like what I suggested above, but
 extending upon the link syntax.  What I agree strongly with is:

   citations are more than links but also include information on
   formatting
 
   

Re: [O] GFDL

2013-05-21 Thread Sebastien Vauban
Hi Bastien,

Bastien wrote:
 Ben Finney ben+em...@benfinney.id.au writes:
 It bothers me mostly for the guide, where I did spend a lot of time to
 make it compact, and now something like one fifth of it is license
 text.  We may actually consider to re-release the guide under a
 different license.

 Please use this as an opportunity to seriously consider relicensing the
 entire work (programs, documentation, etc.) of Org-mode under the same
 license: the GNU GPL. It does not have the special problems of the FDL,
 and having the whole work under the same license terms makes it simpler
 and clearer.

 Well, relicensing the Org compact guide under GNU GPL is definitely
 feasible, but relicensing the Org manual is (sadly) not.  Let's take
 the feasible step first?

FMI, why is GNU GPL not applicable to the manual?

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Effort entry and confusing effort estimates

2013-05-21 Thread Ken Mankoff

Hi Bastien,

On Tue, 21 May 2013, Bastien wrote:


Ken Mankoff mank...@gmail.com writes:

But I'm still confused what 'org-set-effort' expects/interprets 
compared to 'org-clock-modify-effort-estimate'. Any clarification 
will be much appreciated.


`org-set-effort' allows you to _set_ the effort value.

`org-clock-modify-effort-estimate' allows you to either set the 
effort value (e.g. if you enter 1:30, the old value will be 
replaced by this one) or to increment/decrement the effort value 
by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the 
current value by 1 day.  1 day is interpreted depending on 
`org-effort-durations', which see.


Thanks for the explanation. I guess I'm confused why one 
formats/converts/checks the input and the other does not. I guess 
this doesn't imply that org-set-effort does anything different, it 
really is just a pure subset of org-clock-modify-effort-estimate.


Thanks,

  -k.




Re: [O] ical2org.py

2013-05-21 Thread Guido Van Hoecke
Eric S Fraga e.fr...@ucl.ac.uk writes:

 aitor aitors2...@gmail.org writes:

 Hi,

 I've implemented a little script which converts ics files to
 org-mode. You can find the script here:

 https://github.com/asoroa/ical2org.py

 Aitor,

 I would like to try this out but, as I am not a python user, I have no
 idea how to get the two bits you indicate being necessary (icalendar,
 pytz) installed.  I have installed python-dateutil and python-pycalendar
 as these looked the most obvious candidates for icalendar but no
 luck.  Searching the repositories for pytz draws a blank as well.

I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it
and ran `sudo python setup.py install'

Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg
file so you just run `sudo easy-install pytz-2013b-py2.7.egg'

This command should get you going:
`./ical2org.py input.ics  output.org

Hope this helps,


Guido

--
Ever since prehistoric times, wise men have tried to understand what,
exactly, make people laugh.  That's why they were called wise men.
All the other prehistoric people were out puncturing each other with
spears, and the wise men were back in the cave saying: How about:
Would you please take my wife?  No.  How about: Here is my wife, please
take her right now.  No.  How about:  Would you like to take something?
My wife is available.  No.  How about ...
-- Dave Barry, Why Humor is Funny



Re: [O] GFDL

2013-05-21 Thread François Pinard
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 FMI, why is GNU GPL not applicable to the manual?

While I would have long to say, here, I rather censor myself, mostly.

I sometimes happen to think that the GDFL happened not so long after
Richard Stallman and I had a harsh and long dispute about the GNU tar
manual.  In short, I wanted to publish it, Richard wanted that I refrain
from doing so: he expected the manual to be a source of FSF revenue.
The GDFL wording opens the door to Richard's restrictions, while the
GPL, which I used, is more in the spirit of the remainder of the FSF.

GNU tar has it own set of technical difficulties, and I hope I've been
able to put it back on track so it became maintainable again.  But in
many non-technical ways, GNU tar has been an administrative nightmare.

François



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread Haider Rizvi
Max Mikhanosha m...@openchat.com writes:

 Hi All,

 I've been writing some documentation in OrgMode with screenshots, and
 as with any screenshot taking, it takes a while to get one just right.

 A few tiny helper utilities, quickly snowballed into this :-) It may
 need some cleanup, but IMHO its too awesome not to share it with the
 list.

 To try it out, you'll need /usr/bin/scrot which is available as
 scrot package on most distributions.

Cool. Can you make this a bit portable. On Mac OSX, the utility is
called screencapture, and can be run with the same flags. Here is a
piece of code that was published earlier with a sample use.

http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272

,
| #+BEGIN_SRC emacs-lisp
|   (defun paste-clipboard-to-file (optional filename temp-dir)
| Take a screenshot using the crosshairs and saveit to FILENAME,
| if it is given or to a temp file in the TEMP-DIR
| directory. Then add an orgmode style link at point.
| (interactive)
| (let* ((temporary-file-directory (or temp-dir images))
|(fname (or filename (make-temp-file img nil .jpg
|   (call-process-shell-command (concat 
| /usr/sbin/screencapture -s  fname))
|   (insert \n[[file: fname ]])
|   (org-display-inline-images)))  
|   ;;
|   (global-set-key (kbd C-c p) 'paste-clipboard-to-file)
|   
| #+END_SRC
`

Regards, 
-- 
Haider




Re: [O] Customizing Org 8.0 Export

2013-05-21 Thread Scott Randby
On 05/21/2013 01:25 AM, John Hendy wrote:
 On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote:
 Is there any way to make all of org's variables available for
 customization on startup?

 
 Yes, see the original exporter announcement:
 
 http://article.gmane.org/gmane.emacs.orgmode/65574
 
 Section 3.0 calls out two methods of setting available backends. I'm
 guessing you are customizing org-export-backends vs (require 'ox-backend).
 Try requiring the backend and all associated variables will be there on
 startup.
 
 John

Thanks for the solution.

This is the second time in a row I've been referred to the original
exporter announcement. I'm sorry that my questions are so basic, but I
put off switching to 8.0 because my understanding of how org and Emacs
work is not very deep and I know little elisp. Once I have things set
up, I leave them alone and get to work. I'm very grateful to this list
for helping me figure out things that, in hindsight, are obvious.

Scott Randby



Re: [O] GFDL

2013-05-21 Thread Carsten Dominik

On 21 mei 2013, at 15:34, François Pinard pin...@iro.umontreal.ca wrote:

 Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
 writes:
 
 FMI, why is GNU GPL not applicable to the manual?
 
 While I would have long to say, here, I rather censor myself, mostly.
 
 I sometimes happen to think that the GDFL happened not so long after
 Richard Stallman and I had a harsh and long dispute about the GNU tar
 manual.  In short, I wanted to publish it, Richard wanted that I refrain
 from doing so: he expected the manual to be a source of FSF revenue.
 The GDFL wording opens the door to Richard's restrictions,

I am curious, what passage does make such restrictions
possible, and which kinds of restrictions?

- Carsten


 while the
 GPL, which I used, is more in the spirit of the remainder of the FSF.
 
 GNU tar has it own set of technical difficulties, and I hope I've been
 able to put it back on track so it became maintainable again.  But in
 many non-technical ways, GNU tar has been an administrative nightmare.
 
 François
 




Re: [O] Customizing Org 8.0 Export

2013-05-21 Thread John Hendy
On Tue, May 21, 2013 at 8:53 AM, Scott Randby sran...@gmail.com wrote:
 On 05/21/2013 01:25 AM, John Hendy wrote:
 On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote:
 Is there any way to make all of org's variables available for
 customization on startup?


 Yes, see the original exporter announcement:

 http://article.gmane.org/gmane.emacs.orgmode/65574

 Section 3.0 calls out two methods of setting available backends. I'm
 guessing you are customizing org-export-backends vs (require 'ox-backend).
 Try requiring the backend and all associated variables will be there on
 startup.

 John

 Thanks for the solution.

 This is the second time in a row I've been referred to the original
 exporter announcement. I'm sorry that my questions are so basic, but I
 put off switching to 8.0 because my understanding of how org and Emacs
 work is not very deep and I know little elisp. Once I have things set
 up, I leave them alone and get to work. I'm very grateful to this list
 for helping me figure out things that, in hindsight, are obvious.

No problem, and I wouldn't say it was *that* obvious :) I found this
document extremely helpful:
- http://orgmode.org/worg/org-8.0.html

I also started (and should really update again/maintain!) this as a
landing place for documenting other things as they come up:
- http://orgmode.org/worg/exporters/ox-overview.html

And have a blog post walking through setting things up here, if it helps:
- 
http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html


Good luck! We're all learning here, so no worries on the mailing list.
More things for Google to index for users stumbling on this after you!


John


 Scott Randby



Re: [O] GFDL

2013-05-21 Thread François Pinard
Carsten Dominik carsten.domi...@gmail.com writes:

 I am curious, what passage does make such restrictions possible, and
 which kinds of restrictions?

Oh, I did not read the GFDL in quite a years, and really have no
interest in diving and scrutinizing it again :-).  More away I am from
all this, better I feel :-).  Sorry, just forget I've written this
morning, I was likely in some strange mood.

I do love the FSF idea and theory, and supported the GNU project in an
intense way for maybe more than twenty years.  But by now, in practice,
I just cannot stand their slightest abuse, anymore.  I'm all for
programming freedom, but this ought to include programmer freedom too!

François



Re: [O] ical2org.py

2013-05-21 Thread aitor
On Tue, May 21, 2013 at 03:10:51PM +0200, Guido Van Hoecke wrote:

 I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it
 and ran `sudo python setup.py install'
 
 Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg
 file so you just run `sudo easy-install pytz-2013b-py2.7.egg'
 
 This command should get you going:
 `./ical2org.py input.ics  output.org

Hi Guido,

thanks for the help! If the script gets enough interest I can sort out
an easy installation method for it.

best,
aitor



Re: [O] Customizing Org 8.0 Export

2013-05-21 Thread Scott Randby
On 05/21/2013 10:48 AM, John Hendy wrote:
 On Tue, May 21, 2013 at 8:53 AM, Scott Randby sran...@gmail.com wrote:
 On 05/21/2013 01:25 AM, John Hendy wrote:
 On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote:
 Is there any way to make all of org's variables available for
 customization on startup?


 Yes, see the original exporter announcement:

 http://article.gmane.org/gmane.emacs.orgmode/65574

 Section 3.0 calls out two methods of setting available backends. I'm
 guessing you are customizing org-export-backends vs (require 'ox-backend).
 Try requiring the backend and all associated variables will be there on
 startup.

 John

 Thanks for the solution.

 This is the second time in a row I've been referred to the original
 exporter announcement. I'm sorry that my questions are so basic, but I
 put off switching to 8.0 because my understanding of how org and Emacs
 work is not very deep and I know little elisp. Once I have things set
 up, I leave them alone and get to work. I'm very grateful to this list
 for helping me figure out things that, in hindsight, are obvious.
 
 No problem, and I wouldn't say it was *that* obvious :) I found this
 document extremely helpful:
 - http://orgmode.org/worg/org-8.0.html
 
 I also started (and should really update again/maintain!) this as a
 landing place for documenting other things as they come up:
 - http://orgmode.org/worg/exporters/ox-overview.html
 
 And have a blog post walking through setting things up here, if it helps:
 - 
 http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html

Thanks for these links. I have been to the org-8.0.html page before, but
I only read part of it. If I would just read through all these nice
pages, then there would be no problem setting things up. But my approach
to Emacs and org is rather haphazard --- I pick up those things I need
and ignore all the rest. My init.el file is a sorry mess. One of these
days I'll go through everything methodically.

 
 
 Good luck! We're all learning here, so no worries on the mailing list.
 More things for Google to index for users stumbling on this after you!

Yes, this list is great. I've asked simple questions on other lists and
received nasty RTFM responses.

 
 
 John
 

 Scott Randby
 



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread Feng Shu
Haider Rizvi hari...@gmail.com writes:

 Max Mikhanosha m...@openchat.com writes:

 Hi All,

 I've been writing some documentation in OrgMode with screenshots, and
 as with any screenshot taking, it takes a while to get one just right.

 A few tiny helper utilities, quickly snowballed into this :-) It may
 need some cleanup, but IMHO its too awesome not to share it with the
 list.

 To try it out, you'll need /usr/bin/scrot which is available as
 scrot package on most distributions.

 Cool. Can you make this a bit portable. On Mac OSX, the utility is
 called screencapture, and can be run with the same flags. Here is a
 piece of code that was published earlier with a sample use.

It's a good idea, import has nearly same feature as scrot and should
work with  org-screenshot ,it is included imagemagick

https://wiki.archlinux.org/index.php/Taking_a_Screenshot



 http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272

 ,
 | #+BEGIN_SRC emacs-lisp
 |   (defun paste-clipboard-to-file (optional filename temp-dir)
 | Take a screenshot using the crosshairs and saveit to FILENAME,
 | if it is given or to a temp file in the TEMP-DIR
 | directory. Then add an orgmode style link at point.
 | (interactive)
 | (let* ((temporary-file-directory (or temp-dir images))
 |(fname (or filename (make-temp-file img nil .jpg
 |   (call-process-shell-command (concat 
 | /usr/sbin/screencapture -s  fname))
 |   (insert \n[[file: fname ]])
 |   (org-display-inline-images)))  
 |   ;;
 |   (global-set-key (kbd C-c p) 'paste-clipboard-to-file)
 |   
 | #+END_SRC
 `

 Regards, 

-- 



Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

2013-05-21 Thread Viktor Rosenfeld
Hi,

Alan Schmitt wrote:

 Rasmus writes:
 
  I found a bug in that the subject variable should be a list cf. the
  KOMA manual.  This patch fixes this.
 
  It's pretty complex for something so simple, and I might be inclined
  to admit to the put it in a LCO-file approach might be better.
 
 I'd really like to have a second opinion on this. Viktor?

I think this patch is great simply from the usability standpoint of
being able to configure the behavior through customize (which I don't
generally use, but admit that it's a good thing).

I found a few issues though:

1. Choosing `No export' in customize results
`\KOMAoption{subject}{nil}'.

2. It is not possible to set a subject format in the LCO file because if
`org-koma-letter-subject-format' is set, the KOMA option will be
overwritten explicitly, and if it is set to `nil' then the subject is
inhibited altogether. This is actually a problem with the old code as
well. One way out of this is to only print the subject line (i.e.,
`\setkomavar{subject}{.}' if `org-koma-letter-subject-format' is nil and
and fix `noexport' to hide the subject (i.e., inhibit
`\setkomavar{subject}{.}'). Is this the entended behaviour? I'll try to
post a patch for this later tonight.

3. I'm not a big fan of the parentheses in the subject:(.) syntax, but
if that's required to use an option list with multiple values I think
it's okay. It would be nice to be able to specify a single value without
the parens, but it's not a high priority (and I don't know how to do
that).

Cheers,
Viktor

 
 Best,
 
 Alan
 



Re: [O] GFDL

2013-05-21 Thread Bastien


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 FMI, why is GNU GPL not applicable to the manual?

Because the manual is part of GNU Emacs, which is part of the GNU
project, and every project in the GNU project is required to publish
manuals in GNU FDL only.  Dual licensing is not an option here.

There are many discussions about this... a can of (dead) worms.

-- 
 Bastien




Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

2013-05-21 Thread Bastien


Hi Sébastien and John,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 I did not have time yet to bisect the problem, but it _seems_ to be a newly
 introduced feature.

Can you check if the problems persist *before* this commit?

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=b83c03

-- 
 Bastien




[O] [OT] Contributors to org.texi (was: GFDL)

2013-05-21 Thread Memnon Anon
Sebastien Vauban sva-n...@mygooglest.com
writes:

 Bastien wrote:
 Well, relicensing the Org compact guide under GNU GPL is definitely
 feasible, but relicensing the Org manual is (sadly) not.  Let's take
 the feasible step first?

 FMI, why is GNU GPL not applicable to the manual?

Hehe, on an unrelated side note, that made me curious: 
Who did actually end up in org.texi, and how would I start to find out?

0. $ git blame -C -C -M -e org.texi  ~/git-blame.txt
   (I searched the web for that ;)
1. We are only interested in the email addresses, so quick clean up with
   a keyboard macro.
2. Get rid of duplicates: 
   M-x sort-lines
   C-x h 
   M-x shell-command-on-region 
   uniq

And... I see 67 different addresses. Some clearly belong to one person,
so getting rid of the obvious ones my count goes down to ... 58?

Wow... 
Fun.

Back to work :)

Memon






Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread François Pinard
Feng Shu tuma...@gmail.com writes:
 Haider Rizvi hari...@gmail.com writes:
 Max Mikhanosha m...@openchat.com writes:
 scrot
 screencapture
 import (imagemagick)

 https://wiki.archlinux.org/index.php/Taking_a_Screenshot
 http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272

Thanks for these links! :-)

François



Re: [O] [patch] ox-koma-letter.el: credit [3/4]

2013-05-21 Thread Viktor Rosenfeld
Hi,

Rasmus wrote:

 This is probably the most fun change.  It adds special tags PS, ENCL,
 CC, AFTER_CLOSING as in my last patch set, but it uses heading this
 time.  E.g. ENCLs are under the heading * ENCL :ENCL:.  This was
 suggested by Nicolas, and it's nicer.  The ideas comes from
 ox-groff.el file ¹.  Thanks Luis!

This is great! A few things:

- It doesn't work because `org-koma-letter-special-content' is set to
  nil at the beginning of `org-koma-letter-template'. Why is that? If I
  comment it out everything works.

- The function `org-koma-letter--get-tagged-content' does not use the
  `info' argument. Also, the function is not documented.

- The second argument of `org-koma-letter-headline' is misspelled
  (`conents').

- I would remove the formatting from org-koma-letter-ps-prefix and put
  it in the docstring, simply because the separators for \encl and \cc
  are also not formatted in the KOMA-Script defaults.

 One thing I'd like to discuss is whether to adopt headings for TO and
 FROM also.  The Groff exporter already does so for it's letters.  The
 main benefit is that it allows for org-syntax.  IMO it's a lot nicer
 to look at as well.  Check the org-groff site in the footnote for an
 example.

I am not sure about this. I often write a letter below a task in my
Org files so I rely on exporting the subtree only. So I would have to
put the TO address below the letter text which looks weird, but is
doable. On the other hand, being able to use Org syntax and not have to
escape linebreaks with `\\' is a big plus.
 
 I'd be happy to look into this the next time I have a free day for
 programming if you guys (also) find in a more appealing.  (One
 additional benefit would be that for simple documents it wouldn't
 matter whether groff or scrlttr2 was used as backend).

This would be a nice advantage.

Maybe both options could be supported. I.e., use a FROM headline if
available, but fall back on option lines if not? Or is this too
confusing for users?

Cheers,
Viktor
 
 –Rasmus
 
 
 Footnotes: 
  ¹   
 http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html#sec-1-5
 
 -- 
 Powered by magic pixies!

 From eeaa129b6807465566be881b96a94e14706c9a28 Mon Sep 17 00:00:00 2001
 From: rasmus.pank rasmus.p...@gmail.com
 Date: Sun, 19 May 2013 21:50:14 +0200
 Subject: [PATCH 3/4] Added support for after closing and after document
  entities in ox-koma-letter.
 
 * ox-koma-letter.el (org-koma-letter-special-tags-after-closing): specials 
 tags inserted after =\end{closing}=
 * ox-koma-letter.el (org-koma-letter-special-tags-other): other special tags
 * ox-koma-letter.el (org-koma-letter-special-tags): collect
 the two previoues lists (this might be done in a wrong way).
 * ox-koma-letter.el (org-koma-letter-ps-prefix): a prefix for
 PS since scrlttr does not provide it.
 * ox-koma-letter.el (org-koma-letter-headline): stores content
 in a special list if it is =`org-koma-letter-special-tags'= as
 in ox-groff.  Only returns contents if not tags not in special
 tags.
 * ox-koma-letter.el (org-koma-letter-special-content): holds special
 content temporarily.
 * ox-koma-letter.el (org-koma-letter-template): added support
 for the headings with special tags.
 
 The following example will now export a sensible manner.
 
 * my letter
 here's a letter
 * PS :PS:
 it's requires this patch
 * CC :CC:
 Nicolas, Viktor and Alan
 * ENCL :ENCL:
 many patches
 1. this patch
 2. another patch.
 * include patches :AFTER_LETTER:
 \myspecial macro
 
 Namely, content of PS, ENCL and CC headings will be exported after
 \closing{.}  in the order prescribed by
 =`org-koma-letter-special-tags-after-closing'=.  The concent
 of the =AFTER_LETTER= heading will be inserted after
 =\end{letter}=, ideal for e.g. =pdfpages= commands.
 ---
  contrib/lisp/ox-koma-letter.el | 86 
 +++---
  1 file changed, 81 insertions(+), 5 deletions(-)
 
 diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
 index 77d21c7..8ae9fc5 100644
 --- a/contrib/lisp/ox-koma-letter.el
 +++ b/contrib/lisp/ox-koma-letter.el
 @@ -183,6 +183,29 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'boolean)
  
 +(defcustom org-koma-letter-ps-prefix \\textsc{ps}: 
 +  The prefix of PS.  Used to construct PS as \PS-SUFFIX PS\
 +  :group 'org-export-koma-letter
 +  :type 'string)
 +
 +
 +(defconst org-koma-letter-special-tags-after-closing
 +  '(PS ENCL CC)
 +  Headers tags to be inserted after closing)
 +
 +(defconst org-koma-letter-special-tags-other
 +  '(FROM AFTER_LETTER)
 +  Headers tags to be inserted after closing)
 +
 +(defconst org-koma-letter-special-tags
 +  (append org-koma-letter-special-tags-other
 +   org-koma-letter-special-tags-after-closing)
 +  Header tags with special meaning)
 +
 +(defvar org-koma-letter-special-content nil holds special
 +content temporarily.)
 +
 +
  
  ;;; Define Back-End
  
 @@ -198,15 +221,18 @@ Use 

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Viktor Rosenfeld
Hi, 

Rasmus wrote:

 Alan Schmitt alan.schm...@polytechnique.org writes:
 
  OK, sounds good, I've applied it.

Actually, this patch does break LCO files. Now, if you don't set AUTHOR
or EMAIL in the letter the default options from the LaTeX exporter
always overwrite the settings defined in LCO files.

Rasmus, couldn't you just set the old `org-koma-letter-sender' option if
you don't use LCO files?

Also, I agree that SENDER should have been called AUTHOR. It was a
workaround because the LaTeX backend would ignore nil values for AUTHOR
in derived backends (but not for EMAIL, so I kept this). This should now
have been fixed.

 Let's wait with the rest till Vicktor's had a chance to look over it.

Hmm, not fast enough. :-)

Cheers,
Viktor
 
 
 –Rasmus
 
 -- 
 Summon the Mothership!
 
 



Re: [O] [patch] ox-koma-letter.el: credit [1/4]

2013-05-21 Thread Viktor Rosenfeld
Hi,
Rasmus wrote:

 This one just updates the credit: most importantly with Viktor.

Cool, thanks!
 
   - Is it me or is there no option to have git send-email just fix a
 the subject and heads and let the email program do the rest?!  The
 manual and various blog post did not reveal how on earth to get it
 to just use Gnus for sending. . .  The program seems not really to
 follow the Unix principle. . .

I use format-patch to create the patch and send them manually. But
getting send-email to work would automate some things.

Cheers,
Viktor



Re: [O] [patch] ox-koma-letter.el: credit [3/4]

2013-05-21 Thread Rasmus
Viktor,

Good to hear from you!

 This is probably the most fun change.  It adds special tags PS, ENCL,
 CC, AFTER_CLOSING as in my last patch set, but it uses heading this
 time.  E.g. ENCLs are under the heading * ENCL :ENCL:.  This was
 suggested by Nicolas, and it's nicer.  The ideas comes from
 ox-groff.el file ¹.  Thanks Luis!

 This is great! A few things:

 - It doesn't work because `org-koma-letter-special-content' is set to
   nil at the beginning of `org-koma-letter-template'. Why is that? If I
   comment it out everything works.

Hmm, it should be populated by the headline function each time. . .
That is at least the idea.  I.e.
   - When exporting `org-koma-letter-special-content' gets populated
 and is available until next export.  
   - When exports run again stuff might have changed so I want to
 repopulate the variable.

Perhaps I had loaded some magic in Emacs when I tested it that wasn't
preserved in the patch.  I'll test it again ASAP.
  
 - The function `org-koma-letter--get-tagged-content' does not use the
   `info' argument. Also, the function is not documented.

No it doesn't use info.  I guess it's just for consistency.  It's more
or less taken from ox-groff.  I don't mind removing it.

 - The second argument of `org-koma-letter-headline' is misspelled
   (`conents').

Thanks!

 - I would remove the formatting from org-koma-letter-ps-prefix and put
   it in the docstring, simply because the separators for \encl and \cc
   are also not formatted in the KOMA-Script defaults.

So you'd set org-koma-letter-ps-prefix to nil or ?  The thing is, in
scrlttr2 does not add a ps-prefix by itself, which seems inconsistent.
So with your suggesting we'd get a more vanilla feel, which I guess
would normally be nice, but here somehow feel inconsistent to me.  I'm
happy to oblige on this issue.


 One thing I'd like to discuss is whether to adopt headings for TO and
 FROM also.  The Groff exporter already does so for it's letters.  The
 main benefit is that it allows for org-syntax.  IMO it's a lot nicer
 to look at as well.  Check the org-groff site in the footnote for an
 example.

 I am not sure about this. I often write a letter below a task in my
 Org files so I rely on exporting the subtree only. So I would have to
 put the TO address below the letter text which looks weird, but is
 doable. On the other hand, being able to use Org syntax and not have to
 escape linebreaks with `\\' is a big plus.

 Maybe both options could be supported. I.e., use a FROM headline if
 available, but fall back on option lines if not? Or is this too
 confusing for users?

The reason why I didn't add it as this point is that I'd want to keep
it 'backward compatible' and I had to think about it.  I was toying
with introducing a =:with-legacy= variable that would govern which of
=* TO :TO:= and =#+TO_ADDRESS= would be printed if both are present.

What do you think?

Thanks for your comments.
–Rasmus

-- 
The Kids call him Billy the Saint



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread Viktor Rosenfeld
Hi,

Haider Rizvi wrote:

 Max Mikhanosha m...@openchat.com writes:
 
  Hi All,
 
  I've been writing some documentation in OrgMode with screenshots, and
  as with any screenshot taking, it takes a while to get one just right.
 
  A few tiny helper utilities, quickly snowballed into this :-) It may
  need some cleanup, but IMHO its too awesome not to share it with the
  list.
 
  To try it out, you'll need /usr/bin/scrot which is available as
  scrot package on most distributions.
 
 Cool. Can you make this a bit portable. On Mac OSX, the utility is
 called screencapture, and can be run with the same flags. 

Attached is a very first try at making org-screenshot run on OS X. Many
open issues remain:

- Clicking in a window will not take a screenshot using `screencapture
  -s' but aborts the process altogether and does not create a file. To
  capture a window one has to use `screencapture -w'. Another option is
  to use `screencapture -i' and toggle between window and selection mode
  using the space bar. The problem with this approach is that hitting
  the control key will place the screenshot into the clipboard and not
  create a file either.  
  
- Delay does not work because `screencapture -d' has a different
  meaning. To delay a screenshot, one has to use `screencapture -T'.

Cheers,
Viktor
  
 Here is a
 piece of code that was published earlier with a sample use.
 
 http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272
 
 ,
 | #+BEGIN_SRC emacs-lisp
 |   (defun paste-clipboard-to-file (optional filename temp-dir)
 | Take a screenshot using the crosshairs and saveit to FILENAME,
 | if it is given or to a temp file in the TEMP-DIR
 | directory. Then add an orgmode style link at point.
 | (interactive)
 | (let* ((temporary-file-directory (or temp-dir images))
 |(fname (or filename (make-temp-file img nil .jpg
 |   (call-process-shell-command (concat 
 | /usr/sbin/screencapture -s  fname))
 |   (insert \n[[file: fname ]])
 |   (org-display-inline-images)))  
 |   ;;
 |   (global-set-key (kbd C-c p) 'paste-clipboard-to-file)
 |   
 | #+END_SRC
 `
 
 Regards, 
 -- 
 Haider
 
 



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-21 Thread Viktor Rosenfeld
Forgot to attach the patch in my last mail.

Sorry about the double posting.

Viktor Rosenfeld wrote:

 Hi,
 
 Haider Rizvi wrote:
 
  Max Mikhanosha m...@openchat.com writes:
  
   Hi All,
  
   I've been writing some documentation in OrgMode with screenshots, and
   as with any screenshot taking, it takes a while to get one just right.
  
   A few tiny helper utilities, quickly snowballed into this :-) It may
   need some cleanup, but IMHO its too awesome not to share it with the
   list.
  
   To try it out, you'll need /usr/bin/scrot which is available as
   scrot package on most distributions.
  
  Cool. Can you make this a bit portable. On Mac OSX, the utility is
  called screencapture, and can be run with the same flags. 
 
 Attached is a very first try at making org-screenshot run on OS X. Many
 open issues remain:
 
 - Clicking in a window will not take a screenshot using `screencapture
   -s' but aborts the process altogether and does not create a file. To
   capture a window one has to use `screencapture -w'. Another option is
   to use `screencapture -i' and toggle between window and selection mode
   using the space bar. The problem with this approach is that hitting
   the control key will place the screenshot into the clipboard and not
   create a file either.  
   
 - Delay does not work because `screencapture -d' has a different
   meaning. To delay a screenshot, one has to use `screencapture -T'.
 
 Cheers,
 Viktor
   
  Here is a
  piece of code that was published earlier with a sample use.
  
  http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272
  
  ,
  | #+BEGIN_SRC emacs-lisp
  |   (defun paste-clipboard-to-file (optional filename temp-dir)
  | Take a screenshot using the crosshairs and saveit to FILENAME,
  | if it is given or to a temp file in the TEMP-DIR
  | directory. Then add an orgmode style link at point.
  | (interactive)
  | (let* ((temporary-file-directory (or temp-dir images))
  |(fname (or filename (make-temp-file img nil .jpg
  |   (call-process-shell-command (concat 
  | /usr/sbin/screencapture -s  fname))
  |   (insert \n[[file: fname ]])
  |   (org-display-inline-images)))  
  |   ;;
  |   (global-set-key (kbd C-c p) 'paste-clipboard-to-file)
  |   
  | #+END_SRC
  `
  
  Regards, 
  -- 
  Haider
  
  
From 5938b848f4b9b30b25c903e3487834f9400f6ad9 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld listuse...@gmail.com
Date: Tue, 21 May 2013 19:32:16 +0200
Subject: [PATCH] org-screenshot: Let user configure capture program.

* org-screenshot.el (org-screenshot-capture-binary): Configure
the binary to capture a screenshot.
(org-screenshot-take): Do not use hardcoded `scrot' binary.
---
 contrib/lisp/org-screenshot.el | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/org-screenshot.el b/contrib/lisp/org-screenshot.el
index a54cb8f..54c8074 100644
--- a/contrib/lisp/org-screenshot.el
+++ b/contrib/lisp/org-screenshot.el
@@ -85,6 +85,11 @@
   Options for taking and managing screen-shots
   :group 'org-link)
 
+(defcustom org-screenshot-capture-binary scrot
+  Binary to capture screen contents. Use `scrot' on Linux and `screencapture' 
on Mac OS X.
+  :type 'string
+  :group 'org-screenshot)
+
 (defcustom org-screenshot-image-directory ./images/
   Directory in which screenshot image files will be stored, it
 be automatically created if it does't already exist.
@@ -307,7 +312,7 @@ screenshot is done, any more `C-u' after that increases 
delay by
   (or 
(apply 'start-process
   (append
-   (list scrot *scrot* scrot -s path)
+   (list scrot *scrot* org-screenshot-capture-binary -s 
path)
(when (plusp delay)
  (list -d (format %d delay)
(error Unable to start scrot process)))
-- 
1.8.2.3



Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

2013-05-21 Thread Rasmus
Viktor Rosenfeld listuse...@gmail.com writes:

  I found a bug in that the subject variable should be a list
  cf. the
  KOMA manual.  This patch fixes this.
 
  It's pretty complex for something so simple, and I might be
  inclined
  to admit to the put it in a LCO-file approach might be better.
 
 I'd really like to have a second opinion on this. Viktor?

 I think this patch is great simply from the usability standpoint of
 being able to configure the behavior through customize (which I don't
 generally use, but admit that it's a good thing).

 I found a few issues though:

 1. Choosing `No export' in customize results
 `\KOMAoption{subject}{nil}'.

Thanks, that's a bug.  I'll look into it ASAP. 

 2. It is not possible to set a subject format in the LCO file because
 if
 `org-koma-letter-subject-format' is set, the KOMA option will be
 overwritten explicitly, and if it is set to `nil' then the subject is
 inhibited altogether. This is actually a problem with the old code as
 well. One way out of this is to only print the subject line (i.e.,
 `\setkomavar{subject}{.}' if `org-koma-letter-subject-format' is nil
 and
 and fix `noexport' to hide the subject (i.e., inhibit
 `\setkomavar{subject}{.}').


Perhaps the  ox-latex.el way is the way to go:
#+TITLE: # i.e. nothing
The difference would be that here would have not to format subject
komavar at all.

 Is this the entended behaviour? I'll try to post a patch for this
 later tonight.

Yeah, let's think about it.  From my point of view, basically never
using LCO files, I think 
  1. it should be possible to not post a subject.  I tried to implement
 this via #+OPTIONS: subject:nil.
  2. But perhaps I'm trying to be too clever.  I might have defined
 komavar-subject in an LCO file, but still changing subject
 formating on the go.  This is not possible.
  3. If letting subject be disabled by an empty title 2. won't break
 it.  So how about the condition (pseudo lisp):
 (or (title is nil) (subject is nil))?

It should be pretty simple to get to that state I think.

 3. I'm not a big fan of the parentheses in the subject:(.) syntax, but
 if that's required to use an option list with multiple values I think
 it's okay. 

OK, perhaps there's a clever way to get it to accept several keywords
without a parenthese.  I'm not sure.

 It would be nice to be able to specify a single value without the
 parens, but it's not a high priority (and I don't know how to do
 that).

That should be possible.  I thought I'd tested it.  Note though, that
giving a single value overwrites the default.  I'm not sure whether it
should extend upon the default.

Cheers,
Rasmus

-- 
C is for Cookie



[O] org-export-html-date-format-string

2013-05-21 Thread Scott Randby
I'm having trouble customizing the variable
org-export-html-date-format-string. Before I tried to customize it, I
would get the date in the postamble when I exported to html:

  p class=dateCreated: 2013-05-21 Tue 12:44/p

The original string for the variable is: %Y-%m-%dT%R%z

I don't want this string, so I changed it to %F%T%Z which didn't give
any date when I exported. So I changed the string to %Y-%m-%d and still
had no date after export. Changing back to the default string doesn't
work either.

This seems like a bug. Here is what is in my init.el after customization:

 '(org-export-html-date-format-string %Y-%m-%dT%R%z)

 '(org-html-postamble t)

 '(org-html-postamble-format (quote ((en p class=\author\Author:
%a /p p class=\date\Date: %d/p p class=\creator\%c/p

Here is the html of the postamble after export:

  div id=postamble class=status
  p class=authorAuthor: Scott P. Randby /p
  p class=dateDate: /p
  p class=creatora
  href=http://www.gnu.org/software/emacs/;Emacs/a 24.2.1 (a
  href=http://orgmode.org;Org/a mode 8.0.3)/p
  /div

How do I get the date variable to work?

Scott Randby



Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Viktor Rosenfeld
Hi,

Rasmus wrote:

 Hi, 
 
 Now that 8.0 has shipped let's talk bibliography support.  This
 follows directly upon the discussion around March[1].

I did not follow the discussion in March and only skimmed through the
recent discussion in May [2]. But I was wondering if bibliography
support in the LaTeX exporter would be BibTex-only or if it would also
support biblatex, for example.

Cheers,
Viktor

[1] http://mid.gmane.org/20130303070635.GA12112%40panahar
[2] http://thread.gmane.org/gmane.emacs.orgmode/71754



Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Rasmus
Viktor Rosenfeld listuse...@gmail.com writes:

 Actually, this patch does break LCO files. Now, if you don't set
 AUTHOR or EMAIL in the letter the default options from the LaTeX
 exporter always overwrite the settings defined in LCO files.

This one is tough. . .

One could #+INCLUDE an org-file but that's not really a fair comment.

I'm not really sure how to progress.

1. One way would be do do a grep on the LCO files, but they might be
   in the TeX PATH which would vary over TeX systems and OSes.
2. Have people have empty AUTHOR and EMAIL if they've got the info in
   an LCO file, but this is not desirable.  
   - Supply an optional filter to remove this info ex-post, but how
 would it know when to run?
3. Define some function to intelligently guess values based on
   content.
   1. Perhaps a TYPE variable.  So if TYPE is business or causal
  and I select business a list with business-defaults would be
  applied.  OTOH this might be too complicated to just writing a
  LCO files. . .
4. Revert the path.

What should be the standard?  I'm compelled to go with work as the
LaTeX-backend, but it may not be optimal here if there's a need for
chaining email and name regularly.

 Rasmus, couldn't you just set the old `org-koma-letter-sender'
 option if you don't use LCO files?

Sure, I just thought it was inconsistent that the framework didn't use
the same keywords as other backends.  But consistent might lack for
good reasons.

For me the previous behavior was annoying since I usually don't set
AUTHOR and this didn't work nicely.

 Also, I agree that SENDER should have been called AUTHOR. It was a
 workaround because the LaTeX backend would ignore nil values for
 AUTHOR in derived backends (but not for EMAIL, so I kept this). This
 should now have been fixed.

OK.  So it's OK to switch to the AUTHOR keyword and just the default
is what we need to settle on?

–Rasmus

--
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .



[O] Org sources and PDF files on Worg

2013-05-21 Thread Viktor Rosenfeld
Hi,

I recently wrote a tutorial for the ox-koma-letter exporter [1] which
includes a link to an Org file [2] file and a PDF file [3] as examples.
The files are checked into the Worg repository, but they are not
available online. Is there something I have to do to enable this? At
first I thought the problem was related to the switchover to the new
exporter, but the issue persists. 

Also, an old version of the tutorial at an old address [4] is still
online even though I've changed the location in the git repository. How
can I delete this version?

Cheers,
Viktor

[1] http://orgmode.org/worg/exporters/koma-letter-export.html
[2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org
[3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf
[4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html



Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Rasmus
Viktor Rosenfeld listuse...@gmail.com writes:

 Now that 8.0 has shipped let's talk bibliography support.  This
 follows directly upon the discussion around March[1].

 I did not follow the discussion in March 

I tried to summarize it the second post since the thread was very
long.

 But I was wondering if bibliography support in the LaTeX exporter
 would be BibTex-only or if it would also support biblatex, for
 example.

Currently, you can use both through the link syntax, but it's not so
nice if you use prenote and postnotes.

I solely use biber + biblatex these days.

–Rasmus

-- 
This space left intentionally blank



Re: [O] org-export-html-date-format-string

2013-05-21 Thread Scott Randby
I solved the problem by putting the following in the file to be exported:

#+DATE: [2013-05-21 Tue 14:45]

However, this means I have to remember to change the date every time I
export. Is there an easier way to do this?

Scott Randby

On 05/21/2013 01:49 PM, Scott Randby wrote:
 I'm having trouble customizing the variable
 org-export-html-date-format-string. Before I tried to customize it, I
 would get the date in the postamble when I exported to html:
 
   p class=dateCreated: 2013-05-21 Tue 12:44/p
 
 The original string for the variable is: %Y-%m-%dT%R%z
 
 I don't want this string, so I changed it to %F%T%Z which didn't give
 any date when I exported. So I changed the string to %Y-%m-%d and still
 had no date after export. Changing back to the default string doesn't
 work either.
 
 This seems like a bug. Here is what is in my init.el after customization:
 
  '(org-export-html-date-format-string %Y-%m-%dT%R%z)
 
  '(org-html-postamble t)
 
  '(org-html-postamble-format (quote ((en p class=\author\Author:
 %a /p p class=\date\Date: %d/p p class=\creator\%c/p
 
 Here is the html of the postamble after export:
 
   div id=postamble class=status
   p class=authorAuthor: Scott P. Randby /p
   p class=dateDate: /p
   p class=creatora
   href=http://www.gnu.org/software/emacs/;Emacs/a 24.2.1 (a
   href=http://orgmode.org;Org/a mode 8.0.3)/p
   /div
 
 How do I get the date variable to work?
 
 Scott Randby
 



Re: [O] org-export-html-date-format-string

2013-05-21 Thread Nicolas Goaziou
Hello,

Scott Randby sran...@gmail.com writes:

 I'm having trouble customizing the variable
 org-export-html-date-format-string.

Use `org-html-metadata-timestamp-format' instead.


Regards,

-- 
Nicolas Goaziou



Re: [O] TOC in HTML export - how to change formatting of ToDo levels?

2013-05-21 Thread David Rogoff
 You should be able to customize the todo class only within the TOC context
 with such a rule:
 
 --8---cut here---start-8---
 #table-of-contents .todo {
 ...
 }
 --8---cut here---end---8---
 
 Best regards,
   Seb


Thanks for the info.  This will help a bit but still doesn't address the TOC 
code throwing out the actual ToDo states of the headlines and making everything 
either .todo or .done.

 David


Re: [O] org-export-html-date-format-string

2013-05-21 Thread Scott Randby
On 05/21/2013 02:55 PM, Nicolas Goaziou wrote:
 Hello,
 
 Scott Randby sran...@gmail.com writes:
 
 I'm having trouble customizing the variable
 org-export-html-date-format-string.
 
 Use `org-html-metadata-timestamp-format' instead.

Thanks. This worked after I replaced %d with %T in the format string for
org-html-postamble-format.

 
 
 Regards,
 



Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Viktor Rosenfeld
Hi,

Rasmus wrote:

 Viktor Rosenfeld listuse...@gmail.com writes:
 
  Actually, this patch does break LCO files. Now, if you don't set
  AUTHOR or EMAIL in the letter the default options from the LaTeX
  exporter always overwrite the settings defined in LCO files.
 
 This one is tough. . .
 
 One could #+INCLUDE an org-file but that's not really a fair comment.
 
 I'm not really sure how to progress.
 
 1. One way would be do do a grep on the LCO files, but they might be
in the TeX PATH which would vary over TeX systems and OSes.

Way too complicated and brittle, IMHO.

 2. Have people have empty AUTHOR and EMAIL if they've got the info in
an LCO file, but this is not desirable.  
- Supply an optional filter to remove this info ex-post, but how
  would it know when to run?

Empty AUTHOR and EMAIL lines are not user-friendly. However, another
option is to set `user-mail-address' and `user-full-name' to nil, but
then this would also affect other areas of Emacs beside the LaTeX
expoerter (which I currently no use so I can't speak to side-effects).

 3. Define some function to intelligently guess values based on
content.
1. Perhaps a TYPE variable.  So if TYPE is business or causal
   and I select business a list with business-defaults would be
   applied.  OTOH this might be too complicated to just writing a
   LCO files. . .

Basically duplicates LCO files but will never achieve the same
functionality.

 4. Revert the path.

Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)

 What should be the standard?  I'm compelled to go with work as the
 LaTeX-backend, but it may not be optimal here if there's a need for
 chaining email and name regularly.

I prefer 5. :-)
 
  Rasmus, couldn't you just set the old `org-koma-letter-sender'
  option if you don't use LCO files?
 
 Sure, I just thought it was inconsistent that the framework didn't use
 the same keywords as other backends.  But consistent might lack for
 good reasons.

The default LaTeX exporter does not have LCO files. Sure you can simply
\input a latex file but there is no dedicated support for this in Org
mode, is there? 

The LaTeX exporter also assumes that every LaTeX file needs a title, a
date, and an author, but this is not always true as the scrlttr2 class
shows (title, or subject, is definitely optional). Also, LaTeX blocks
which are evaluated separately don't need these values either. So I
understand striving for consistency, but I think that the use case here
is different enough to break it.

 For me the previous behavior was annoying since I usually don't set
 AUTHOR and this didn't work nicely.
 
  Also, I agree that SENDER should have been called AUTHOR. It was a
  workaround because the LaTeX backend would ignore nil values for
  AUTHOR in derived backends (but not for EMAIL, so I kept this). This
  should now have been fixed.
 
 OK.  So it's OK to switch to the AUTHOR keyword and just the default
 is what we need to settle on?

I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.

Cheers,
Viktor

 
 –Rasmus
 
 --
 . . . Stallman was indeed the tallest possible mountain and by
 standing on his shoulders you could see forever. . .
 



[O] org-plus-contrib elpa and ox-* files

2013-05-21 Thread Seth Mason
Back in the beginning  of May I pointed out what I thought was a bug
in server.mk that prevented the ox-* files in contrib from getting
included in the Org ELPA archives. It got fixed in
6de09e2d3e38ac84a09659931ee96dff5e5d68c9 (thanks Achim!).

I just installed org-plus-contrib-20130520.tar from Org ELPA but the
ox-* files still aren't there.  Maybe I was wrong about the source of
the issue? Or is there a delay between what hits master and what gets
to the Org ELPA archves?

Thanks in advance,



Re: [O] [patch] ox-koma-letter.el: credit [3/4]

2013-05-21 Thread Viktor Rosenfeld
Hi,

Rasmus wrote:

  - It doesn't work because `org-koma-letter-special-content' is set to
nil at the beginning of `org-koma-letter-template'. Why is that? If I
comment it out everything works.
 
 Hmm, it should be populated by the headline function each time. . .
 That is at least the idea.  I.e.
- When exporting `org-koma-letter-special-content' gets populated
  and is available until next export.  
- When exports run again stuff might have changed so I want to
  repopulate the variable.

Why not clear `org-koma-letter-special-content' at the start of
`org-koma-letter-headline'?

  - I would remove the formatting from org-koma-letter-ps-prefix and put
it in the docstring, simply because the separators for \encl and \cc
are also not formatted in the KOMA-Script defaults.
 
 So you'd set org-koma-letter-ps-prefix to nil or ?  The thing is, in
 scrlttr2 does not add a ps-prefix by itself, which seems inconsistent.
 So with your suggesting we'd get a more vanilla feel, which I guess
 would normally be nice, but here somehow feel inconsistent to me.  I'm
 happy to oblige on this issue.

Either nil or  or even PS. I guess there is no default because
people write things like PPS and PPPS and so on. Anyway, in my view
having \ps specially formatted is inconsistent because \encl and \cc are
not per default.

  One thing I'd like to discuss is whether to adopt headings for TO and
  FROM also.  The Groff exporter already does so for it's letters.  The
  main benefit is that it allows for org-syntax.  IMO it's a lot nicer
  to look at as well.  Check the org-groff site in the footnote for an
  example.
 
  I am not sure about this. I often write a letter below a task in my
  Org files so I rely on exporting the subtree only. So I would have to
  put the TO address below the letter text which looks weird, but is
  doable. On the other hand, being able to use Org syntax and not have to
  escape linebreaks with `\\' is a big plus.
 
  Maybe both options could be supported. I.e., use a FROM headline if
  available, but fall back on option lines if not? Or is this too
  confusing for users?
 
 The reason why I didn't add it as this point is that I'd want to keep
 it 'backward compatible' and I had to think about it.  I was toying
 with introducing a =:with-legacy= variable that would govern which of
 =* TO :TO:= and =#+TO_ADDRESS= would be printed if both are present.

I would definitely like to keep the old functionality. I like how your
patch uses headlines to add additional information to the letter. But in
the letters I wrote I would only need a FROM headline and having this
single headline below the letter text seems strange.

However, I realize that my preferences are very much tied to my workflow
and being able to specify an address below FROM or TO headlines is very
useful because it is so powerful (and probably easier to new users). If
a letter uses both a headline and an option line to set an address I
would think the headline should take precedence, because it is more
powerful. A `:with-legacy' variable doesn't really solve anything
because what does the exporter do if the variable is missing but there
are two addresses set? Maybe the exporter could simply emit a warning in
that case.

Cheers,
Viktor

 
 What do you think?
 
 Thanks for your comments.
 –Rasmus
 
 -- 
 The Kids call him Billy the Saint
 



Re: [O] performance of exporting large tables

2013-05-21 Thread D M German
 Nicolas Goaziou twisted the bytes to say:


 Nicolas Nicolas Goaziou n.goaz...@gmail.com writes:
  I am going to have a look at this.

 Nicolas I pushed a commit caching the results of some table functions. Export 
of
 Nicolas large tables should be a lot faster (I get 6 s now; it was 90 s 
before).

Hi Nicolas,

thank you very much. This has resolved my issue. I can now export an org file
with these tables in few seconds.

thank you,

--daniel


 Nicolas Regards,

 Nicolas -- 
 Nicolas Nicolas Goaziou


--
Daniel M. German  To read is to travel without all the hassles 
of luggage.
   Emilio Salgari
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 



Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Marcin Borkowski
Dnia 2013-05-21, o godz. 19:55:53
Viktor Rosenfeld listuse...@gmail.com napisał(a):

 Hi,
 
 Rasmus wrote:
 
  Hi, 
  
  Now that 8.0 has shipped let's talk bibliography support.  This
  follows directly upon the discussion around March[1].
 
 I did not follow the discussion in March and only skimmed through the
 recent discussion in May [2]. But I was wondering if bibliography
 support in the LaTeX exporter would be BibTex-only or if it would also
 support biblatex, for example.

Good point.

I do not use Org-mode for authoring (I'm quite happy with LaTeX itself
for that), and in LaTeX, I use neither bibtex nor biblatex; but AFAIK,
bibtex is basically dead like John Cleese's parrot.  I don't even think
that it needs to or should be supported; the faster bibtex usage fades
away, the better.

What I would suggest is to look into amsrefs manual.  The amsrefs
package was (is?) an interesting attempt at a /pure LaTeX/ solution to
the bibliography problem, not dependent on any executable other than
LaTeX.  It is not capable of sorting bibliographies, but other than
that is quite powerful (much more than bibtex, though seemingly less
than biblatex).  What is interesting here is its \ycite and \ocite
commands (see
http://mirrors.ctan.org/macros/latex/contrib/amsrefs/amsrdoc.pdf); it
might be a good idea to support something similar.  (I'm not sure
whether biblatex supports such a thing.)

 Cheers,
 Viktor

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] Org sources and PDF files on Worg

2013-05-21 Thread Jay Kerns
Hello Viktor,

On Tue, May 21, 2013 at 2:13 PM, Viktor Rosenfeld listuse...@gmail.com wrote:
 Hi,

 I recently wrote a tutorial for the ox-koma-letter exporter [1] which
 includes a link to an Org file [2] file and a PDF file [3] as examples.
 The files are checked into the Worg repository, but they are not
 available online. Is there something I have to do to enable this? At
 first I thought the problem was related to the switchover to the new
 exporter, but the issue persists.

 Also, an old version of the tutorial at an old address [4] is still
 online even though I've changed the location in the git repository. How
 can I delete this version?

 Cheers,
 Viktor

 [1] http://orgmode.org/worg/exporters/koma-letter-export.html
 [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org
 [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf
 [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html


I believe I can give a partial answer: it looks like Worg isn't
publishing right now, which suggests that there was a recent commit
which broke things.  The search for the problem begins.  Once the
error is identified and fixed, then things should get back to normal.

I've copied Marc on this message - we'll see if we can track the problem down.

Thanks for the report.

-- 
Jay Kerns


-- 
G. Jay Kerns, Ph.D.
Youngstown State University
http://people.ysu.edu/~gkerns/



Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

2013-05-21 Thread Rasmus
Viktor Rosenfeld listuse...@gmail.com writes:

 Or 5, keep the change from SENDER to AUTHOR but revert the default
 values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
 lines could be removed because they duplicate the derived latex
 backend.)

I once had a teacher who talked about the optimal degree of
conservatism (as well speaking positively about being in the infamoues
ivory tower).  5. is fine with me.  So I guess the deal is
  1. default value is the same as in ox-latex.
  2. . . . but it's kept in a seperete variable ox-kl variable.


 The default LaTeX exporter does not have LCO files. Sure you can simply
 \input a latex file but there is no dedicated support for this in Org
 mode, is there? 

only through #+LATEX: \input{.} I guess (or something similar).

 I think that switching from SENDER to AUTHOR, keeping the
 `org-koma-letter-{author,email}' variables in the KOMA backend, but
 setting them per default to `user-full-name' and `user-mail-address',
 would solve both your problems and let me keep LCO files. I would then
 simply set these `org-koma-letter-*' variables to `nil' and document
 this setup in the docstring. I'll see tomorrow if this is feasable.

Does the attached patch work for you (also with ps tags?)

–Rasmus

-- 
Dung makes an excellent fertilizerFrom 92b07bac2d707f01e48796778453b67a9ecd1daa Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Wed, 22 May 2013 01:16:54 +0200
Subject: [PATCH 5/5] Variables for author and email for ox-koma-letter and a
 bug fix.

* ox-koma-letter.el (koma-letter): reintroduced koma-letter
specif author and email.
* ox-koma-letter.el (koma-letter): set
org-koma-special-content to nil when exporting

The former is needed so that author/email can be set in a LCO file.

TINYCHANGE
---
 contrib/lisp/ox-koma-letter.el | 49 +++---
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 020df52..92cf13a 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -109,6 +109,12 @@
   :group 'org-export-koma-letter
   :type 'string)
 
+(defcustom org-koma-letter-email user-mail-address
+  The default email address stored in the letter. )
+
+(defcustom org-koma-letter-author user-full-name
+  The default name of the sender. )
+
 (defcustom org-koma-letter-signature \\usekomavar{fromname}
   String used as the signature.
   :group 'org-export-koma-letter
@@ -143,7 +149,6 @@ English manual of 2012-07-22)
   :group 'org-export-koma-letter)
 
 
-
 (defcustom org-koma-letter-use-backaddress t
   Print return address in small line above to address.
   :group 'org-export-koma-letter
@@ -179,7 +184,6 @@ Use `foldmarks:true' to activate default fold marks or
   :group 'org-export-koma-letter
   :type 'string)
 
-
 (defconst org-koma-letter-special-tags-after-closing
   '(PS ENCL CC)
   Headers tags to be inserted after closing)
@@ -193,7 +197,7 @@ Use `foldmarks:true' to activate default fold marks or
 	  org-koma-letter-special-tags-after-closing)
   Header tags with special meaning)
 
-(defvar org-koma-letter-special-content nil holds special
+(defvar org-koma-letter-special-contents nil holds special
 content temporarily.)
 
 
@@ -203,10 +207,10 @@ content temporarily.)
 (org-export-define-derived-backend 'koma-letter 'latex
   :options-alist
   '((:lco LCO nil org-koma-letter-class-option-file)
-(:sender AUTHOR nil user-full-name t)
+(:sender AUTHOR nil org-koma-letter-author)
 (:from-address FROM_ADDRESS nil org-koma-letter-from-address newline)
 (:phone-number PHONE_NUMBER nil org-koma-letter-phone-number)
-(:email EMAIL nil user-mail-address t)
+(:email EMAIL nil org-koma-letter-email)
 (:to-address TO_ADDRESS nil nil newline)
 (:place PLACE nil org-koma-letter-place)
 (:opening OPENING nil org-koma-letter-opening)
@@ -275,29 +279,31 @@ channel.
 ;; Thanks, Luis!
 
 (defun org-koma-letter--get-tagged-content  (tag info)
-  (cdr  (assoc tag org-koma-letter-special-content)))
+  (cdr  (assoc tag org-koma-letter-special-contents)))
 
 
-(defun org-koma-letter-headline (headline conents info)
+(defun org-koma-letter-headline (headline contents info)
   Transcode a HEADLINE element from Org to LaTeX.
 CONTENTS holds the contents of the headline.  INFO is a plist
 holding contextual informatio.n
 
 Note that if a headline is tagged with a tag from
 `org-koma-letter-special-tags' it will not be exported, but
-stored in `org-koma-letter-special-content' and included at the
+stored in `org-koma-letter-special-contents' and included at the
 appropriate place.
   (let*
   ((tags (and (plist-get info :with-tags)
 		 (org-export-get-tags headline info
-(if (member (car tags) org-koma-letter-special-tags)
-	(cond ((member (car tags) '(PS ps))
-	   (progn
-		 (push (cons (car tags) (concat (plist-get info :ps-prefix) contents))
-		

Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Christian Wittern

Hi Rasmus,

On 2013-05-21 21:21, Rasmus wrote:

Now that 8.0 has shipped let's talk bibliography support.  This
follows directly upon the discussion around March[1].
Thanks for a great post and for taken initiative for making org-mode even 
better for my purposes.  I started using org for writing papers a few years 
ago and I am not looking back.  The weak point however is bibliographies, as 
you say.


FWIW, I will describe my use case.  For drafting and when I can get away 
with it, I am going from org to PDF through XeLaTex, with either bibtex or 
more recently biber+biblatex.  However, when I submit papers, in most cases 
they have to be in a wordprocessor format, so I am going through the ODT 
export here.   In my current workflow this means that the bibliographie 
falls apart and in the end (deadlines!!) I usually cut and paste what I can 
get into either HTML or PDF.  This is not ideal and if this can improve it 
would mean a lot to me.


One problem I have had with bibtex and which I am now kind of dealing with 
(albeit still in a hackish way) in biber+biblatex is that I need specific 
formatting of the entries depending on the language I am publishing in, 
which is mostly either English or Japanese.  So for Japanese sources cited 
in English papers, I have to give the author and title optionally in 
Japanese characters, but also in romanized form and possibly in translation, 
whereas English sources in Japanese might require a Japanese form of the 
names and again a translation into Japanese.   I ended up adding extra 
fields to my bibtex file, since no bibliographic format I know of (except 
TEI) would support this and still allow me to integrate it into my workflow, 
but the big problem lies of course in integrating this better in my workflow.


So whatever org ends up with having in terms of bibliography, I would like 
to work with you and however jumps in to make sure that it also fits this 
need (which is actually not limited to an exotic field like mine, but is 
quite common for academics working in East Asia).


All the best,

Christian

--
Christian Wittern, Kyoto




Re: [O] GFDL

2013-05-21 Thread Carsten Dominik

On 21.5.2013, at 17:03, François Pinard pin...@iro.umontreal.ca wrote:

 Carsten Dominik carsten.domi...@gmail.com writes:
 
 I am curious, what passage does make such restrictions possible, and
 which kinds of restrictions?
 
 Oh, I did not read the GFDL in quite a years, and really have no
 interest in diving and scrutinizing it again :-).  

OK, I will not ask again. :)

 More away I am from
 all this, better I feel :-).  Sorry, just forget I've written this
 morning, I was likely in some strange mood.
 
 I do love the FSF idea and theory, and supported the GNU project in an
 intense way for maybe more than twenty years.  But by now, in practice,
 I just cannot stand their slightest abuse, anymore.  I'm all for
 programming freedom, but this ought to include programmer freedom too!
 
 François
 




Re: [O] Let's discuss citation and Org syntax

2013-05-21 Thread Erik Hetzner
At Tue, 21 May 2013 19:55:53 +0200,
Viktor Rosenfeld wrote:
 
 Hi,
 
 Rasmus wrote:
 
  Hi, 
  
  Now that 8.0 has shipped let's talk bibliography support.  This
  follows directly upon the discussion around March[1].
 
 I did not follow the discussion in March and only skimmed through the
 recent discussion in May [2]. But I was wondering if bibliography
 support in the LaTeX exporter would be BibTex-only or if it would also
 support biblatex, for example.

And to further confuse the issue, why not consider pandoc style
citations [1]?

This works right now. Create an org file:

  See [@citekey, p. 10] for more info.

(assuming a bibtex, endnote, ris, ... file that contains a cite with
key “citekey”). Export to markdown. Process in pandoc, either to
latex:

  ❤ pandoc --natbib test.md -t latex -s --biblio test.bib

or to HTML, etc:

  ❤ pandoc test.md -s --biblio test.bib

While it would be nice to make this work natively with org, especially
with latex output, it would be great if compatibility with pandoc
could be obtained.

best, Erik

1. http://johnmacfarlane.net/pandoc/README.html#citation-rendering
Sent from my free software system http://fsf.org/.