Re: [O] Math formatting in HTML export - The Org Manual

2014-10-14 Thread Eric S Fraga
Have a look at the following variable and note the SNIPPET argument:

,[ C-h v org-latex-packages-alist RET ]
| org-latex-packages-alist is a variable defined in `org.el'.
| Its value is (( xcolor)
|  ( tikz)
|  ( listings)
|  (version=3 mhchem)
|  ( amsmath t))
| 
| Original value was nil
| 
| Documentation:
| Alist of packages to be inserted in every LaTeX header.
| 
| These will be inserted after `org-latex-default-packages-alist'.
| Each element is either a cell or a string.
| 
| A cell is of the format:
| 
| (options package SNIPPET-FLAG)
| 
| SNIPPET-FLAG, when non-nil, indicates that this package is also
| needed when turning LaTeX snippets into images for inclusion into
| non-LaTeX output.
| 
| A string will be inserted as-is in the header of the document.
| 
| Make sure that you only list packages here which:
| 
|   - you want in every file;
|   - do not conflict with the setup in `org-format-latex-header';
|   - do not conflict with the default packages in
| `org-latex-default-packages-alist'.
| 
| You can customize this variable.
`


-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)



[O] What about a TOC export filter?

2014-10-14 Thread Thorsten Jolitz

Hi List, 

in a derived backend it would be OK to let the parent backend (html)
export the TOC, but I need to post-process the exported html (wrap it in
extra code). 

Since I did not find suitable functionality for this, I use a kind of
workaround: 

 1. disable default with option toc:nil

 2. put a #+TOC: headlines 2 line

 3. copy and adapt (i.e. overwrite) the org-html-keyword transcoder

but wouldn't a toc-filter make more sense? Did I miss it?

-- 
cheers,
Thorsten





Re: [O] export to odt: error in style.xml

2014-10-14 Thread Rasmus
Hi,

Achim Gratz strom...@nexgo.de writes:

 Rasmus writes:
 Could you please rebase or cherry-pick your changes onto the
 then-current master before committing them?
 However, can you please elaborate on what exactly I did wrong?  I have
 checked for the following to understand your criticism:

   1. When I do $ git diff 004332b^ 00433b I get a one line diff (except
  the context).  There are no change of white space or other garbage.
  Why is this not cherry-picked?
 […]

 This one is, but your earlier commits introduced half a dozen

Let's be clear, there are *two* redundant merges.

 spurious merges since they were all started at different points on
 master.

I fail to see the relevance of your remark.

 In principal it is true.  However, is it a real issue¹ in practice?

 The script that generates the ChangeLog for the Emacs merge will list
 all of these separately and Bastien or who else is doing the merge will
 have to manually put them back together.

Thanks.  I will be more careful on this.

Bastien b...@gnu.org writes:

 I was asking no such thing, only that the author name and email you use
 for your commits are always one and the same.

 Yes: it's important to use the same name and address so that we can
 group changelogs under the same person when adding them to Emacs.

Thanks.  

Which file is grouped by author?  Looking quickly at ORG-NEWS, it
doesn't seem to be grouped by author?  Anyway

—Rasmus

-- 
C is for Cookie




Re: [O] Sharing: Agenda skip function to remove future-scheduled items

2014-10-14 Thread Sebastien Vauban
James Harkins wrote:
 [...] I realized that I didn't want to see items that are scheduled
 for the future, because this is my agenda view for what tasks are
 available right now. For example, if I have a task to update my grade
 sheet, it doesn't make sense to do that before I've taught the
 lessons -- so I don't want to see the task until it's actually due.

 I didn't find a straightforward way to use a property search such as
 scheduled is nil or scheduled  today, but I did (with some false
 starts) hack up a skip function that seems to do the job.

I use the following (tricky) settings, which should do what you have in
mind, if I'm not mistaken:

#+begin_src emacs-lisp
  ;; Don't show scheduled entries in the global `todo' list.
  (setq org-agenda-todo-ignore-scheduled 'future)

  ;; Don't show entries scheduled in the future in the global
  ;; `todo' list (until they are within the warning period).
  (setq org-agenda-todo-ignore-deadlines 'near)

  ;; Honor `todo' list `org-agenda-todo-ignore...' options also
  ;; in the `tags-todo' list.
  (setq org-agenda-tags-todo-honor-ignore-options t)
#+end_src

Best regards,
  Seb

-- 
Sebastien Vauban




[O] [ob-R] table variable passing broken

2014-10-14 Thread Andreas Leha
Hi all,

There seems to be a bug in table passing as variables now using the
tangle-friendly version of passing variables.


Here is an example (I get an error also with emacs -Q):

--8---cut here---start-8---
* test
#+name: testtab
| variable  | display   | unit  |
|---+---+---|
| num_cells | Number of Cells in Well   |   |
| cell_area | Cell Area | μm²   |
| nucleus_area  | Nucleus Area  | μm²   |
| roundness | Cell Roundness|   |
| ratio_w2l | Cell Width to Length Ratio|   |
| inten_nuc_dapi_median | Intensity Nucleus DAPI Median |   |
| dapi_median   | Intensity Nucleus DAPI Median |   |
| edu_median| Intensity edu Median  |   |
| oct4_median   | Intensity oct4 Median |   |
| clump_size| Clump Size| cells |
| short_name| Cell Line |   |
| p_col | Column|   |
| batch | Batch |   |
| concentration | Fibronectin Concentration | ugml  |
| Residual  | Residual  |   |
| evaluation_guid   | Plate |   |
| donor | Genotype  |   |

#+BEGIN_SRC R :session *test* :var test=testtab
  test
#+END_SRC

#+RESULTS:
--8---cut here---end---8---



I see this in my R session:

--8---cut here---start-8---
Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings,  
(from testorg.org!917613Wp#22) : 
  line 17 did not have 3 elements
--8---cut here---end---8---

This is on
- GNU Emacs 24.4.50.1 (x86_64-apple-darwin13.3.0, NS appkit-1265.21 Version 
10.9.4 (Build 13E28)) of 2014-09-02 on mib106584i.local
- Org-mode version 8.3beta (release_8.3beta-470-g087f8e)
- ess-version: 14.05 [git: 4283f1304a54502c42707b6a4ba347703f0992dd]

Best,
Andreas




[O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

As discussed previously, I would like to modify property drawers syntax.
The change is simple: they must be located right after a headline and
its planning line, if any.  Therefore the following cases are valid

  * Headline
:PROPERTIES:
:KEY: value
:END:

  * Headline
SCHEDULED: 2014-10-14 mar.
:PROPERTIES:
:KEY: value
:END:

but, in the following case, the scheduled keyword will not be recognized

  * Headline
:PROPERTIES:
:KEY: value
:END:
SCHEDULED: 2014-10-14 mar.

When not empty, they also have to contain only node properties.
Moreover, node properties' keys can only contain non-whitespace
characters and cannot end with a plus sign (which is used for
accumulation). Value can contain anything but a newline character.

Thus, the following property drawer is invalid

  * Headline
:PROPERTIES:
:KEY: value
Some text.
:END:

Any invalid property drawer becomes de facto a regular drawer, with
PROPERTIES as its name.

Besides defining exactly the syntax of property drawers, it should also
make the property API faster in some cases. Indeed, there's no need to
search through entire (possibly huge) sections in order to find
properties attached to a headline.

However, it will break some Org documents. In particular, TODO-states
changes are usually logged before any drawer, including properties
drawers. The following function repairs them.

  (defun org-repair-property-drawers ()
Fix properties drawers in current buffer.
  Ignore non Org buffers.
(when (eq major-mode 'org-mode)
  (org-with-wide-buffer
   (goto-char (point-min))
   (let ((case-fold-search t)
 (inline-re (and (featurep 'org-inlinetask)
 (concat (org-inlinetask-outline-regexp)
 END[ \t]*$
 (org-map-entries
  (lambda ()
(unless (and inline-re (org-looking-at-p inline-re))
  (save-excursion
(let ((end (save-excursion (outline-next-heading) (point
  (forward-line)
  (when (org-looking-at-p org-planning-line-re) (forward-line))
  (when (and ( (point) end)
 (not (org-looking-at-p org-property-drawer-re))
 (save-excursion
   (re-search-forward org-property-drawer-re end 
t)))
(insert (delete-and-extract-region
 (match-beginning 0)
 (min (1+ (match-end 0)) end)))
(unless (bolp) (insert \n

Internally, changes are somewhat invasive, as they include a rewrite of
almost all the property API. They also alter clocking, tags, todo
keywords, logging, initialization, hopefully in an invisible manner.

I pushed a new branch, top-properties in the repository for code
review and testing. It includes unit tests, documentation and an
ORG-NEWS entry.

Feedback welcome.


Regards,

-- 
Nicolas Goaziou0x80A93738



Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Andreas Leha
Hi Nicolas,

My only 'concern' is that it looks awkward or at least unfamiliar when the
property drawer is closed (which it is always in my documents).

I guess than it would change from

*** Call XXX
:PROPERTIES:...
2014-10-16 Thu 13:00-14:00

to

*** Call XXX
2014-10-16 Thu 13:00-14:00
:PROPERTIES:...

which has a folded item 'in the middle of text' rather than right below the
heading.

I'll get used to that, I guess.

Regards,
Andreas





Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Hello,

 As discussed previously, I would like to modify property drawers syntax.
 The change is simple: they must be located right after a headline and
 its planning line, if any.  Therefore the following cases are valid

   * Headline
 :PROPERTIES:
 :KEY: value
 :END:

   * Headline
 SCHEDULED: 2014-10-14 mar.
 :PROPERTIES:
 :KEY: value
 :END:

 but, in the following case, the scheduled keyword will not be recognized

   * Headline
 :PROPERTIES:
 :KEY: value
 :END:
 SCHEDULED: 2014-10-14 mar.

 When not empty, they also have to contain only node properties.
 Moreover, node properties' keys can only contain non-whitespace
 characters and cannot end with a plus sign (which is used for
 accumulation). Value can contain anything but a newline character.

 Thus, the following property drawer is invalid

   * Headline
 :PROPERTIES:
 :KEY: value
 Some text.
 :END:

 Any invalid property drawer becomes de facto a regular drawer, with
 PROPERTIES as its name.

 Besides defining exactly the syntax of property drawers, it should also
 make the property API faster in some cases. Indeed, there's no need to
 search through entire (possibly huge) sections in order to find
 properties attached to a headline.

 However, it will break some Org documents. In particular, TODO-states
 changes are usually logged before any drawer, including properties
 drawers. The following function repairs them.

   (defun org-repair-property-drawers ()
 Fix properties drawers in current buffer.
   Ignore non Org buffers.
 (when (eq major-mode 'org-mode)
   (org-with-wide-buffer
(goto-char (point-min))
(let ((case-fold-search t)
  (inline-re (and (featurep 'org-inlinetask)
  (concat (org-inlinetask-outline-regexp)
  END[ \t]*$
  (org-map-entries
   (lambda ()
 (unless (and inline-re (org-looking-at-p inline-re))
   (save-excursion
 (let ((end (save-excursion (outline-next-heading) (point
   (forward-line)
   (when (org-looking-at-p org-planning-line-re) 
 (forward-line))
   (when (and ( (point) end)
  (not (org-looking-at-p org-property-drawer-re))
  (save-excursion
(re-search-forward org-property-drawer-re end 
 t)))
 (insert (delete-and-extract-region
  (match-beginning 0)
  (min (1+ (match-end 0)) end)))
 (unless (bolp) (insert \n

 Internally, changes are somewhat invasive, as they include a rewrite of
 almost all the property API. They also alter clocking, tags, todo
 keywords, logging, initialization, hopefully in an invisible manner.

 I pushed a new branch, top-properties in the repository for code
 review and testing. It includes unit tests, documentation and an
 ORG-NEWS entry.

 Feedback welcome.


 Regards,




Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 My only 'concern' is that it looks awkward or at least unfamiliar when the
 property drawer is closed (which it is always in my documents).

 I guess than it would change from

 *** Call XXX
 :PROPERTIES:...
 2014-10-16 Thu 13:00-14:00

 to

 *** Call XXX
 2014-10-16 Thu 13:00-14:00
 :PROPERTIES:...

No it wouldn't. PROPERTIES must be right after the deadline. 2014-10-16
Thu 13:00-14:00 is a mere timestamp, not a planning info line (with
SCHEDULED, DEADLINE, CLOSED keywords).

The second case is not a property drawer.


Regards,

-- 
Nicolas Goaziou



[O] etc/ORG-NEWS not updated for one year

2014-10-14 Thread Glenn Morris

etc/ORG-NEWS in emacs-24 has not been updated for ~ one year.

If you are going to update it, please do so before thie Friday.



Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Eric Abrahamsen
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 As discussed previously, I would like to modify property drawers syntax.
 The change is simple: they must be located right after a headline and
 its planning line, if any.  Therefore the following cases are valid

   * Headline
 :PROPERTIES:
 :KEY: value
 :END:

   * Headline
 SCHEDULED: 2014-10-14 mar.
 :PROPERTIES:
 :KEY: value
 :END:

 but, in the following case, the scheduled keyword will not be recognized

   * Headline
 :PROPERTIES:
 :KEY: value
 :END:
 SCHEDULED: 2014-10-14 mar.

 When not empty, they also have to contain only node properties.
 Moreover, node properties' keys can only contain non-whitespace
 characters and cannot end with a plus sign (which is used for
 accumulation). Value can contain anything but a newline character.

 Thus, the following property drawer is invalid

   * Headline
 :PROPERTIES:
 :KEY: value
 Some text.
 :END:

 Any invalid property drawer becomes de facto a regular drawer, with
 PROPERTIES as its name.

 Besides defining exactly the syntax of property drawers, it should also
 make the property API faster in some cases. Indeed, there's no need to
 search through entire (possibly huge) sections in order to find
 properties attached to a headline.

 However, it will break some Org documents. In particular, TODO-states
 changes are usually logged before any drawer, including properties
 drawers. The following function repairs them.

   (defun org-repair-property-drawers ()
 Fix properties drawers in current buffer.
   Ignore non Org buffers.
 (when (eq major-mode 'org-mode)
   (org-with-wide-buffer
(goto-char (point-min))
(let ((case-fold-search t)
  (inline-re (and (featurep 'org-inlinetask)
  (concat (org-inlinetask-outline-regexp)
  END[ \t]*$
  (org-map-entries
   (lambda ()
 (unless (and inline-re (org-looking-at-p inline-re))
   (save-excursion
 (let ((end (save-excursion (outline-next-heading) (point
   (forward-line)
   (when (org-looking-at-p org-planning-line-re) 
 (forward-line))
   (when (and ( (point) end)
  (not (org-looking-at-p org-property-drawer-re))
  (save-excursion
(re-search-forward org-property-drawer-re end 
 t)))
 (insert (delete-and-extract-region
  (match-beginning 0)
  (min (1+ (match-end 0)) end)))
 (unless (bolp) (insert \n

 Internally, changes are somewhat invasive, as they include a rewrite of
 almost all the property API. They also alter clocking, tags, todo
 keywords, logging, initialization, hopefully in an invisible manner.

 I pushed a new branch, top-properties in the repository for code
 review and testing. It includes unit tests, documentation and an
 ORG-NEWS entry.

Sounds like fun! Here's maybe a bug. In this test case:

* Here's something
** Second level
   :PROPERTIES:
   :ID:   06b778b5-72a5-45b5-aea6-2d0fef0fd24b
   :END:

Calling org-entry-put on the first heading will actually place the
property on its child. Reason being that, when org-entry-put calls
org-get-property-block, and that calls org-insert-property-drawer, point
has already been advanced to the beginning of the ** Second level
line. 

org-insert-property-drawer examines the child instead of the parent,
thinks it doesn't have to insert anything, and returns nil. Code later
in org-get-property-block locates the :END: belonging to the child,
assumes that's the end of the parent's block, and sticks the new
property there. (I found this because org-id-get-create placed new ID
values in the child's property drawer.)

That was a mouthful, but I'm not going to venture a patch at this point!

Eric




Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Michael Brand
Hi Nicolas

On Tue, Oct 14, 2014 at 4:42 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 As discussed previously, I would like to modify property drawers syntax.
 The change is simple: they must be located right after a headline and
 its planning line, if any.  Therefore the following cases are valid

   * Headline
 :PROPERTIES:
 :KEY: value
 :END:

   * Headline
 SCHEDULED: 2014-10-14 mar.
 :PROPERTIES:
 :KEY: value
 :END:

What about legacy multi line plain timestamp and planning info:

* Yearly meeting
  2013-09-22 Sun
  2014-10-19 Sun
  SCHEDULED: 2015-01-01 Thu Add next plain timestamp.
  :PROPERTIES:
  :KEY:  value
  :END:

* Yearly task
  DEADLINE: 2013-09-22 Sun -2d
  DEADLINE: 2014-10-19 Sun -2d
  SCHEDULED: 2015-01-01 Thu Add next deadline.
  :PROPERTIES:
  :KEY:  value
  :END:

Will they also become invalid as I tend to understand?

Can they be reordered as

* Yearly meeting
  SCHEDULED: 2015-01-01 Thu Add next plain timestamp.
  :PROPERTIES:
  :KEY:  value
  :END:
  2014-10-19 Sun
  2013-09-22 Sun

* Yearly task
  [It seems it can not be only reordered.]

or will they have to be transformed into sub-headings like

* Yearly meeting
  :PROPERTIES:
  :KEY:  value
  :END:
** Yearly meeting - 2013
   2013-09-22 Sun
** Yearly meeting - 2014
   2014-10-19 Sun
** Yearly meeting - Add next plain timestamp
   SCHEDULED: 2015-01-01 Thu

* Yearly task
  :PROPERTIES:
  :KEY:  value
  :END:
** Yearly task - 2013
   DEADLINE: 2013-09-22 Sun -2d
** Yearly task - 2014
   DEADLINE: 2014-10-19 Sun -2d
** Yearly task - Add next deadline
   SCHEDULED: 2015-01-01 Thu

?

Michael



Re: [O] [ob-R] table variable passing broken

2014-10-14 Thread Charles Berry
Andreas Leha andreas.leha at med.uni-goettingen.de writes:

 
 Hi all,
 
 There seems to be a bug in table passing as variables now using the
 tangle-friendly version of passing variables.
 
 Here is an example (I get an error also with emacs -Q):
 
 --8---cut here---start-8---
 * test
 #+name: testtab
 | variable  | display   | unit  |
 |---+---+---|
 | num_cells | Number of Cells in Well   |   |
 | cell_area | Cell Area | μm²   |
 | nucleus_area  | Nucleus Area  | μm²   |
 | roundness | Cell Roundness|   |
 | ratio_w2l | Cell Width to Length Ratio|   |
 | inten_nuc_dapi_median | Intensity Nucleus DAPI Median |   |
 | dapi_median   | Intensity Nucleus DAPI Median |   |
 | edu_median| Intensity edu Median  |   |
 | oct4_median   | Intensity oct4 Median |   |
 | clump_size| Clump Size| cells |
 | short_name| Cell Line |   |
 | p_col | Column|   |
 | batch | Batch |   |
 | concentration | Fibronectin Concentration | ugml  |
 | Residual  | Residual  |   |
 | evaluation_guid   | Plate |   |
 | donor | Genotype  |   |
 
 #+BEGIN_SRC R :session *test* :var test=testtab
   test
 #+END_SRC
 
 #+RESULTS:
 --8---cut here---end---8---
 
 I see this in my R session:
 
 --8---cut here---start-8---
 Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, 
 na.strings,  (from
 testorg.org!917613Wp#22) : 
   line 17 did not have 3 elements
 --8---cut here---end---8---
 

I think this is the wrong diagnosis.

Did you actually revert to the earlier version of ob-R.el to confirm that 
this would have run correctly? 

The reason I ask is that I just tried this with org-babel-R-assign-elisp
from 

  org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el

and got the same error. Note this:

--8---cut here---start-8---

#+name: testtab2
| variable | display  | unit |
|--+--+--|
| donor| Genotype |  |

  
#+BEGIN_SRC emacs-lisp :var test=testtab2
(orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field))
#+END_SRC

#+RESULTS:
: donor   Genotype


#+BEGIN_SRC emacs-lisp :var value=testtab2
;; from org-babel-R-assign-elisp
(mapcar 'length (org-remove-if-not 'sequencep value))
#+END_SRC

#+RESULTS:
| 3 |

--8---cut here---end---8---

In particular, the empty table cells are omitted even though 

`value' or `test' has all lengths as 3. This results in 
calling read.table ( ..., fill=FALSE) implicitly.

Not sure if the fix is to retool org-babel-R-assign-elisp or something
in org-table.el.

HTH,

Chuck




Re: [O] etc/ORG-NEWS not updated for one year

2014-10-14 Thread Bastien
Glenn Morris r...@gnu.org writes:

 etc/ORG-NEWS in emacs-24 has not been updated for ~ one year.

 If you are going to update it, please do so before thie Friday.

I will have a look, thanks.

There has been no major release since one year, so don't expect
major updates.

-- 
 Bastien



Re: [O] Math formatting in HTML export - The Org Manual

2014-10-14 Thread Joseph Vidal-Rosset
Thanks Eric.

I have tested this solution that works with imagemagick and html export. I
have added these lines in my init.el :

; Include the latex-exporter
(require 'ox-latex)
;; Add minted to the defaults packages to include when exporting.
;(add-to-list 'org-latex-packages-alist '( minted))
;; Tell the latex export to use the minted package for source
;; code coloration.
(setq org-latex-listings 'minted)
;; Let the exporter use the -shell-escape option to let latex
;; execute external programs.
;; This obviously and can be dangerous to activate!
(setq org-latex-pdf-process
  '(xelatex -shell-escape -interaction nonstopmode -output-directory
%o %f))

and it works.

But now it does not work in my Gnus if I want to include some png images of
proofs... I have to deleted these dangerous lines...

I do not understand why I need minted and shell-escape...

Best wishes

Jo.


2014-10-14 9:25 GMT+02:00 Eric S Fraga e.fr...@ucl.ac.uk:

 Have a look at the following variable and note the SNIPPET argument:

 ,[ C-h v org-latex-packages-alist RET ]
 | org-latex-packages-alist is a variable defined in `org.el'.
 | Its value is (( xcolor)
 |  ( tikz)
 |  ( listings)
 |  (version=3 mhchem)
 |  ( amsmath t))
 |
 | Original value was nil
 |
 | Documentation:
 | Alist of packages to be inserted in every LaTeX header.
 |
 | These will be inserted after `org-latex-default-packages-alist'.
 | Each element is either a cell or a string.
 |
 | A cell is of the format:
 |
 | (options package SNIPPET-FLAG)
 |
 | SNIPPET-FLAG, when non-nil, indicates that this package is also
 | needed when turning LaTeX snippets into images for inclusion into
 | non-LaTeX output.
 |
 | A string will be inserted as-is in the header of the document.
 |
 | Make sure that you only list packages here which:
 |
 |   - you want in every file;
 |   - do not conflict with the setup in `org-format-latex-header';
 |   - do not conflict with the default packages in
 | `org-latex-default-packages-alist'.
 |
 | You can customize this variable.
 `


 --
 Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)



Re: [O] Math formatting in HTML export - The Org Manual

2014-10-14 Thread Nick Dokos
Joseph Vidal-Rosset joseph.vidal.ros...@gmail.com writes:

 Thanks Eric.

 I have tested this solution that works with imagemagick and html export. I 
 have added these lines in my init.el :

 ; Include the latex-exporter
 (require 'ox-latex)
 ;; Add minted to the defaults packages to include when exporting.
 ;(add-to-list 'org-latex-packages-alist '( minted))
 ;; Tell the latex export to use the minted package for source
 ;; code coloration.
 (setq org-latex-listings 'minted)
 ;; Let the exporter use the -shell-escape option to let latex
 ;; execute external programs.
 ;; This obviously and can be dangerous to activate!
 (setq org-latex-pdf-process
   '(xelatex -shell-escape -interaction nonstopmode -output-directory %o 
 %f))

 and it works.

 But now it does not work in my Gnus if I want to include some png
 images of proofs... I have to deleted these dangerous lines...

 I do not understand why I need minted and shell-escape...


I don't know why you need minted (I have not followed the conversation),
but to use minted you *need* -shell-escape: minted requires running an
external program (pygments), but tex does not like doing that for
security reasons - the -shell-escape option gives tex permission to run
such an external program.

Nick




[O] [PATCH] contrib/lisp/org-velocity: Fix failure for big window

2014-10-14 Thread Marco Wahl
Hi list, hi Paul,

thanks for your org-velocity contribution!  I just discovered
org-velocity and immediately liked it.

I found a bug which might not have occurred in the past since the
monitors were smaller.  The bug shows up when the number of lines of the
match window exceeds the number of available indexes (which is 61).  I
think the patch (which is just a switch from 'greater than' to 'smaller
than') in the attachment is a way to go.

Please let me know what you think.


Best regards,  Marco
-- 
http://www.wahlzone.de
GPG: 0x0A3AE6F2
From c867eda9b60736b0d3ae50d5a5f889e80cf25a81 Mon Sep 17 00:00:00 2001
From: Marco Wahl marcowahls...@gmail.com
Date: Tue, 14 Oct 2014 20:07:31 +0200
Subject: [PATCH] contrib/lisp/org-velocity: Fix failure for big window

* contrib/lisp/org-velocity.el (org-velocity-incremental-read): Reversed
  the estimation against window-height.
---
 contrib/lisp/org-velocity.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/lisp/org-velocity.el b/contrib/lisp/org-velocity.el
index 3631a59..e6788c6 100644
--- a/contrib/lisp/org-velocity.el
+++ b/contrib/lisp/org-velocity.el
@@ -671,7 +671,7 @@ Stop searching once there are more matches than can be displayed.
  ;; Truncate the index to the size of the buffer to be
  ;; displayed.
  (with-selected-window match-window
-   (if ( (window-height) (length org-velocity-index))
+   (if ( (window-height) (length org-velocity-index))
;; (subseq org-velocity-index 0 (window-height))
(let ((hints (copy-sequence org-velocity-index)))
  (setcdr (nthcdr (window-height) hints) nil)
-- 
2.1.2



Re: [O] [ob-R] table variable passing broken

2014-10-14 Thread Andreas Leha
Charles Berry ccbe...@ucsd.edu writes:
 Andreas Leha andreas.leha at med.uni-goettingen.de writes:

 
 Hi all,
 
 There seems to be a bug in table passing as variables now using the
 tangle-friendly version of passing variables.
 
 Here is an example (I get an error also with emacs -Q):
 
 --8---cut here---start-8---
 * test
 #+name: testtab
 | variable  | display   | unit  |
 |---+---+---|
 | num_cells | Number of Cells in Well   |   |
 | cell_area | Cell Area | μm²   |
 | nucleus_area  | Nucleus Area  | μm²   |
 | roundness | Cell Roundness|   |
 | ratio_w2l | Cell Width to Length Ratio|   |
 | inten_nuc_dapi_median | Intensity Nucleus DAPI Median |   |
 | dapi_median   | Intensity Nucleus DAPI Median |   |
 | edu_median| Intensity edu Median  |   |
 | oct4_median   | Intensity oct4 Median |   |
 | clump_size| Clump Size| cells |
 | short_name| Cell Line |   |
 | p_col | Column|   |
 | batch | Batch |   |
 | concentration | Fibronectin Concentration | ugml  |
 | Residual  | Residual  |   |
 | evaluation_guid   | Plate |   |
 | donor | Genotype  |   |
 
 #+BEGIN_SRC R :session *test* :var test=testtab
   test
 #+END_SRC
 
 #+RESULTS:
 --8---cut here---end---8---
 
 I see this in my R session:
 
 --8---cut here---start-8---
 Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, 
 na.strings,  (from
 testorg.org!917613Wp#22) : 
   line 17 did not have 3 elements
 --8---cut here---end---8---
 

 I think this is the wrong diagnosis.

I agree.  Saving the table as tsv (via org-table-export) results
in a file that cannot be read from R either.


 Did you actually revert to the earlier version of ob-R.el to confirm that 
 this would have run correctly? 

I did not revert.  But that org file used to work.  I won't be able
to bisect any time soon.


 The reason I ask is that I just tried this with org-babel-R-assign-elisp
 from 

   org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el

 and got the same error. Note this:


 #+name: testtab2
 | variable | display  | unit |
 |--+--+--|
 | donor| Genotype |  |

   
 #+BEGIN_SRC emacs-lisp :var test=testtab2
 (orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field))
 #+END_SRC

 #+RESULTS:
 : donor Genotype


exactly.  That also causes the org-table-export to fail.


 #+BEGIN_SRC emacs-lisp :var value=testtab2
 ;; from org-babel-R-assign-elisp
 (mapcar 'length (org-remove-if-not 'sequencep value))
 #+END_SRC

 #+RESULTS:
 | 3 |

 In particular, the empty table cells are omitted even though 

 `value' or `test' has all lengths as 3. This results in 
 calling read.table ( ..., fill=FALSE) implicitly.

 Not sure if the fix is to retool org-babel-R-assign-elisp or something
 in org-table.el.


I am the wrong person to answer that.  But it looks to me to be an
issue for org-table.el.

Thanks for your better analysis.

Regards,
Andreas




Re: [O] Math formatting in HTML export - The Org Manual

2014-10-14 Thread Eric S Fraga
On Tuesday, 14 Oct 2014 at 19:23, Joseph Vidal-Rosset wrote:

[...]

 But now it does not work in my Gnus if I want to include some png images of
 proofs... I have to deleted these dangerous lines...

Sorry, I missed this the first time around.  What does gnus have to do
with this?  You were talking about exporting to HTML but never mentioned
gnus in the original post.

If you are trying to write an html based email, you should be looking at
different functionality than exporting.  Check out org-mime-htmlize, for
instance.  Exporting creates files which reference other files (for
images).  Messages are different.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-450-gbc9a58



[O] Bug: `org-capture-templates' file+headline target does not accept string variable [8.2.10 (8.2.10-elpa @ c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)]

2014-10-14 Thread Louis Chan
Having a template inside `org-capture-templates`, which uses the
file+headline target, with a string variable as its third argument (the
node headline), makes the command `org-capture` fail (specifically, when
selecting this particular template that uses this target).
The heading I have chosen, Tasks, does exist within the file selected
within the template. When I use a variable that contains the string
Tasks, the command fails. However, when I use the literal string
Tasks instead, the command succeeds and works fine.


Emacs  : GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Package: Org-mode version 8.2.10 (8.2.10-elpa @
c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)

current state:
==
(setq
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-babel-pre-tangle-hook '(save-buffer)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-capture-templates '((t Todo entry
  (file+headline main-org-file tasks-heading)
  * TODO %?\n %i\n %a)
 )
 org-default-notes-file ~/org/main.org
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-mode-hook '(#[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook
org-show-block-all append
local]
   5]
 #[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook
org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 org-indent-mode)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-agenda-files '(~/org/main.org)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-confirm-shell-link-function 'yes-or-no-p
 )



Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 Sounds like fun! Here's maybe a bug. In this test case:

 * Here's something
 ** Second level
:PROPERTIES:
:ID:   06b778b5-72a5-45b5-aea6-2d0fef0fd24b
:END:

Good catch. Fixed, thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Michael Brand michael.ch.br...@gmail.com writes:

 What about legacy multi line plain timestamp and planning info:

 * Yearly meeting
   2013-09-22 Sun
   2014-10-19 Sun
   SCHEDULED: 2015-01-01 Thu Add next plain timestamp.
   :PROPERTIES:
   :KEY:  value
   :END:

This is invalid, and has been so for a long time. Quoting first footnote
in (info (org) Inserting deadline/schedule):

  The ‘SCHEDULED’ and ‘DEADLINE’ dates are inserted on the line right
  below the headline. Don’t put any text between this line and the
  headline.

This footnote was inserted in c431fef47a7cbcc6ea79e3a945bc22cca4b4be96,
which is dating back from march 2011.

 * Yearly task
   DEADLINE: 2013-09-22 Sun -2d
   DEADLINE: 2014-10-19 Sun -2d
   SCHEDULED: 2015-01-01 Thu Add next deadline.
   :PROPERTIES:
   :KEY:  value
   :END:

This is also invalid, per the footnote above. Also, you cannot have some
text on the planning line.

 Will they also become invalid as I tend to understand?

They are already. My proposal doesn't change anything about it.

 Can they be reordered as

 * Yearly meeting
   SCHEDULED: 2015-01-01 Thu Add next plain timestamp.
   :PROPERTIES:
   :KEY:  value
   :END:
   2014-10-19 Sun
   2013-09-22 Sun

If you remove Add next plain timestamp., this is perfectly valid.

  * Yearly meeting
SCHEDULED: 2015-01-01 Thu
:PROPERTIES:
:KEY:  value
:END:
2014-10-19 Sun
2013-09-22 Sun

 or will they have to be transformed into sub-headings like

 * Yearly meeting
   :PROPERTIES:
   :KEY:  value
   :END:
 ** Yearly meeting - 2013
2013-09-22 Sun
 ** Yearly meeting - 2014
2014-10-19 Sun
 ** Yearly meeting - Add next plain timestamp
SCHEDULED: 2015-01-01 Thu

 * Yearly task
   :PROPERTIES:
   :KEY:  value
   :END:
 ** Yearly task - 2013
DEADLINE: 2013-09-22 Sun -2d
 ** Yearly task - 2014
DEADLINE: 2014-10-19 Sun -2d
 ** Yearly task - Add next deadline
SCHEDULED: 2015-01-01 Thu

I don't understand this.

Again, there is one possible planning info line per entry. If there is
one, the property drawer has to be inserted right below it.  Otherwise,
it needs to be right after the headline itself.

This has nothing to do with plain timestamps, i.e., 2014-10-19 Sun and
2013-09-22 Sun in your example.

I hope this is clearer now.


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] org-capture-place-item better alignment for new lists.

2014-10-14 Thread Nicolas Goaziou
Hello,

Andrew Burgess andrew.burg...@embecosm.com writes:

 I've revised the patch (below) so that I now use org-indent-line to
 establish the best indentation if we're starting a new list, this has
 resulted in slightly more churn, but hopefully not too much.

Thanks. I applied it.

Note that you needed to add TINYCHANGE at the end of your patch. Since
you are close to the loc limit, you will need to sign FSF papers for
another one.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: `org-capture-templates' file+headline target does not accept string variable [8.2.10 (8.2.10-elpa @ c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)]

2014-10-14 Thread Nicolas Goaziou
Hello,

Louis Chan loui...@hacari.com writes:

 Having a template inside `org-capture-templates`, which uses the
 file+headline target, with a string variable as its third argument (the
 node headline), makes the command `org-capture` fail (specifically, when
 selecting this particular template that uses this target).
 The heading I have chosen, Tasks, does exist within the file selected
 within the template. When I use a variable that contains the string
 Tasks, the command fails. However, when I use the literal string
 Tasks instead, the command succeeds and works fine.

Nothing, in the manual or in `org-capture-templates' docstring, pretends
that variables are supported there. You are expected to provide
a string. I don't see any bug here.


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] key-binding for all plotting styles

2014-10-14 Thread Thierry Banel
Here is the updated patch.

To see the result:
- cd to org-mode tree root
- make info
- launch Emacs
- C-u C-h i doc/org RET
- search for Org-Plot chapter

Regards
Thierry


Le 13/10/2014 18:24, Nicolas Goaziou a écrit :

 Some comments follow.
 ...

 It should be

   @kbd{M-x org-plot/gnuplot @key{RET}}
   @kbd{M-x orgtbl-ascii-plot @key{RET}}
   @samp{too small} or @samp{too large}.
   @samp{12}
Fixed

 Note there is also the macro

   @orgcmd{C-c  g,org-plot/gnuplot}
This macro is used as bullet items in a @table
I cannot use it in the middle of a text.

 BTW is-it ASCII-art or ascii-art?
Changed to capitals.



From 5168483137640a896501c88740052fe5112bed54 Mon Sep 17 00:00:00 2001
From: Thierry Banel tbanelweb...@free.fr
Date: Tue, 14 Oct 2014 22:34:54 +0200
Subject: [PATCH] Document ASCII-art plot

* doc/org.texi: Extend Gnuplot chapter to ASCII-art plotting.
* etc/ORG-NEWS: Document ASCII-art plot.
---
 doc/org.texi | 57 -
 etc/ORG-NEWS |  2 ++
 2 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 05df0eb..767fa1a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3258,11 +3258,17 @@ functions.
 @cindex plot tables using Gnuplot
 @cindex #+PLOT
 
-Org-Plot can produce 2D and 3D graphs of information stored in org tables
-using @file{Gnuplot} @uref{http://www.gnuplot.info/} and @file{gnuplot-mode}
+Org-Plot can produce graphs of information stored in org tables, either
+graphically or in ASCII-art.
+
+@subheading Graphical plots using @file{Gnuplot}
+
+Org-Plot produces 2D and 3D graphs using @file{Gnuplot}
+@uref{http://www.gnuplot.info/} and @file{gnuplot-mode}
 @uref{http://xafs.org/BruceRavel/GnuplotMode}.  To see this in action, ensure
 that you have both Gnuplot and Gnuplot mode installed on your system, then
-call @code{org-plot/gnuplot} on the following table.
+call @kbd{C-c  g} or @kbd{M-x org-plot/gnuplot @key{RET}} on the following
+table.
 
 @example
 @group
@@ -3280,8 +3286,8 @@ call @code{org-plot/gnuplot} on the following table.
 Notice that Org Plot is smart enough to apply the table's headers as labels.
 Further control over the labels, type, content, and appearance of plots can
 be exercised through the @code{#+PLOT:} lines preceding a table.  See below
-for a complete list of Org-plot options.  For more information and examples
-see the Org-plot tutorial at
+for a complete list of Org-plot options.  The @code{#+PLOT:} lines are
+optional.  For more information and examples see the Org-plot tutorial at
 @uref{http://orgmode.org/worg/org-tutorials/org-plot.html}.
 
 @subsubheading Plot Options
@@ -3337,6 +3343,47 @@ may still want to specify the plot type, as that can impact the content of
 the data file.
 @end table
 
+@subheading ASCII bar plots
+
+While the cursor is on a column, typing @kbd{C-c \ a} or
+@kbd{M-x orgtbl-ascii-plot @key{RET}} create a new column containing an
+ASCII-art bars plot.  The plot is implemented through a regular column
+formula.  When the source column changes, the bar plot may be updated by
+refreshing the table, for example typing @kbd{C-u C-c *}.
+
+@example
+@group
+| Sede  | Max cites |  |
+|---+---+--|
+| Chile |257.72 |  |
+| Leeds |165.77 | WWWh |
+| Sao Paolo | 71.00 | WWW; |
+| Stockholm |134.19 | WW:  |
+| Morelia   |257.56 | WWWH |
+| Rochefourchat |  0.00 |  |
+#+TBLFM: $3='(orgtbl-ascii-draw $2 0.0 257.72 12)
+@end group
+@end example
+
+The formula is an elisp call:
+@lisp
+(orgtbl-ascii-draw COLUMN MIN MAX WIDTH)
+@end lisp
+
+@table @code
+@item COLUMN
+  is a reference to the source column.
+
+@item MIN MAX
+  are the minimal and maximal values displayed.  Sources values
+  outside this range are displayed as @samp{too small}
+  or @samp{too large}.
+
+@item WIDTH
+  is the width in characters of the bar-plot.  It defaults to @samp{12}.
+
+@end table
+
 @node Hyperlinks
 @chapter Hyperlinks
 @cindex hyperlinks
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 0a5af68..e94dec6 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -96,6 +96,8 @@ would throw an error. A new variable
 ~org-table-formula-create-columns~ was added to adjust this
 behavior. It is now possible to silently add new columns, to do so
 with a warning or to explicitly ask the user each time.
+*** ASCII plot
+Ability to plot values in a column through ASCII-art bars.
 ** Miscellaneous
 *** File names in links accept are now compatible with URI syntax
 Absolute file names can now start with =///= in addition to =/=. E.g.,
-- 
1.9.1



Re: [O] [PATCH] key-binding for all plotting styles

2014-10-14 Thread Nicolas Goaziou
Hello,

Thierry Banel tbanelweb...@free.fr writes:

 Here is the updated patch.

[...]

 BTW is-it ASCII-art or ascii-art?
 Changed to capitals.
__ _  _   
   / \   _ __  _ __ | (_) ___  __| |  
  / _ \ | '_ \| '_ \| | |/ _ \/ _` |  
 / ___ \| |_) | |_) | | |  __/ (_| |_ 
/_/   \_\ .__/| .__/|_|_|\___|\__,_(_)
|_|   |_| 


Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] key-binding for all plotting styles

2014-10-14 Thread Thierry Banel
Le 14/10/2014 23:08, Nicolas Goaziou a écrit :
 __ _  _   
/ \   _ __  _ __ | (_) ___  __| |  
   / _ \ | '_ \| '_ \| | |/ _ \/ _` |  
  / ___ \| |_) | |_) | | |  __/ (_| |_ 
 /_/   \_\ .__/| .__/|_|_|\___|\__,_(_)
 |_|   |_| 



_
  _(\
 (_)\ \
 \ \
  ) )
 _ / /
 (_)/ /
   (_/




Re: [O] org-export-format-source-code-or-example: End of Buffer

2014-10-14 Thread Mishal Awadah
Hi Bastien,

According to Andreas, this is an org-mode issue:
https://answers.launchpad.net/python-mode/+question/248031

Thanks,
Mish

On Fri, Apr 18, 2014 at 7:57 AM, Bastien b...@gnu.org wrote:

 Hi Mishal,

 Mishal Awadah a.mam...@gmail.com writes:

  I added the sample code that generates the error for me on
 
 http://stackoverflow.com/questions/22565379/emacs-org-mode-python-source-blocks-dont-export-with-python-mode-el

 I see Andreas made this python-mode bug report for it:
 https://bugs.launchpad.net/python-mode/+bug/1295825

 So I hope this will be sorted there.

 Best,

 --
  Bastien



[O] How to change a link?

2014-10-14 Thread Marcin Borkowski
Hi list,

assume that I have a link object (e.g., I'm in the ellipsis part of
this:

(org-element-map (org-element-parse-buffer 'object) 'link
  (lambda (elt) ... ))

What I want to do is this:
1. check whether it is an internal link, and
2. if it is, change it so that it points to the analogous place in
another file.

Any hints about how to do these things?

(The rationale is that I'm writing a function which splits a single Org
file into a bunch of smaller ones, and I want to preserve links.)

Best,

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



Re: [O] Sharing: Agenda skip function to remove future-scheduled items

2014-10-14 Thread James Harkins
Sebastien Vauban sva-news@... writes:

 I use the following (tricky) settings, which should 
do what you have in
 mind, if I'm not mistaken:
 
 #+begin_src emacs-lisp
   ;; Don't show scheduled entries in the global 
`todo' list.
   (setq org-agenda-todo-ignore-scheduled 'future)
 
   ;; Don't show entries scheduled in the future in the 
global
   ;; `todo' list (until they are within the warning 
period).
   (setq org-agenda-todo-ignore-deadlines 'near)
 
   ;; Honor `todo' list `org-agenda-todo-ignore...' 
options also
   ;; in the `tags-todo' list.
   (setq org-agenda-tags-todo-honor-ignore-options 
t)
 #+end_src

Interesting. How would I apply those settings to only 
one custom agenda command, while leaving the 
others with the default behavior of showing future 
schedules?

hjh




Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Eric Abrahamsen
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 As discussed previously, I would like to modify property drawers syntax.
 The change is simple: they must be located right after a headline and
 its planning line, if any.  Therefore the following cases are valid

Is there any chance this has messed up file-local #+TODO: keyword
definitions? Specifically, it looks like, if there are more than one of
those options lines, they aren't parsed or applied in this test branch.

This works in both master and top-properties:

#+TODO: FIX | BREAK

* FIX My car


This works in master but *not* top-properties:

#+TODO: FIX | BREAK
#+TODO: EMAIL | REPLY

* FIX My car
* EMAIL My dad


In the second case, none of the TODO keywords are recognized as valid
keywords. The lines don't appear to be parsed at all -- usually lines
like that override the globally-defined keyword list, but in this case
the global definitions are in effect.

The docs still say multiple lines are permitted...

Thanks,
Eric




Re: [O] Math formatting in HTML export - The Org Manual

2014-10-14 Thread Joseph Vidal-Rosset
2014-10-14 19:51 GMT+02:00 Nick Dokos ndo...@gmail.com:

 I don't know why you need minted (I have not followed the conversation),
 but to use minted you *need* -shell-escape: minted requires running an
 external program (pygments), but tex does not like doing that for
 security reasons - the -shell-escape option gives tex permission to run
 such an external program.



Thanks for this explanatio Nick. I need minted, strangely, in order to get
png images in html export. If I try to avoid the use of minted, the png
images are corrupted...

Best wishes

Jo.