Re: [O] Launching Emacs org-mode commands from Windows 7 command line?

[Martin Beck]

Andy Moreton  gmail.com> writes:
> > I tried like that:
> > emacsclient --eval '(org-search-view nil "search string")'
> > but with no success.
> > In the command line I get the error message:
> > *ERROR*: End of file during parsing
> 
> cmd.exe has strange quoting rules. Does this work for you ?
> 
> emacsclient --eval "(org-search-view nil """search string""")"
> 

Thanks a lot, Andy!
That does the trick!

Martin

Re: [O] Fontification of org code block not printed

[Francesco Pizzolante]

Hi Bastien,

> This is the fault of Org.
>
> I fixed this in master by removing `org-block-background'.
>
> This is radical but I think this is really better:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=f8b42e8
>
> Sebastien, let's think about another way of getting a
> color for the background, if that's really needed.

I have to say that I'm surprised about the way this issue has been
fixed. Let me tell you why.

1) The fix 'simply' removes a useful Org functionality, which I use for
   3 years now, without providing any alternative.

2) The first approach would have been to try to fix the issue instead of
   completely removing the functionality which, as I already said, is
   present since a long time.

3) A possible workaround, without completely removing
   org-block-background, would have been to add a variable in order for
   people to activate (or de-activate) it and use it (or avoid the
   issue).

4) To conclude, according to Stefan Monnier (see his answser from
   2014-07-29 11:38), the issue is due to a bug in ps-def.el and not in
   Org:

> It's a problem in the ps-def.el code which handles the `face' property
> in a "naive" way: it fails to merge the various active face properties
> (from the various overlays and the text-property).

Could you, then, put org-block-background back and let the fix be done
in Emacs and not in Org?

Thanks a lot.

Regards,
 Francesco

Re: [O] [POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

> I didn't read the other thread is details, but it seems the most
> sensible thing to do is alter the org fill function(s).  These seems
> to rely on org-element, though, and I'm guessing that is why a syntax
> change is necessary, yes?

I would be perfectly happy with this behavior. Can't comment on
implementation aspects.

Regards,
Federico

Re: [O] Bug: org src block folds partially [8.2.6 (8.2.6-67-g9e09b2-elpa @ c:/Users/andrea/AppData/Roaming/.emacs.d/elpa/org-20140602/)]

[Nicolas Goaziou]

Hello,

Andrea Rossetti  writes:

> When I:
>
>   - create a "BEGIN_SRC org" block (let's call it "the external
> BEGIN_SRC")
>   - hit C-c ' to edit its contents
>   - create two consecutive, non-nested "BEGIN_SRC org" blocks
> (let's call them "the internal BEGIN_SRCs")
>   - hit C-c ' to return back to the main org buffer
>   - hit TAB on the external BEGIN_SRC to fold the whole block
>
> then the folding happens only for the first internal BEGIN_SRC block.
> Tentative guess: I suppose "#+END_SRC" is used as a regexp by the fold
> procedure, while something like "[^,]#+END_SRC" could be more
> appropriate.

This should be fixed (along with other issues in the same function).
Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: pdf page numbers in links are ignored when exporting to latex [8.2.7b (8.2.7b-13-gd8a0ee-elpa @ /home/moritz/.emacs.d/elpa/org-20140728/)]

[Nicolas Goaziou]

Hello,

Moritz Kiefer  writes:

> This is my first attempt at elisp so it's probably terrible code

It's not. Thanks for the patch. Some comments follow.

> * lisp/ox-latex.el (org-latex--inline-image): Use page
> number (:search-option) of pdf links as page option in includegraphics

Missing full stop.

You also need to add "TINYCHANGE" on a line below if you don't have
signed FSF papers yet.

> ---
>  lisp/ox-latex.el | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index ceea302..edbde70 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -1861,6 +1861,10 @@ used as a communication channel."
>   (setq options (concat options ",width=" width)))
>(when (org-string-nw-p height)
>   (setq options (concat options ",height=" height)))
> +  (when (and (equal filetype "pdf")
> + (string-match "\\`[0-9]+\\'" (org-element-property 
> :search-option link))
> + (not (string-match "page=" options)))
> + (setq options (concat options ",page=" (org-element-property 
> :search-option link

I suggest to let-bind SEARCH-OPTION instead of calling
`org-element-property' twice. Also, it's better to use
`org-string-match-p' instead of `string-match' since you don't use
match-data anyway. Eventually, you need to check if SEARCH-OPTION is
non-nil, as (string-match REGEXP nil) throws an error.

  (let ((search-option (org-element-property :search-option link)))
(when (and search-option
   (equal filetype "pdf")
   (org-string-match-p "\\`[0-9]+\\'" search-option)
   ...)
  ...))


Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [RFC] Rewrite `org-entry-properties' using parser

[Bastien]

Hi Thorsten,

Thorsten Jolitz  writes:

> here is my first take of rewriting `org-entry-properties'.

I didn't take the time to closely look at the change, but thanks
for working on this.

My main concern with anything that touches `org-entry-properties'
is whether agenda generation is affected in terms of performances.
Any change here needs to check this very carefully, because we
cannot affort to exchange speed against clarity (sadly enough.)

If you can explore this, that'd be great.

-- 
 Bastien

Re: [O] proposal to make C-c C-c not remove latex overlays

[Bastien]

Hi Charles,

Charles Berry  writes:

> The docstring for `org-preview-latex-fragment' still says:
>
> "The images can be removed again with \\[org-ctrl-c-ctrl-c]."
>
> Maybe change that to "\\[org-preview-latex-fragment]"?

Fixed, thanks.  `org-preview-latex-fragment' is now named
`org-toggle-latex-fragment'.

-- 
 Bastien

Re: [O] [bug, beamer] Frame parameters taken from example code block

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> A better place would be the line below planning info, if any, or below
> the headline otherwise.

Yes, exactly.

-- 
 Bastien

Re: [O] [babel][PATCHES] exporting inline source code

[Nicolas Berthier]

Nicolas Goaziou wrote:

> Hello,
>
> Nicolas Berthier  writes:
>
>> In any case, as advised earlier in the discussion, I updated one patch
>> to integrate new tests for the new feature. I also slightly simplified
>> the HTML export patch to avoid useless display attributes.
>
> Thank you for this nice patch. Some comments follow.
>
>> +   "\\(?:^\\|[^-[:alnum:]]\\)\\(src_\\([^ \f\t\n\r\v\\[]+\\)"
>
> I think "[^ \f\t\n\r\v[]" is enough.

Indeed.  I fixed it in the new attached patch.  Thanks.

As for the definition of what enters into a language name, I suggest
leaving it for a subsequent modification as it's not the intended goal
of this patch.

>> +(defcustom org-babel-exp-inline-code-template
>> +  "src_%lang[%switches%flags]{%body}"
>> +  "Template used to export the body of inline code blocks.
>> +This template may be customized to include additional information
>> +such as the code block name, or the values of particular header
>> +arguments.  The template is filled out using `org-fill-template',
>> +and the following %keys may be used.
>> +
>> + lang -- the language of the code block
>> + name -- the name of the code block
>> + body -- the body of the code block
>> + switches -- the switches associated to the code block
>> + flags - the flags passed to the code block
>> +
>> +In addition to the keys mentioned above, every header argument
>> +defined for the code block may be used as a key and will be
>> +replaced with its value."
>> +  :group 'org-babel
>> +  :type 'string)
>
> You need to add :version and :package-version values for new defcustoms.

Fixed with what I assume are the correct version numbers.  Correct me if
they are wrong.

>> +(ert-deftest ob-exp/exports-inline-code ()
>> +  (should
>> +   (string-match
>> +(replace-regexp-in-string
>> + "\\[]{" "\\(?:\\[]\\)?{" ;accept both src_sh[]{...} or src_sh{...}
>> + (regexp-quote "Here is one in the middle src_sh[]{echo 1} of a line.
>> +Here is one at the end of a line. src_sh[]{echo 2}
>> +src_sh[]{echo 3} Here is one at the beginning of a line.
>> +Here is one that is also evaluated: src_sh[]{echo 4} =4=")
>> + nil t)
>> +(org-test-at-id "cd54fc88-1b6b-45b6-8511-4d8fa7fc8076"
>> +  (org-narrow-to-subtree)
>> +  (org-test-with-expanded-babel-code (buffer-string))
>
> It is a matter of taste, but I think tests should be self-contained. In
> particular, it isn't fun debugging `org-test-at-id'. The same goes for
> other tests.

New tests in "testing/lisp/test-ob.el" are akin already existing tests
in this file that were easy to adapt.  Considering that the patch adds
mostly export-related plus minor syntactic stuff, I think testing babel
evaluation itself is not as critical as testing the babel export
functionality w.r.t the inline code export, and the org-element parser
w.r.t the new syntax.  So, I did not add self-contained tests in
"test-ob.el" itself, and concentrated on "test-ob-exp.el" and
"test-org-element.el".  Then, the new patch adds some more
self-contained tests to ease debugging simple cases, as well as basic
tests for the inline source block parser in
`test-org-element/inline-src-block-parser'.

Besides, adding new tests made me encounter two unexpected results
during export:

- First, I discovered that the data resulting from calls to
  `org-babel-parse-header-arguments' were malformed when it was called
  with strings starting with a single space (e.g., " :foo bar") as it
  led to `(intern "")' calls in this function (leading to errors in some
  other place).

  For now, I fixed it in the first patch by further extending
  `org-babel-inline-src-block-regexp' to wipe out all spaces before the
  headers matching group (as `org-babel-src-block-regexp' does), even
  though handling cases where `arg' equals "" in
  `org-babel-parse-header-arguments' may be a cleaner solution;

- Secondly, wrapping of results when exporting code with ":results code"
  switches (as in "src_emacs-lisp[:exports results :results code]{(+
  1 1)}") led to unexpected results.  I doubt writing such kind of thing
  is actually useful, but it does not seem to cost too much to handle
  simple cases anyway.  I added two new failing tests to exhibit such
  cases in the first patch, and attached a third patch fixing this
  problem.  However, I am not even sure about the results that ought to
  be expected from the export of such code blocks, and it is still easy
  to find code blocks that break it (if only by writing code printing
  newlines).

All tests pass after each patch.

>> +  (if lang
>> +  (format "%s" lang label code)
>> +  (format "\n%s" label code)
>
> LANG cannot be nil. So,
>
>   (format "%s" lang label code)
>
> is sufficient.

Done. Thanks.

>From 66f602987e6479e73e13e78235c9a7f6316e1a7d Mon Sep 17 00:00:00 2001
From: Nicolas Berthier 
Date: Fri, 13 Jun 2014 15:32:54 +0200
Subject: [PATCH 1/3] ob: Support for exporting inline source code

* lisp/ob-exp.el (org-babel-exp-inline-co

Re: [O] [RFC] Rewrite `org-entry-properties' using parser

[Thorsten Jolitz]

Bastien  writes:

Hi Bastien,

> Thorsten Jolitz  writes:
>
>> here is my first take of rewriting `org-entry-properties'.
>
> I didn't take the time to closely look at the change, but thanks
> for working on this.
>
> My main concern with anything that touches `org-entry-properties'
> is whether agenda generation is affected in terms of performances.
> Any change here needs to check this very carefully, because we
> cannot affort to exchange speed against clarity (sadly enough.)

I would guess it all depends on the speed of `org-element-at-point'
then. I can test this with very big org files later, but first I would
it to converge a bit towards a possibly acceptable version. 

E.g. when looking at the ERT tests it seems ugly and not helpfull that
values of properties like 'deadline' are returned in parse-tree format,
they should be interpreted first (but thats another function-call
affecting speed?).

Furthermore, to achieve real claritiy, the classification of properties
in Org-mode should be checked again for completeness and
consistency. E.g. the 'ID' property set by 'org-id' does not appear in
any 'org--properties' variable and thus would falsely be treated as
user/application property. Properties in 'org-special-properties' are
upcase and don't always match the names of the (downcase) properties set
by the parser. There is no variable for the class of properties that
really only serve the parser/export framework (:beg, :end, :content-beg:
etc.).


> If you can explore this, that'd be great.

As a little test I switched Agenda from day to year mode with
(uncompiled) old and new version. I checked with 

#+begin_src emacs-lisp
(symbol-file 'org-entry-properties)
#+end_src

that uncompiled versions are used, and with 

,
| C-h f org-entry-properties
`

which version is loaded. The results are *suspiciously* similar, but the
checks indicated the new version was loaded during second test.

* test-call (in agenda day-view)

#+begin_src emacs-lisp
(benchmark-run nil (org-agenda-change-time-span 'year))
#+end_src

** old (uncompiled)

(54.418716989 94 12.71853901712)

** new (uncompiled)

(53.862527422 82 12.037524198)

-- 
cheers,
Thorsten

Re: [O] [RFC] Rewrite `org-entry-properties' using parser

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  writes:

> here is my first take of rewriting `org-entry-properties'.

Interesting. A first round of comments follows.

> Implementation goals were:
>
>  1. (almost) full backward-compability. The parser upcases user
>properties, thus case-sensitivity is lost after parsing and old
>applications that rely on the difference between "foo", "Foo" and
>"FOO" as property keys will break

Case sensitivity never was a feature for properties.

>  - Are some options useless?

Yes, see below.

>  - Is property-classification consistent (e.g. "TODO" in
>`org-special-properties', but :todo-keyword and :todo-type in the
>parse-tree)?

"TODO" and :todo-keyword properties are the same.

>  - I actually reimplemented the docstring of the old function instead of
>the rather complicated code - did I get the semantics right?
>
>  - are there bugs?
>
>  - etc ...
>
> Here is an Org file with the new version of `org-entry-properties',
> helper functions and some 20 ERT-tests. Please have a look.
>
>
> * org-entry-properties
> ** new function (org.el)
>
> #+begin_src emacs-lisp
> (defun org-entry-properties (&optional pom which specific)
>   "Get all properties of the entry at point-or-marker POM.
>
> This includes the TODO keyword, the tags, time strings for
> deadline, scheduled, and clocking, and any additional properties
> defined in the entry.
>
> The return value is an alist, except if WHICH has value `parser',
> then a plist filtered for the properties set by
> `org-element-parse-headline' is returned.

Properties returned by `org-element-at-point' are not meant to be
accessed through `org-entry-properties'. You can remove this option.

>  - nil or `all' :: get all regular (non parser) properties
>
>  - `special' :: get properties that are member of
>`org-special-properties'
>
>  - `standard' :: get properties of that subclass
>
>  - `parser' :: get properties set by parser (as plist)

See above.

>  - `custom' :: get properties that are member of
>`org-custom-properties'
>
>  - `default' :: get properties that are member of
>`org-default-properties'

`org-default-properties' is a (broken) hard-coded list of properties,
only useful for completion. Since this is arbitrary, there's no reason
to check this.

>  - `document' :: get properties that are member of
>`org-element-document-properties'

The name is misleading, "document properties" are keywords (e.g.
"#+TITLE:"). You can omit this.

>  - `file' :: get properties that are member of
>`org-file-properties'
>
>  - `global' :: get properties that are member of
>`org-global-properties'
>
>  - `global-fixed' :: get properties that are member of
>`org-global-properties-fixed'

The only purpose of `org-global-properties-fixed' is to have a basis for
`org-global-properties'. You can ignore the former.

>  - `non-org' :: get properties that are not member of any of the
>preceeding classes (except `all')
>
>  - any string :: get only exactly this property
>
>  - form :: get properties string-matched by (rx-to-string form),
>with FORM being a regular expression in sexp form

Why do you impose `rx-to-string' on the user? Just ask for a regexp. If
one wants exactly a property, he will use `regexp-quote'.

> SPECIFIC can be a string, symbol or keyword, all types will be

keyword type is not needed if you don't access to parser properties.

> converted to an upcased string. It is the specific property we
> are interested in. This argument only exists for historical
> reasons and backward portability, since giving a string value to
> WHICH has the same effect as giving a value to SPECIFIC. However,
> if SPECIFIC is non-nil, it takes precedence over WHICH."
>   (setq which (or which 'all))
>   (org-with-wide-buffer
>(org-with-point-at pom

`org-with-point-at' already call `org-with-wide-buffer', so you can
remove the latter.

>  (when (and (derived-mode-p 'org-mode)
>   (ignore-errors (org-back-to-heading t)))
>(let ((elem (org-element-at-point)))
>(when (eq (car elem) 'headline)

Use `org-element-type', not `car'. Also, you need to include
`inlinetask'

  (when (memq (org-element-type elem) '(headline inlinetask))
...)

>  (let* ((specific-prop
>  (cond
>   ((or (org-string-nw-p specific)
>(org-string-nw-p which))
>(upcase
> (or (org-string-nw-p specific)
> (org-string-nw-p which
>   ((keywordp specific)
>(car (org-split-string
>  (format "%s" specific) ":")))

You can ignore `keywordp' part.

>   ((and (not (booleanp specific))
> (symbolp specific))
>(upcase (format "%s" specific)))
>   (t nil)))

This begs for refactoring. I think

  (specific-prop
   (let ((prop (or specific which)))
   

[O] Unicode (double-byte?) goofs up text table layout

[John Lusk]

Hey, org-mode crew.  Awesome app; I love it.  It's pretty much the only
thing that keeps me in emacs these days (apart from writing Python code :)
).

You probably already know about this problem, but here's a thousand words:

​
(I hope that comes through.)

I'm sorry I only have time to whine and not fix, but, hey: day job and all.

GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN
Org-mode version 8.2.5h (8.2.5h-dist @
c:/usr/local/share/emacs/site-lisp/org/)

(Re-attaching pic at full size, since I don't know what gmail is going to
do to that insertion.)

John.

Re: [O] Unicode (double-byte?) goofs up text table layout

[Grant Rettke]

Layout works for ASCII width characters

https://lists.gnu.org/archive/html/emacs-orgmode/2009-02/msg00323.html

The maintainers surely may tell you more, though.

Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Fri, Aug 1, 2014 at 8:46 AM, John Lusk  wrote:

> Hey, org-mode crew.  Awesome app; I love it.  It's pretty much the only
> thing that keeps me in emacs these days (apart from writing Python code :)
> ).
>
> You probably already know about this problem, but here's a thousand words:
>
> ​
> (I hope that comes through.)
>
> I'm sorry I only have time to whine and not fix, but, hey: day job and all.
>
> GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN
> Org-mode version 8.2.5h (8.2.5h-dist @
> c:/usr/local/share/emacs/site-lisp/org/)
>
> (Re-attaching pic at full size, since I don't know what gmail is going to
> do to that insertion.)
>
> John.
>
>

[O] How to define file-local preamble for graphviz dot?

[Vladimir Alexiev]

I have a bunch of dot settings that I want to set globally. I hacked it like 
this:

(setq va/org-dot-preamble "digraph g {
  rankdir=LR nodesep=0.2 ranksep=0.1 arrowsize=0.2
  node [fontname=courier fontsize=10 margin=\"0.02,0.01\" shape=box width=0.1 
height=0.1]
  edge [fontname=courier fontsize=8 labelfontname=courier labelfontsize=8]")

(defadvice org-babel-expand-body:dot (before add-preamble (body params) 
activate)
  "add DOT=va/org-dot-preamble as :var in params, so $dot is replaced with it"
  (setq params (cons (cons ':var (cons 'DOT va/org-dot-preamble))
 params)))

And then I start dot code blocks with "$dot", which is replaced with the above 
string:

#+begin_src dot :results silent file :file ./img/SymmetricProperty.png
$dot 
x -> y [label="q"]
y -> x [label="q" color=red]
}
#+end_src

I can override a dot param by adding a different value after the common 
inclusion $dot, e.g.:
$dot ranksep=0.7

The problem is
*** how can I make this per-file? 
Neither #+BIND nor emacs "Local Variables:" does the trick.
Bonus if I can do it per-heading :-)

dot can take these settings from the command line, eg
-G "rankdir=LR nodesep=0.2 ranksep=0.1 arrowsize=0.2"
-N "fontname=courier fontsize=10 margin=\"0.02,0.01\" shape=box width=0.1 
height=0.1"
-E "fontname=courier fontsize=8 labelfontname=courier labelfontsize=8"

So I could try to mess with the :cmdline slot of 
org-babel-default-header-args:dot ... is this evaluated locally?

Re: [O] Unicode (double-byte?) goofs up text table layout

[Eric Abrahamsen]

John Lusk  writes:

> Hey, org-mode crew.  Awesome app; I love it.  It's pretty much the
> only thing that keeps me in emacs these days (apart from writing
> Python code :) ).
>
> You probably already know about this problem, but here's a thousand
> words:
>
>
> [cid] 
> 
>
> ​
> (I hope that comes through.)

A bit of work has gone into keeping double-byte characters from messing
up Org tables, but my guess is what you've got there is just an odd-out
glyph. It looks like the, erm, carrots (I'm not a mathematician) are
getting borrowed from a different font and substituted into your
fixed-width font where they don't quite belong.

[five minutes later]

I just went and did my homework and LOGICAL OR and LOGICAL AND are
in fact single-byte characters. If they look funny, it's just because
few fixed-width fonts come with all the necessaries. I don't think
there's much way around that...

> I'm sorry I only have time to whine and not fix, but, hey: day job
> and all.
>
> GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN
> Org-mode version 8.2.5h (8.2.5h-dist @ c:/usr/local/share/emacs/
> site-lisp/org/)
>
> (Re-attaching pic at full size, since I don't know what gmail is
> going to do to that insertion.)
>
> John.

Re: [O] Release Org 8.2.7c

[SabreWolfy]

Bastien  gnu.org> writes:

> I released Org 8.2.7c.

Can someone point me to the changelog for this? Is not here[1]. Is it on
that git thing somewhere? :)

[1] http://orgmode.org/Changes.html

Re: [O] org-plus-contrib should provide org

[Vladimir Alexiev]

> > The org-plus-contrib package on http://orgmode.org/elpa/ should provide 
> > org-8.0
> Why do you think it does not?

To be frank, I'm not sure how packages declare what they provide. 
org-plus-contrib has this
(define-package "org-plus-contrib" "20140526" "Outline-based notes management 
and organizer" 'nil)

While org has that:
(define-package "org" "20140526" "Outline-based notes management and organizer" 
'nil)

All I know is that when I install something like org-reveal:

(define-package "ox-reveal" "20140409.929" "reveal.js Presentation Back-End for 
Org Export Engine" 
   '((org "8.0")) :keywords ("outlines" "hypermedia" "slideshow" 
"presentation"))

(the second line starts with the REQUIREMENTS param of define-package)

it goes and installs org, even though I have org-plus-contribs.

Re: [O] Release Org 8.2.7c

[SabreWolfy]

Bastien  gnu.org> writes:

> I released Org 8.2.7c.

Should this be available via ELPA[1]?

[1] http://orgmode.org/elpa.html

Re: [O] Unicode (double-byte?) goofs up text table layout

[John Lusk]

Yeah, constant-width font.  I tried switching to utf-16, but that didn't
help.


On Fri, Aug 1, 2014 at 12:11 PM, Grant Rettke 
wrote:

> Layout works for ASCII width characters
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2009-02/msg00323.html
>
> The maintainers surely may tell you more, though.
>
> Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
> g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
> “Wisdom begins in wonder.” --Socrates
> ((λ (x) (x x)) (λ (x) (x x)))
> “Life has become immeasurably better since I have been forced to stop
> taking it seriously.” --Thompson
>
>
> On Fri, Aug 1, 2014 at 8:46 AM, John Lusk  wrote:
>
>> Hey, org-mode crew.  Awesome app; I love it.  It's pretty much the only
>> thing that keeps me in emacs these days (apart from writing Python code :)
>> ).
>>
>> You probably already know about this problem, but here's a thousand words:
>>
>> ​
>> (I hope that comes through.)
>>
>> I'm sorry I only have time to whine and not fix, but, hey: day job and
>> all.
>>
>> GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN
>> Org-mode version 8.2.5h (8.2.5h-dist @
>> c:/usr/local/share/emacs/site-lisp/org/)
>>
>> (Re-attaching pic at full size, since I don't know what gmail is going to
>> do to that insertion.)
>>
>> John.
>>
>>
>

Re: [O] Unicode (double-byte?) goofs up text table layout

[Achim Gratz]

John Lusk writes:
> You probably already know about this problem, but here's a thousand
> words:

That has nothing to do with Org.  Your font (or any of the fallback
fonts that are tried instead) doesn't provide a single-width glyph for
the unicode codepoint you're using.  Emacs usually gets this right if
you have at least a fallback font for these glyphs that has the same
width _and_ single-width glyphs, so wither such a font is missing
completely on your system or the fontconfig is slightly messed up.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] Release Org 8.2.7c

[Nicolas Goaziou]

Hello,

SabreWolfy  writes:

> Bastien  gnu.org> writes:
>
>> I released Org 8.2.7c.
>
> Can someone point me to the changelog for this? Is not here[1]. Is it on
> that git thing somewhere? :)
>
> [1] http://orgmode.org/Changes.html

8.2.* releases are bugfixes releases. The changelog is the same as 8.2.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Rewrite `org-entry-properties' using parser

[Erik Hetzner]

At Fri, 01 Aug 2014 01:21:47 +0200,
Thorsten Jolitz wrote:
> 
> Hi List,
> 
> here is my first take of rewriting `org-entry-properties'.
> 
> The existing function predates the new parser and some Org variables,
> and thus does the parsing and the property classification itself. The
> new version leaves parsing to the parser and property classification
> (mostly) to existing Org variables, resulting in much simpler code. 
>
> […]

Hi Thorsten,

This doesn’t directly related to this work, but I have been trying to
come up with a workflow for using org-mode for research and have had
trouble with the fact that user properties cannot be multi-valued. So
if a user wants to assign subjects to an entry, they need to figure
some way to assign multiple subjects.

There are workarounds, but it would be helpful if user properties
could be multivalued. I don’t know if this is feasible given the
current codebase; when I looked into it, it seemed pretty difficult.

best, Erik

-- 
Sent from my free software system .

[O] Bug: html export of radio targets incorrect [8.2.7b (8.2.7b-1-ga5beff-elpa @ /home/vgrinshp/apps/share/emacs/24.3.50/lisp/org/)]

[Vadim Grinshpun]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.

My org document has radiotargets where one target is contained within
another as a substring. E.g., something like this:

  <<>> 
  <<>>

When I try to export via HTML (process described below),
the visible text of the links referring to these targets is mangled (as
if interpreted twice).
The resulting HTML of a radio target link to foo_bar_baz looks like this:
  foo_bar_baz
The text is, naturally, rendered as:
   foo_bar_baz

So while the link target is correct, the text of the link is not.

Please let me know what additional info is needed, if any.
-Vadim G.
vgrin...@akamai.com

Emacs  : GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2013-10-04 on gleep
Package: Org-mode version 8.2.7b (8.2.7b-1-ga5beff-elpa @ 
/home/vgrinshp/apps/share/emacs/24.3.50/lisp/org/)

current state:
==
(setq
 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-shiftleft-final-hook '(windmove-left)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-log-done t
 org-latex-format-inlinetask-function 'ignore
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-startup-folded t
 org-export-date-timestamp-format "%Y-%m-%d"
 org-agenda-custom-commands '(("P" "Printed agenda"
   ((agenda ""
 ((org-agenda-span (quote week)) 
(org-agenda-start-on-weekday nil)
  (org-agenda-repeating-timestamp-show-all t)
  (org-agenda-entry-types (quote (:timestamp 
:sexp
 )
(agenda ""
 ((org-agenda-ndays 1) 
(org-deadline-warning-days 7)
  (org-agenda-todo-keyword-format "[%s]")
  (org-agenda-scheduled-leaders (quote ("" "")))
  (org-agenda-prefix-format "%t  %s"))
 )
(todo "TODO"
 ((org-agenda-prefix-format "%T: [%s]  ")
  (org-agenda-sorting-strategy (quote (tag-up 
priority-down)))
  (org-agenda-todo-keyword-format "")
  (org-agenda-overriding-header
   "\nTasks by Context\n--\n")
  )
 )
)
   ((org-agenda-compact-blocks t) 
(org-agenda-remove-tags t))
   ("~/agenda.ps"))
  ("1" "Remaining items"
   ((agenda ""
 ((org-agenda-skip-scheduled-if-done (quote t))
  (org-agenda-start-on-weekday nil)
  (org-agenda-entry-types
   (quote (:timestamp :sexp :scheduled 
:deadline)))
  )
 )
)
   ((org-agenda-compact-blocks t)) ("~/agenda.ps"))
  )
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-todo-keyword-faces '(("TODO" :foreground "orange red" :weight bold)
  ("NEXT" :foreground "yellow" :background "blue" 
:underline "t" :weight
   bold)
  ("REVIEW" :foreground "deep sky blue" :weight bold)
  ("DONE" :foreground "pale green" :weight bold)
  ("DELEGATED" :foreground "pale green" :weight bold)
  ("CR" :foreground "orange red" :weight bold)
  ("CR:next" :foreground "yellow" :background "blue" 
:underline "t" :weight
   bold)
  ("CR:review" :foreground "deep sky blue" :weight bold)
  ("CR:integ" :foreground "darkgoldenrod2" :weight bold)
  ("CR:review2" :foreground "aquamarine" :weight bold)
  ("CR:postponed" :foreground "dark goldenro

Re: [O] Release Org 8.2.7c

[Bastien]

SabreWolfy  writes:

>> I released Org 8.2.7c.
>
> Should this be available via ELPA[1]?

It is.

-- 
 Bastien

Re: [O] Bug: pdf page numbers in links are ignored when exporting to latex [8.2.7b (8.2.7b-13-gd8a0ee-elpa @ /home/moritz/.emacs.d/elpa/org-20140728/)]

[Moritz Kiefer]

Nicolas Goaziou  writes:

> Hello,
>
> It's not. Thanks for the patch. Some comments follow.
>
Hi, tried to fix those issues.

>From 82cb7209c912798b43a91b3dde1dd4428e09580e Mon Sep 17 00:00:00 2001
From: Moritz Kiefer 
Date: Thu, 31 Jul 2014 17:45:36 +0200
Subject: [PATCH] ox-latex.el: Add page number of link when exporting to latex

* lisp/ox-latex.el (org-latex--inline-image): Use page
number (:search-option) of pdf links as page option in
includegraphics.

TINYCHANGE
---
 lisp/ox-latex.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index ceea302..dd227ab 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1861,6 +1861,12 @@ used as a communication channel."
 	(setq options (concat options ",width=" width)))
   (when (org-string-nw-p height)
 	(setq options (concat options ",height=" height)))
+  (let ((search-option (org-element-property :search-option link)))
+(when (and search-option
+   (equal filetype "pdf")
+   (string-match "\\`[0-9]+\\'" search-option)
+   (not (string-match "page=" options)))
+  (setq options (concat options ",page=" search-option
   (setq image-code
 	(format "\\includegraphics%s{%s}"
 		(cond ((not (org-string-nw-p options)) "")
-- 
2.0.3

[O] Help: Turn off CLOCK blocking

[Subhan Michael Tindall]

Is there any way to easily turn of CLOCK blocking?
Currently it appears the otherwise-valid inactive timestamp entries in a CLOCK 
line
are treated as invisible when creating agenda views, viewing in agendas, etc 
using v [
Example:
* TEST HEADLINE WORKING HERE
  :TIMELOGS:
  CLOCK: [2014-08-01 Fri 12:06]--[2014-08-02 Sat 12:09] => 24:03
  :END:
Week-agenda (W31):
Monday 28 July 2014 W31
Tuesday29 July 2014
Wednesday  30 July 2014
Thursday   31 July 2014
Friday  1 August 2014
Saturday2 August 2014
Sunday  3 August 2014

Will not be picked up in agendas even with v [

* TEST HEADLINE WORKING HERE
  :TIMELOGS:
  CLOCK: [2014-08-01 Fri 12:06]--[2014-08-02 Sat 12:09] => 24:03
  block: [2014-08-01 Fri 12:23]
  :END:

Week-agenda (W31):
Monday 28 July 2014 W31
Tuesday29 July 2014
Wednesday  30 July 2014
Thursday   31 July 2014
Friday  1 August 2014
  tmp:12:23.. [ TEST HEADLINE WORKING HERE
Saturday2 August 2014
Sunday  3 August 2014

Will show up when v [, which is the expected behavior.
Is there any configuration I'm just not finding to convince org to treat the 
clock line as a valid inactive time stamp?
I assume it is being screened out somewhere, can anybody point me at where? 
Maybe I can cobble up a toggle.
Later, all!
Subhan


Subhan Michael Tindall
Program Analyst - FamilyCare Health Plans
825 NE Multnomah St, Suite 1400; Portland OR 97232
Direct: 503-471-3127
Fax:  503-471-3177
Email:  subh...@familycareinc.org
[Email-Signature-Logos June 20143]


This message is intended for the sole use of the individual and entity to which 
it is addressed and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If you are not the intended 
addressee, nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone the 
message or any information contained in the message. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete the message.  Thank you.

[O] Cannot build documentation (release_8.3beta-155-g82b64d)

[Vicente Vera]

Hello, recently I tried to install the latest development snapshot from Git
through the following procedure, which has worked for me perfectly until
now:

- make cleanall
- make up0
- make install

When the build system gets to creating the documentation (just the info
file) these error lines appear (i'm sorry for the length) and the process
stops:

/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:16387:
Cross reference to nonexistent node `Using
 multiple #+TBLFM lines' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:16078:
Cross reference to nonexistent node `External
 links' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:15548:
Cross reference to nonexistent node `Code evaluation
 security' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:15289:
Cross reference to nonexistent node `Property
 inheritance' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:14506:
Cross reference to nonexistent node `Evaluating code
 blocks' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:14224:
Cross reference to nonexistent node `Evaluating
 code blocks' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:14219:
Cross reference to nonexistent node `Code
 evaluation security' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:14169:
Cross reference to nonexistent node `Library
 of Babel' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:13391:
Cross reference to nonexistent node `HTML
 export' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:12932:
Cross reference to nonexistent node `Evaluating
 code blocks' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:12219:
Cross reference to nonexistent node `Column width and
 alignment' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:12100:
Cross reference to nonexistent node `Configuring a
 document converter' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:11252:
Cross reference to nonexistent node `Radio
 targets' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:10788:
Cross reference to nonexistent node `Export
 settings' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:10503:
Cross reference to nonexistent node `In-buffer
 settings' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:10348:
Cross reference to nonexistent node `Literal
 examples' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:10177:
Cross reference to nonexistent node `Math formatting in
 HTML export' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:10017:
Cross reference to nonexistent node `Generating
 an index' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:9922:
Cross reference to nonexistent node `Text
 areas in HTML export' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:9850:
Cross reference to nonexistent node `Plain
 lists' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:9613:
Cross reference to nonexistent node `Document
 structure' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:8779:
Cross reference to nonexistent node `Filtering/limiting
 agenda items' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:8134:
Cross reference to nonexistent node `Property
 inheritance' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:8012:
Cross reference to nonexistent node `Agenda
 commands' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:7816:
Cross reference to nonexistent node `Agenda
 commands' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:7719:
Cross reference to nonexistent node `Matching
 tags and properties' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/org-mode/doc//org.texi:7197:
Cross reference to nonexistent node `Adding
 hyperlink types' (perhaps incorrect sectioning?).
/home/vicente/descarga/org-master-git-20140707/or

Re: [O] org-table Row Count Formula

[Michael Brand]

On Wed, Jul 30, 2014 at 2:52 AM, Eric Abrahamsen
 wrote:
> The vcount function will count the number of elements in a vector, so
> you could probably pass a range reference, like @1..@> (first row to
> last row) to vcount.

Yes.

> I think empty rows would be omitted, though.

It depends on whether the mode "E" is used or not, see
http://orgmode.org/manual/Formula-syntax-for-Calc.html

Michael

Re: [O] [PATH] Speedups to org-table-recalculate

[Michael Brand]

Hi Nathaniel

On Tue, Jul 29, 2014 at 2:03 PM, Nathaniel Flath  wrote:
> This patch speeds up org-table-recalculate by removing all 'message'
> function calls.  Additionally adds an early check for whether there are any
> formulas and only executes the rest of the function if so.

As far as I understand these `message' were added to see the progress
of a long lasting recalculation which would not be supported any more
with your patch. But I agree that it would be sufficient to report the
current field/line only every let's say one second and suppress the
others to gain speed for use cases like yours.

Michael

[O] [babel] [bug] saving moves window and point

[Samuel Wales]

to reproduce in maint:

c-c ' on a fairly large shell source block
move point someplace
c-x c-s

sometimes point moves
sometimes the position in the window recenters

it seems quite random

what i expected was no changes of anything

thanks

Re: [O] [babel] turn off code line label feature

[Samuel Wales]

when i do capture, i expect it to work the same in any buffer.  but
editing source code makes it ask me for a code line label.  this is  a
great feature, but it breaks my flow when it asks me so i want to turn
that feature off.  what is the variable to turn it off?  i want
capture to work the same in every buffer.

thanks.

Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.

[Alexis]

Gour wrote:

> Excuse me for dumb question, but is this package meant to be something
> like org-contacts NG (something which we would really like to have)?

i don't think that's a dumb question at all!

My original motivation for developing org-vcard was to create part of a
pipeline for synchronising contacts between Org and my smartphone. My
intended plan for this pipeline is:

1. Create org-vcard to at least enable easy export and import of vCard
files between my smartphone and Org.

2. Using org-vcard as a library, create org-carddav (which i hope to
start working on shortly) in order to be able to synchronise contacts
stored in Org with arbitrary CardDAV servers.

3. Using org-carddav, set up a way of synchronising my Org-based
contacts with my smartphone-based contacts.

i'm taking this approach because:

(a) The MobileOrg release process currently appears to be stalled. A few
pull requests i've submitted to the project, one of which was intended
as the first step in making MobileOrg org-contacts.el-aware, have been
accepted, but there has been no new release including these
changes/fixes.

(b) (i) i feel org-contacts.el, as it stands, is too inflexible. It's only
aware of a relatively small number of properties, and extending this
requires directly messing around in the org-contacts.el code. i feel
that this has made it difficult to expand the list of properties
available, as it basically requires everyone to agree on exactly what
properties to add, and how.

(b) (ii) Further to (b) (i), i feel people should be able to define
their own properties, in their preferred language, without having to
write code for this.

(b) (iii) More generally, previous discussions on this topic on this
list have convinced me that it's folly to expect everyone to agree on a
single style for contacts in Org, and that what is needed is a system
that can easily accommodate the development of new contact styles,
potentially allowing an ecosystem/marketplace of styles to develop, with
particularly popular styles being considered for inclusion by default in
the system.

Given all the above, yes, i would like to see org-vcard become the basis
for an "Org contacts NG" system. (Which, to answer Feng Shu's question,
would mean that the 'tree' style would be available by default in such a
system.) Whether to actually take this approach, however, is something
i'll let the community decide. :-)


Alexis.

Re: [O] proposal to have ignoreheading tags/properties

[Mark Edgington]

Hi Bastien,

I've attached a patch for ox-extra which doesn't yet include the
option for choosing specific tag names (the 'ignore' tag is currently
hard-coded).  Feel free to modify / commit it.

Regards,

Mark


On Tue, Jul 29, 2014 at 10:31 AM, Bastien  wrote:
> Hi Nicolas,
>
> Nicolas Goaziou  writes:
>
>> Filters are _not_ meant to be in core since they are hardly a generic
>> solution for a class of problem. They are entry points for user-level
>> hacking. Generic patches should operate at the parse tree level, not
>> using regexps.
>>
>> Eric's filter, like any other filter, has flaws that cannot be fixed.
>> Useful filters ought to be published in Worg, not included in core.
>
> Fair enough.
>
> Still, can someone add Eric's solution to contrib/lisp/ox-extra.el?
>
> Thanks,
>
> --
>  Bastien
From 7b60eefcb21c2a62b1ab7f248f6a0b993d89cc4d Mon Sep 17 00:00:00 2001
From: Mark Edgington 
Date: Sat, 2 Aug 2014 00:32:29 -0400
Subject: [PATCH] * ox-extra.el: add ignore-headlines filter

---
 contrib/lisp/ox-extra.el | 82 +++-
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-extra.el b/contrib/lisp/ox-extra.el
index f4f0b76..01368cb 100644
--- a/contrib/lisp/ox-extra.el
+++ b/contrib/lisp/ox-extra.el
@@ -23,6 +23,12 @@
 ;; are not part of org's core.  Call `ox-extras-activate' passing a
 ;; list of symbols naming extras, which will be installed globally in
 ;; your org session.
+;;
+;; For example, you could include the following in your .emacs file:
+;;
+;;(require 'ox-extra)
+;;(ox-extras-activate '(latex-header-blocks ignore-headlines))
+;;
 
 ;; Currently available extras:
 
@@ -35,6 +41,12 @@
 ;;   ...
 ;; #+end_latex
 
+;; - `ignore-headlines' -- allow a headline (but not its children) to
+;; be ignored.  Any headline tagged with the 'ignore' tag will be
+;; ignored (i.e. will not be included in the export), but any child
+;; headlines will not be ignored (unless explicitly tagged to be
+;; ignored), and will instead have their levels promoted by one.
+
 ;; TODO:
 ;; - add a function to org-mode-hook that looks for a ox-extras local
 ;;   variable and activates the specified extras buffer-locally
@@ -75,8 +87,76 @@
 	;; earlier in the file
 	(reverse positions)
 
+
+;; During export headlines which have the "ignore" tag are removed
+;; from the parse tree.  Their contents are retained (leading to a
+;; possibly invalid parse tree, which nevertheless appears to function
+;; correctly with most export backends) all children headlines are
+;; retained and are promoted to the level of the ignored parent
+;; headline.
+;;
+;; This makes it possible to add structure to the original Org-mode
+;; document which does not effect the exported version, such as in the
+;; following examples.
+;;
+;; Wrapping an abstract in a headline
+;;
+;; * Abstract:ignore:
+;; #+LaTeX: \begin{abstract}
+;; #+HTML: 
+;;
+;; ...
+;;
+;; #+HTML: 
+;; #+LaTeX: \end{abstract}
+;;
+;; Placing References under a headline (using ox-bibtex in contrib)
+;;
+;; * References :ignore:
+;; #+BIBLIOGRAPHY: dissertation plain
+;;
+;; Inserting an appendix for LaTeX using the appendix package.
+;;
+;; * Appendix   :ignore:
+;; #+LaTeX: \begin{appendices}
+;; ** Reproduction
+;; ...
+;; ** Definitions
+;; #+LaTeX: \end{appendices}
+;;
+(defun org-export-ignore-headlines (data backend info)
+  "Remove headlines tagged \"ignore\" retaining contents and promoting children.
+Each headline tagged \"ignore\" will be removed retaining its
+contents and promoting any children headlines to the level of the
+parent."
+  (org-element-map data 'headline
+(lambda (object)
+  (when (member "ignore" (org-element-property :tags object))
+(let ((level-top (org-element-property :level object))
+  level-diff)
+  (mapc (lambda (el)
+  ;; recursively promote all nested headlines
+  (org-element-map el 'headline
+(lambda (el)
+  (when (equal 'headline (org-element-type el))
+(unless level-diff
+  (setq level-diff (- (org-element-property :level el)
+  level-top)))
+(org-element-put-property el
+  :level (- (org-element-property :level el)
+level-diff)
+  ;; insert back into parse tree
+  (org-element-insert-before el object))
+(org-element-contents object)))
+(org-element-extract-element object)))
+info nil)
+  data)
+
+;(add-hook 'org-export-filter-parse-tree-functions 'org-export-ignore-headlines)
+
 (defconst ox-extras
-  '((latex-header-blocks org-latex-header-blocks-filter org-export-before-parsing-hook))
+  '(