Re: [O] C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords)

2011-11-01 Thread Daniel Bausch
Am Montag 31 Oktober 2011, 20:01:14 schrieb Eric Schulte:
 Daniel Bausch danielbau...@gmx.de writes:
  I did some tests with my documents and they look fine.  Thanks for your
  work.
 
 Great, good to know.
 
  (A minor remark, offtopic: If the document ends just below a source
  code block, no results are inserted when the block is executed.  You
  have to insert an additional blank line, for a result to can appear.)
 
 I can't reproduce this problem.

Ok, I played around and found that what I saw has nothing to do with a blank 
line existing or not, but only with the position of point.  What I observed 
happens if point is at the end of the #+end_src line.  If you press C-c C-c 
there then you get Local setup has been refreshed if there is a newline 
following.  If the documents ends just there, then you get org-mode 
fontification error.  In both cases no result is produced.  I think it is a 
very common case that one wants to execute a code block right after typing 
#+end_src, so that point position should belong to the code block.  If you 
move one character left, so you are between r and c, then C-c C-c works as 
expected.

If you need an example, use that

#+begin_src R
  42
#+end_src

It even does not matter, whether there is additional text following.




Re: [O] wrap long table formula

2011-11-01 Thread henry atting
Carsten Dominik carsten.domi...@gmail.com writes:

 On 31.10.2011, at 19:10, Samuel Wales wrote:

 Would a column formula work?

 Good idea!  Quite likely it would.

 - Carsten

 
 Samuel
 
 -- 
 The Kafka Pandemic: http://thekafkapandemic.blogspot.com
 ===
 Bigotry against people with serious diseases is still bigotry.

I was thinking of a column formula but have no clue if it's
possible and if so, how.

In this short example the formula's length is no problem but for a
table with 12 rows or more it certainly is; -- and currently it's the
only way I can realize it.

|   |   |
|---+---|
| 2 |   |
| 6 | 4 |
| 7 | 5 |
#+TBLFM: @3$2=vmean(@2$1..@3$1::@4$2=vmean(@2$1..@4$1


henry

-- 
http://literaturlatenight.de



Re: [O] wrap long table formula

2011-11-01 Thread Christian Moe

On 11/1/11 8:17 AM, henry atting wrote:


I was thinking of a column formula but have no clue if it's
possible and if so, how.

In this short example the formula's length is no problem but for a
table with 12 rows or more it certainly is; -- and currently it's the
only way I can realize it.

|   |   |
|---+---|
| 2 |   |
| 6 | 4 |
| 7 | 5 |
#+TBLFM: @3$2=vmean(@2$1..@3$1::@4$2=vmean(@2$1..@4$1



|   | |
|---+-|
| 2 | |
| 6 |   4 |
| 7 |   5 |
| 3 | 4.5 |
| 9 | 5.4 |
#+TBLFM: @3$2..@$2=vmean(@2$1..@0$1)

hth,
Christian



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Christian Moe

On 10/31/11 10:36 PM, Eric Schulte wrote:


4. My own idea of allowing any defined property to be passed as an
argument to src blocks (which would require some changes to how Babel
reads its :var header args).



I do see how this approach could be powerful, however I fear both the
size of the change and the potential negative consequences of combining
the property and variable name spaces.



Well, you would know better than me on both scores, so I'll stop 
pushing. Thanks for considering it.


Yours,
Christian



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Nicolas Goaziou
Hello,

Eric Schulte schulte.e...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Well, what about:

 #+property: :var foo=1
 #+property: :var bar=2
 #+property: :var baz=3
 #+property: :var qux=4

 Unfortunately this won't work, the final value of the var property
 will be qux=4 rather than foo=1, bar=2, baz=3, qux=4.

I know that it won't work, as #+begin_property didn't work before you
introduced it. The idea is to make that work instead (with or without
the colons in front of var).

 I would say that the block is defining an keyword, but yes, I suppose
 we've never had a multi-line keyword definition structure.

I differentiate keywords and blocks from their usage. As such, blocks
are not defining a keyword. They're not even in the same league.

 Along these lines I would also like to allow TBLFM lines to be broken
 over multiple lines, as I often find myself right-scrolling in a buffer
 to find equations in large spreadsheets.  I wonder if there would be a
 general solution to allow *all* #keyword+ lines to have a block
 equivalent.

The solution I implemented in my document on Org syntax is to create two
keyword's families: cumulative and dual.

Belonging to the first one means a keyword accumulates its values on
multiple calls instead of replacing them. That's how I parse
#+headers: or #+attr_latex lines, for example. The second one allows
the keyword to have a secondary, optional, value, in square brackets.
This is useful for keywords like #+results:, which can include an hash
value like #+results[hash-string]: keyword-value.

Typically, what is required here is to add #+property: to the
cumulative family. Thus,

#+property: var foo=1
#+property: var bar=2

is exactly the same as #+property: var foo=1 var bar=2.

Also, make sure var assignations accumulate too.

 I don't know how #+text: works, but with #+header: the order of the
 blocks is not important, i.e.,

 #+headers: :var a=1
 #+headers: :cache a=2

 is equal to

 #+headers: :cache a=2
 #+headers: :var a=1

 but the same is not true for

 #+PROPERTY:  var foo=1,
 #+PROPERTY+: bar=2

 and

 #+PROPERTY+: bar=2
 #+PROPERTY:  var foo=1,

Because, again, #+property+: isn't a great idea. Here, #+headers:
accumulates its values. Make the same for #+property: and we're all
set.

 It is desirable to have a logic behind syntax, and to always refer to
 it. Thus, is is desirable to separate syntax used for contents from
 syntax used for Org control. It's very different from things on
 a single line vs things on multiple lines.

 Sure, but to play devils (or my own) advocate, I would say that
 simplicity is important and blocks for multi-line content is a simpler
 rule than blocks for formatting of multi-line content, and for naming
 multi-line data, the second being the case with code and example
 blocks.

What? Blocks do not name anything. In the case of code and example
blocks, you specify Org how to format/understand the contents, like any
other block. You use #+name: to name them.

Again, the rule is simple: blocks are directly related to contents,
keywords aren't. Corollary is: no block with only options and no
contents.

 My goal here is to find the most natural solution which conforms to
 Org-modes design as well as possible, I just don't know what that
 would be...

We share the same goal.


Regards,

-- 
Nicolas Goaziou



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Nicolas Goaziou
Correcting myself,

 Typically, what is required here is to add #+property: to the
 cumulative family. Thus,

 #+property: var foo=1
 #+property: var bar=2

 is exactly the same as #+property: var foo=1 var bar=2.

 Also, make sure var assignations accumulate too.

I don't think #+property: should belong to a cumulative family of
keywords. But Babel var keyword definitely should. Thus, the idea
stays the same: on multiple var calls, accumulate values instead of
replacing them (unless, obviously, the variables has already been
assigned a value before).



[O] dependencies and schedule repeater problem

2011-11-01 Thread Sandra Snan
What I want is that if I look at my list of things to do, and I’ve
already swept the floor and marked it as done, it shouldn’t bother me
anymore for the day, but pop up the next day.
And if I’ve swept the floor, I’ll be presented with the opportunity to
also mop the floor, if it’s been a week since last time. (And I don’t
want to mop an unswept floor. And I don’t need to mop every time I
sweep.)


This is what I have now.

I’m using GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d
scroll bars) of 2010-12-11 on brahms, modified by Debian and the
version of org-mode that came with it.

* TODO mop the floor :home:
  SCHEDULED: 2011-11-01 Tue .+1w
** TODO sweep the floor
   SCHEDULED: 2011-11-01 Tue .+1d

I have a custom agenda search that hides future items.
For example, expressions like
(hh tags-todo home+SCHEDULED=\\|SCHEDULED=\today\)
deep inside org-agenda-custom-commands.

I have custom-set
 '(org-agenda-dim-blocked-tasks (quote invisible))
 '(org-enforce-todo-dependencies t)

The problem is that “sweep the floor” never gets marked done since it
has a repeater, so “mop the floor” never becomes visible.

Can I fix this problem, or can I get the desired behavior some other way?

Thank you,
Sandra

PS
“mop the floor” and “sweep the floor” are just examples and so are the
specific intervals. I have many different repeating and depending
tasks that work like this.



Re: [O] Bug: Publishing with auto-sitemap is broken [7.7 (release_7.7.497.gae02e)]

2011-11-01 Thread Nicolas Goaziou
Hello,

Bernt Hansen be...@norang.ca writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Bernt Hansen be...@norang.ca writes:

 Publishing with an automatically generated index file is broken for me.

 With org-publish-projects set with 

:auto-sitemap t
:sitemap-filename index.html
:sitemap-title Test Publishing Area
:sitemap-style tree

 I think reverting changes on headlines in HTML and DocBook exporters is
 the best option for now.

 Does the following patch work?

 Yes, this patch works for me.

Would you mind dismissing the previous patch and test the following
instead? I think that the approach is better.

Thank you in advance.

Regards,

-- 
Nicolas Goaziou
From e31e89430aa9f1b5de545c3bfd1503acc848d527 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Tue, 1 Nov 2011 11:40:11 +0100
Subject: [PATCH] Globalize some variables to make them available in buffers
 not in Org mode

* lisp/org.el (org-heading-regexp, org-heading-keyword-regexp-format,
  org-heading-keyword-maybe-regexp-format): Globalize variables so
  they are accessible even in buffers not in Org mode.
---
 lisp/org.el |   38 --
 1 files changed, 16 insertions(+), 22 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 318ccfd..c3c7bdf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4246,10 +4246,6 @@ collapsed state.
 
 ;;; Variables for pre-computed regular expressions, all buffer local
 
-(defvar org-heading-regexp nil
-  Matches an headline.
-Stars are put in group 1 and the trimmed body in group 2.)
-(make-variable-buffer-local 'org-heading-regexp)
 (defvar org-drawer-regexp nil
   Matches first line of a hidden block.)
 (make-variable-buffer-local 'org-drawer-regexp)
@@ -4273,18 +4269,6 @@ group 3: Priority cookie
 group 4: True headline
 group 5: Tags)
 (make-variable-buffer-local 'org-complex-heading-regexp)
-(defvar org-heading-keyword-regexp-format nil
-  Printf format to make regexp to match an headline with some keyword.
-This regexp will match the headline of any node which has the
-exact keyword that is put into the format.  The keyword isn't in
-any group by default, but the stars and the body are.)
-(make-variable-buffer-local 'org-heading-keyword-regexp-format)
-(defvar org-heading-keyword-maybe-regexp-format nil
-  Printf format to make regexp to match an headline with some keyword.
-This regexp can match any headline with the specified keyword, or
-a without a keyword.  The keyword isn't in any group by default,
-but the stars and the body are.)
-(make-variable-buffer-local 'org-heading-keyword-maybe-regexp-format)
 (defvar org-complex-heading-regexp-format nil
   Printf format to make regexp to match an exact headline.
 This regexp will match the headline of any node which has the
@@ -4661,12 +4645,6 @@ means to push this value onto the list in the variable.)
 	(concat \\(
 		(mapconcat 'regexp-quote org-not-done-keywords \\|)
 		\\))
-	org-heading-regexp
-	^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$
-	org-heading-keyword-regexp-format
-	^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$
-	org-heading-keyword-maybe-regexp-format
-	^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$
 	org-not-done-heading-regexp
 	(format org-heading-keyword-regexp-format org-not-done-regexp)
 	org-todo-line-regexp
@@ -4854,6 +4832,22 @@ This variable is set by `org-before-change-function'.
 This is similar to `org-outline-regexp' but additionally makes
 sure that we are at the beginning of the line.)
 
+(defconst org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$
+  Matches an headline, putting stars and text into groups.
+Stars are put in group 1 and the trimmed body in group 2.)
+(defconst org-heading-keyword-regexp-format
+  ^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$
+  Printf format for a regexp matching an headline with some keyword.
+This regexp will match the headline of any node which has the
+exact keyword that is put into the format.  The keyword isn't in
+any group by default, but the stars and the body are.)
+(defconst org-heading-keyword-maybe-regexp-format
+  ^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$
+  Printf format for a regexp matching an headline, possibly with some keyword.
+This regexp can match any headline with the specified keyword, or
+without a keyword.  The keyword isn't in any group by default,
+but the stars and the body are.)
+
 ;;;###autoload
 (define-derived-mode org-mode outline-mode Org
   Outline-based notes management and organizer, alias
-- 
1.7.7.1



Re: [O] [odt] equation labels

2011-11-01 Thread Myles English
 On Mon, 31 Oct 2011 11:54:35 +, Myles English said:

 On Mon, 31 Oct 2011 03:41:18 +0530, Jambunathan K said:

   Myles English mylesengl...@gmail.com writes:
   I have found that Equations become labelled as Figures in the
   version I am using:
   
   emacs 23.3.1 org-mode from git commit 71f1c1be (Oct 26) The test
   equations in latex-mathml.org in this message:
   
   http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00198.html
   
   are labelled as Equation in the odt files but when I export it
   fresh I get Figure.

   This was a regression. I pushed a fix few moments ago. Could you
   please pull again?

   Thanks for the push, there are three things I notice now:

   1) my document won't open and causes libreoffice to crash! I get:
   terminate called after throwing an instance of what():
   vector::_M_default_append on the command line

   2) the first equation in latex-mathml.org is not numbered, I would
   expect this if it was using a begin{equation*} environment but not a
   begin{equation}.

   3) the second equation looks a bit like this:

  x=root(b) (1) Radicals

  but I would have expected something like:

  x=root(b) Equation 1.: Radicals

Alright, points 2 and 3 are cleared up by me understanding that the
asterisk in \begin{equation*} has no visible effect, and that instead of
having Equation 1.: in the caption below the formula, there is a (1)
on the RHS.

Point 1 is entirely my own problem.

Myles



Re: [O] Bug: Publishing with auto-sitemap is broken [7.7 (release_7.7.497.gae02e)]

2011-11-01 Thread Bernt Hansen
Hi Nicolas,

Nicolas Goaziou n.goaz...@gmail.com writes:

 Bernt Hansen be...@norang.ca writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Bernt Hansen be...@norang.ca writes:

 Publishing with an automatically generated index file is broken for me.

 With org-publish-projects set with 

   :auto-sitemap t
   :sitemap-filename index.html
   :sitemap-title Test Publishing Area
   :sitemap-style tree

 I think reverting changes on headlines in HTML and DocBook exporters is
 the best option for now.

 Does the following patch work?

 Yes, this patch works for me.

 Would you mind dismissing the previous patch and test the following
 instead? I think that the approach is better.

Not at all :)  I'll try this after work tonight and report back.


 Thank you in advance.


And Thank You!

Regards,
Bernt



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Eric Schulte
Nicolas Goaziou n.goaz...@gmail.com writes:

 Correcting myself,

 Typically, what is required here is to add #+property: to the
 cumulative family. Thus,

 #+property: var foo=1
 #+property: var bar=2

 is exactly the same as #+property: var foo=1 var bar=2.

 Also, make sure var assignations accumulate too.

 I don't think #+property: should belong to a cumulative family of
 keywords. But Babel var keyword definitely should. Thus, the idea
 stays the same: on multiple var calls, accumulate values instead of
 replacing them (unless, obviously, the variables has already been
 assigned a value before).

This was one of the proposed options to solve this problem, namely
introduce a list of properties whose value accumulates rather than is
replaced.  Since the property list data structure only allows each key
to appear once, the accumulation would necessarily occur on the value
side, so assuming var is an accumulating property, then 

#+property: var foo=1
#+property: var bar=2

would result in `org-file-properties' having the following value

  ((var . foo=1 bar=1))

Which with some changes in the code-block side code could be used by
code blocks to assign multiple variables.

I went with changing property syntax rather than internal behavior
because I am not overly familiar with properties or the code with which
they were implemented and I felt (probably incorrectly) that this would
be a less dramatic change to Org-mode.  I'm happy to work up a solution
along the lines suggested above, which would introduce a variable like
`org-accumulating-properties' or some-such which would default to only
holding the var property name

Best -- Eric

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



Re: [O] wrap long table formula

2011-11-01 Thread Nick Dokos
Christian Moe m...@christianmoe.com wrote:

 On 11/1/11 8:17 AM, henry atting wrote:
 
  I was thinking of a column formula but have no clue if it's
  possible and if so, how.
 
  In this short example the formula's length is no problem but for a
  table with 12 rows or more it certainly is; -- and currently it's the
  only way I can realize it.
 
  |   |   |
  |---+---|
  | 2 |   |
  | 6 | 4 |
  | 7 | 5 |
  #+TBLFM: @3$2=vmean(@2$1..@3$1::@4$2=vmean(@2$1..@4$1
 
 
 |   | |
 |---+-|
 | 2 | |
 | 6 |   4 |
 | 7 |   5 |
 | 3 | 4.5 |
 | 9 | 5.4 |
 #+TBLFM: @3$2..@$2=vmean(@2$1..@0$1)
 

Another common way to deal with an exceptional cell is to use a field
formula for the exceptional cell and a column formula for the rest:
field formulas take precedence:

#+TBLFM: @2$2 = string() :: $2 = vmean(@2$1..@0$2)

Nick




Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

2011-11-01 Thread Nick Dokos
Eric Schulte schulte.e...@gmail.com wrote:

 My concerns with respect to a property drawer solution are two fold.
 
 1) In the same way that #+PROPERTY: assumes its value will live on a
single line, property drawers assume that their values will live on a
single line.  I don't see how it will be easier to fold multi-line
properties into drawers than outside of drawers.
 
 2) It is not possible to specify file-wide properties with drawers,
unlike with property lines.
 
 Thanks -- Eric
 

I felt uneasy about #+begin_property, but I could not articulate
my unease until first Nicolas and then Samuel expressed some of their
concerns.

But it seemed to me from the beginning that properties were *not* the
right fit for babel whole-file args and I'm more convinced than ever
that this is the *wrong* direction: it conflates different concepts
and it forces changes in a well established area in order to satisfy
the concerns of the other area.

Can we please back off this path? The changes are big, they affect
users' everyday work and it is not clear where they are going to end up.
Let's revert the changes to master, establish a branch, and do all this
experimentation in a branch. When it is thoroughly cooked to most
people's satisfaction, it can be merged into master. That way, people
can continue their daily work, without having to worry about changing
their files to satisfy the new changes.

Git provided exceptionally flexible branching: let's use it.

My two cents,
Nick

 Samuel Wales samolog...@gmail.com writes:
 
  Hi Eric,
 
  Properties can be specified in the properties drawer.  But
  multiple-line ones cannot at present (at least not without serializing the 
  way
  multiple-line macros are serialized).
 
  Therefore you propose new syntax for multiple-line properties.
 
  I propose that allowing the properties drawer to handle multiple-line
  properties might have 3 advantages over adding block syntax.
 
  1: If you want a single-line property, you have a choice.  If you want
  a multiple-line
  property, you have to use a block.  That seems inconsistent.
 
  2: Some people would probably have use for multiple-line properties, such
  as in org-contacts.  Doesn't have to be Babel.  People are used to the
  properties drawer.  Also, external parsers are.
 
  3: Nic objects to blocks without discussing them first.
 
  Perhaps upgrading properties drawer will satisfy that objection /and/ be
  consistent /and/ allow further uses in Org.
 
  This all presumes we're sticking with properties for Babel.
 
  Samuel
 
  -- 
  The Kafka Pandemic: http://thekafkapandemic.blogspot.com
  ===
  Bigotry against people with serious diseases is still bigotry.
 
 -- 
 Eric Schulte
 http://cs.unm.edu/~eschulte/
 



Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

2011-11-01 Thread Nick Dokos
Nick Dokos nicholas.do...@hp.com wrote:


 Can we please back off this path? 

In order to prevent confusion or needless argument: the path I think we
should back off of is the committing of these changes to master - I think
the work should be done in a branch and cooked thoroughly before merging
it to master.

I did not mean to imply (although I think one could easily get that impression
from my mail) backing off the property implementation (despite my personal
reservations about that).

Nick













Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

2011-11-01 Thread Eric Schulte
Nick Dokos nicholas.do...@hp.com writes:

 Nick Dokos nicholas.do...@hp.com wrote:


 Can we please back off this path? 

 In order to prevent confusion or needless argument: the path I think we
 should back off of is the committing of these changes to master - I think
 the work should be done in a branch and cooked thoroughly before merging
 it to master.


I would agree that these changes should be happening in branches if the
problems were technical, however the issues that need to be addressed
are social issues of consensus, and for better or worse pushing changes
to the master branch is the best way to alert all interested actors and
begin the consensus-building process.

If these changes had been pushed up to a branch they would be sitting
happily in that branch with no-one noticing or objecting.  They had been
discussed at length on list before their implementation and commitance,
but this most recent round of discussion was caused by a push to the
master branch.

This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same time I
think it is an acceptable place to try out new functionality.


 I did not mean to imply (although I think one could easily get that impression
 from my mail) backing off the property implementation (despite my personal
 reservations about that).


OK, good, because I *do* think that properties are a natural fit for
specifying code block parameters.  The use of subtree properties has
already proven itself, and file-wide properties are a natural extension
(much more natural than the introduction of a #+BABEL: header argument).

While there is certainly some pain in this process I think it is nailing
down both the needs for code block properties as well as the scope of
what is and is not desirable functionality for properties in general.

Best -- Eric


 Nick











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



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Nicolas Goaziou
Eric Schulte schulte.e...@gmail.com writes:

 This was one of the proposed options to solve this problem, namely
 introduce a list of properties whose value accumulates rather than is
 replaced.  Since the property list data structure only allows each key
 to appear once, the accumulation would necessarily occur on the value
 side, so assuming var is an accumulating property, then 

 #+property: var foo=1
 #+property: var bar=2

 would result in `org-file-properties' having the following value

   ((var . foo=1 bar=1))

 Which with some changes in the code-block side code could be used by
 code blocks to assign multiple variables.

 I went with changing property syntax rather than internal behavior
 because I am not overly familiar with properties or the code with which
 they were implemented and I felt (probably incorrectly) that this would
 be a less dramatic change to Org-mode.  I'm happy to work up a solution
 along the lines suggested above, which would introduce a variable like
 `org-accumulating-properties' or some-such which would default to only
 holding the var property name

That sounds way better to me. It's just a matter of modifying the
following part in `org-set-regexps-and-options'.

#+begin_src emacs-lisp
((equal key PROPERTY)
 (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value)
   (push (cons (match-string 1 value) (match-string 2 value))
 props)))
#+end_src

If we want to be a bit more future-proof on that side, we may even
refine the `org-accumulating-properties' idea by making it an
`org-accumulated-properties-alist' where key is property's name and
value a symbol describing how they are accumulated. That symbol could
be, for example `space', `comma', `newline', `consed'.


Regards,

-- 
Nicolas Goaziou



[O] [odt] regression in using an equation sourced via latex_header

2011-11-01 Thread Myles English

Hello,

If I have a latex file mystyle.tex that contains:

\newcommand{\myBigEquation}{b=23}

and then have this in my org file:

#+LATEX_HEADER: \usepackage{/path/to/mystyle}

I can use it conveniently like this:

\begin{equation}
 \myBigEquation
\end{equation}

and that exports fine to pdf but not to odt.  I am fairly sure it used
to work (around 7th Oct).  Can anyone confirm this?

Myles



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Eric Schulte
Nicolas Goaziou n.goaz...@gmail.com writes:

 Eric Schulte schulte.e...@gmail.com writes:

 This was one of the proposed options to solve this problem, namely
 introduce a list of properties whose value accumulates rather than is
 replaced.  Since the property list data structure only allows each key
 to appear once, the accumulation would necessarily occur on the value
 side, so assuming var is an accumulating property, then 

 #+property: var foo=1
 #+property: var bar=2

 would result in `org-file-properties' having the following value

   ((var . foo=1 bar=1))

 Which with some changes in the code-block side code could be used by
 code blocks to assign multiple variables.

 I went with changing property syntax rather than internal behavior
 because I am not overly familiar with properties or the code with which
 they were implemented and I felt (probably incorrectly) that this would
 be a less dramatic change to Org-mode.  I'm happy to work up a solution
 along the lines suggested above, which would introduce a variable like
 `org-accumulating-properties' or some-such which would default to only
 holding the var property name

 That sounds way better to me. It's just a matter of modifying the
 following part in `org-set-regexps-and-options'.

 #+begin_src emacs-lisp
 ((equal key PROPERTY)
  (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value)
(push (cons (match-string 1 value) (match-string 2 value))
  props)))
 #+end_src

 If we want to be a bit more future-proof on that side, we may even
 refine the `org-accumulating-properties' idea by making it an
 `org-accumulated-properties-alist' where key is property's name and
 value a symbol describing how they are accumulated. That symbol could
 be, for example `space', `comma', `newline', `consed'.


Beautiful,

The attached patch implements this idea with an alist as you specify
above.  If we can reach some sort of agreement that this is the best way
forward I will revert the property blocks and add this patch.

Unfortunately I don't know what constitutes agreement, or who the vested
interest holders are in this sort of decision.  I would be nice if
Carsten or Bastien could weigh in.

Cheers -- Eric

As an aside discussions like this are part of why I really enjoy working
on Org-mode.

From 2496eec5ad79c7e4e4f3804efb1bbce17f913704 Mon Sep 17 00:00:00 2001
From: Eric Schulte schulte.e...@gmail.com
Date: Tue, 1 Nov 2011 10:56:36 -0600
Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist').

  The default value of this new variable is '((var . , ))
  resulting in the following behavior

  #+property: var foo=1
  #+property: var bar=2

  #+begin_src emacs-lisp
(+ foo bar)
  #+end_src

  #+results:
  : 3

* lisp/org.el (org-accumulated-properties-alist): Adding an alist
  which specifies which properties may be accumulated and how.
  (org-set-regexps-and-options): Make use of accumulating properties
  when collecting said.
---
 lisp/org.el |   28 ++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 318ccfd..b34d274 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.)
 
+(defcustom org-accumulated-properties-alist
+  '((var . , ))
+  Alist of properties whose values should accumulate rather than overwrite.
+Each element of this alist should include both a string property
+name as well as the string connector used to join multiple values
+for this property.  So for example using the default value of
+this list which associates \var\ with \, \, the following
+Org-mode text,
+
+  #+PROPERTY: var foo=1
+  #+PROPERTY: var bar=2
+
+will result in the following being added to `org-file-properties'.
+
+  '(\var\ . \foo=1, bar=2\))
+
 (defun org-set-regexps-and-options ()
   Precompute regular expressions for current buffer.
   (when (eq major-mode 'org-mode)
@@ -4492,8 +4508,16 @@ means to push this value onto the list in the variable.)
 	  (setq prio (org-split-string value  +)))
 	 ((equal key PROPERTY)
 	  (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		  props)))
+		(let* ((prop (match-string 1 value))
+		   (value (match-string 2 value))
+		   (str (cdr (assoc prop org-accumulated-properties-alist)))
+		   (existing (cdr (assoc prop props
+		  (if (and str existing)
+		  (setq props (cons (cons prop (concat existing str value))
+	(org-remove-if (lambda (p)
+			 (string= (car p) prop))
+		   props)))
+		(push (cons prop value) props)
 	 ((equal key FILETAGS)
 	  (when (string-match \\S- value)
 		(setq ftags
-- 
1.7.4.1




 Regards,

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


Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Christian Moe

On 11/1/11 5:58 PM, Eric Schulte wrote:


 so assuming var is an accumulating property, then

#+property: var foo=1
#+property: var bar=2

would result in `org-file-properties' having the following value

   ((var . foo=1 bar=1))


Given this:

---


#+property: var foo=1
#+property: var bar=2

* Heading
  :PROPERTIES:
  :var: foo=3
  :END:


---

Would it result in ((var . foo=3 bar=2))?

Yours,
Christian



Re: [O] wrap long table formula

2011-11-01 Thread henry atting
Nick Dokos nicholas.do...@hp.com writes:

 Christian Moe m...@christianmoe.com wrote:

 On 11/1/11 8:17 AM, henry atting wrote:
 
  I was thinking of a column formula but have no clue if it's
  possible and if so, how.
 
  In this short example the formula's length is no problem but for a
  table with 12 rows or more it certainly is; -- and currently it's the
  only way I can realize it.
 
  |   |   |
  |---+---|
  | 2 |   |
  | 6 | 4 |
  | 7 | 5 |
  #+TBLFM: @3$2=vmean(@2$1..@3$1::@4$2=vmean(@2$1..@4$1
 
 
 |   | |
 |---+-|
 | 2 | |
 | 6 |   4 |
 | 7 |   5 |
 | 3 | 4.5 |
 | 9 | 5.4 |
 #+TBLFM: @3$2..@$2=vmean(@2$1..@0$1)
 

 Another common way to deal with an exceptional cell is to use a field
 formula for the exceptional cell and a column formula for the rest:
 field formulas take precedence:

 #+TBLFM: @2$2 = string() :: $2 = vmean(@2$1..@0$2)

 Nick

Thanks again to all, both solutions are working fine; I could get rid of my
tapeworm formula.

Is there a place where these advanced features are explained more thoroughly?

henry

-- 
http://literaturlatenight.de



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Eric Schulte
Christian Moe m...@christianmoe.com writes:

 On 11/1/11 5:58 PM, Eric Schulte wrote:

  so assuming var is an accumulating property, then

 #+property: var foo=1
 #+property: var bar=2

 would result in `org-file-properties' having the following value

((var . foo=1 bar=1))

 Given this:

 ---


 #+property: var foo=1
 #+property: var bar=2

 * Heading
:PROPERTIES:
:var: foo=3
:END:


 ---

 Would it result in ((var . foo=3 bar=2))?


Good catch Christian, I get the following behavior, currently seems the
property-block specification overwrites the global property.  I'll have
to update my patch to append at the subheading level as well.

#+property: var foo=1
#+property: var bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) var t)
#+end_src

#+results:
: foo=1, bar=2

* heading
  :PROPERTIES:
  :var:  foo=4
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 4

#+begin_src emacs-lisp
  (org-entry-get (point) var t)
#+end_src

#+results:
: foo=4

As for variable handling, I think the solution is to ensure that on the
code-block side of things, a var string like foo=3, bar=2, foo=1
results in,

foo=1
bar=2

that is, subtree variable definitions will pre-empty earlier definitions
of the same variable..

Best -- Eric


 Yours,
 Christian

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


Re: [O] [odt] regression in using an equation sourced via latex_header

2011-11-01 Thread Jambunathan K

Myles

Thanks for exercising the latex-to-mathml changes. I am happy that there
is someone out there interested in and using stuff that I have spent
some efforts on.

 Hello,

 If I have a latex file mystyle.tex that contains:

 \newcommand{\myBigEquation}{b=23}

 and then have this in my org file:

 #+LATEX_HEADER: \usepackage{/path/to/mystyle}

 I can use it conveniently like this:

 \begin{equation}
  \myBigEquation
 \end{equation}

 and that exports fine to pdf but not to odt.  I am fairly sure it used
 to work (around 7th Oct).  Can anyone confirm this?

I am using the very latest version in the git. While exporting to odt
using

1. dvipng 
   - I see no issues [1]

2. mathml
   - You need to register your command file with -ncf argument.

 For example, if I put the mystyle.tex in the same directory as
 exported .org file and add the -ncf argument to the converter as
 below

 #+begin_src emacs-lisp
 (setq org-latex-to-mathml-convert-command
   java -jar %j -ncf mystyle.tex -unicode -force -df %o %I )
 #+end_src

 I see that your sample file gets exported just fine.

Side Note:
==

1. You don't have to export the whole file to see whether the
   latex-mathml conversion is sane.

   You can mark - as in marking a region - the LaTeX fragment in your
   org file and do a M-x org-create-math-formula. You will see something
   like this echoed in you *Messages* buffer.

, M-x org-create-math-formula
| Mark set [2 times]
| Mark activated
| Wrote ~/tmp-myles/ltxmathml-in3272esr
| Running java -jar ~/tmp-odt/mathtoweb.jar -ncf mystyle.tex -unicode -force 
-df ltxmathml-out3272r2x ltxmathml-in3272esr 
| ?xml version=1.0 encoding=UTF-8?
| math xmlns=http://www.w3.org/1998/Math/MathML;
| mrow
|   mspace width=1.00em /
|   mib/mi
|   mo=/mo
|   mn23/mn
| /mrow
| /math
`

2. I am copy pasting the extra stuff that gets attached to the latex
   fragment before it get latex ed and dvipnged.

   latex-to-mathml converter ignores *all* of the stuff that goes in
   org-format-latex-header, org-export-latex-default-packages-alist,
   org-export-latex-packages-alist, org-format-latex-header-extra
   variables.

   I think I should build an ncf file on the fly based on these
   variables and pass it to the command line converter.

   Since I don't know much of latex, can you or someone in the list give
   me pointers on what would constitute an ncf argument as expected by
   mathtoweb.

   I will make the needed changes as required.
   
, See org-create-formula-image
| (with-temp-file texfile
|   (insert (org-splice-latex-header
|  org-format-latex-header
|  org-export-latex-default-packages-alist
|  org-export-latex-packages-alist t
|  org-format-latex-header-extra))
|   (insert \n\\begin{document}\n string \n\\end{document}\n)
|   (require 'org-latex)
|   (org-export-latex-fix-inputenc))
`

, temporary tex file [see LATEX-HEADER at the end]
| \documentclass{article}
| \usepackage[usenames]{color}
| \usepackage{amsmath}
| \usepackage[mathscr]{eucal}
| \pagestyle{empty} % do not remove
| \usepackage{pdfpages}
| \usepackage[utf8]{inputenc}
| \usepackage[T1]{fontenc}
| % Package fixltx2e omitted
| \usepackage{graphicx}
| % Package longtable omitted
| % Package float omitted
| % Package wrapfig omitted
| \usepackage{soul}
| \usepackage{t1enc}
| \usepackage{textcomp}
| \usepackage{amssymb}
| % Package hyperref omitted
| \tolerance=1000
| % The settings below are copied from fullpage.sty
| \setlength{\textwidth}{\paperwidth}
| \addtolength{\textwidth}{-3cm}
| \setlength{\oddsidemargin}{1.5cm}
| \addtolength{\oddsidemargin}{-2.54cm}
| \setlength{\evensidemargin}{\oddsidemargin}
| \setlength{\textheight}{\paperheight}
| \addtolength{\textheight}{-\headheight}
| \addtolength{\textheight}{-\headsep}
| \addtolength{\textheight}{-\footskip}
| \addtolength{\textheight}{-3cm}
| \setlength{\topmargin}{1.5cm}
| \addtolength{\topmargin}{-2.54cm}
| 
| \usepackage{jambu}
| \begin{document}
| \begin{equation}
|  \myBigEquation
| \end{equation}
| \end{document}
`

Footnotes: 

[1]  LaTeX novice here. 

The method I used is this: Put that style file in one of the local
directories and register that directory as a root with the MikTex
package manager. Then use this directive:
\usepackage{jambu}

ps: I am on Windows using Cygwin. So getting the directory path right
with escaping - what with spaces in directories - is always a
hair-splitting experience for me.

 
 Myles





-- 



Re: [O] wrap long table formula

2011-11-01 Thread Nick Dokos
henry atting nsmp...@online.de wrote:

 Nick Dokos nicholas.do...@hp.com writes:
 
  Christian Moe m...@christianmoe.com wrote:
 
  |   | |
  |---+-|
  | 2 | |
  | 6 |   4 |
  | 7 |   5 |
  | 3 | 4.5 |
  | 9 | 5.4 |
  #+TBLFM: @3$2..@$2=vmean(@2$1..@0$1)
  
 
  Another common way to deal with an exceptional cell is to use a field
  formula for the exceptional cell and a column formula for the rest:
  field formulas take precedence:
 
  #+TBLFM: @2$2 = string() :: $2 = vmean(@2$1..@0$2)
 

 Thanks again to all, both solutions are working fine; I could get rid of my
 tapeworm formula.
 
 Is there a place where these advanced features are explained more thoroughly?
 

All of this is contained in

(info (org) The spreadsheet)

but sometimes you have to read the section a few times (and refer back
to it a few more times): in particular

   (info (org) References)

and

   (info (org) Field and range formulas)

deserve repeated reading. 

   (info (org) Column formulas)

describes the field formula trick.

The whole spreadsheet section of the manual could benefit from a list of
well chosen examples (perhaps on Worg, with a pointer from the manual).
But afaict, everything is in the manual.

Nick










Re: [O] [odt] regression in using an equation sourced via latex_header

2011-11-01 Thread Jambunathan K
 2. mathml
- You need to register your command file with -ncf argument.

  For example, if I put the mystyle.tex in the same directory as
  exported .org file and add the -ncf argument to the converter as
  below

  #+begin_src emacs-lisp
  (setq org-latex-to-mathml-convert-command
java -jar %j -ncf mystyle.tex -unicode -force -df %o %I )
  #+end_src


ncf option is documented here:
http://www.mathtoweb.com/cgi-bin/mathtoweb_users_guide.pl#Using_newcommand_and_renewcommand



Re: [O] [odt] equation labels

2011-11-01 Thread Jambunathan K

Myles

(I have read the followup post to this set of questions)

Myles English mylesengl...@gmail.com writes:
 On Mon, 31 Oct 2011 03:41:18 +0530, Jambunathan K said:

Myles English mylesengl...@gmail.com writes:
I have found that Equations become labelled as Figures in the
version I am using:

emacs 23.3.1 org-mode from git commit 71f1c1be (Oct 26) The test
equations in latex-mathml.org in this message:

http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00198.html

are labelled as Equation in the odt files but when I export it
fresh I get Figure.

This was a regression. I pushed a fix few moments ago. Could you
please pull again?

 Thanks for the push, there are three things I notice now:

 1) my document won't open and causes libreoffice to crash! I get:
terminate called after throwing an instance of
  what():  vector::_M_default_append on the command line

1. You are using custom styles for your latex fragment
2. latex-to-mathml converter - as it stands today - assumes the latex
   fragment is completed in and of itself and doesn't honor the style
   settings.

Putting 1 and 2 together, I am assuming that the XML created by the ODT
emitter contains garbage which is causing LibreOffice to be confused. In
my observation, ill-formed XML triggers file is corrupt and should I
repair the file? from LibreOffice. A crash seems strange to me.

1. http://article.gmane.org/gmane.emacs.orgmode/48714
   - Above link has my note on -ncf option to mathtoweb

2. http://orgmode.org/worg/org-faq.html
   - Above link has a note on how to debug corrupt odt files.
 (Hint: search for corrupt)

 2) the first equation in latex-mathml.org is not numbered, I would
expect this if it was using a begin{equation*} environment but not a
begin{equation}.

Currently the odt exporter doesn't peek in to the latex fragment and
infer what manner of equation it is. This is something that I could take
up ...

,
| (defvar org-latex-regexps
|   '((begin ^[ 
\t]*\\(begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?end{\\2}\\) 1 t)
| ;; ($ \\([ (]\\|^\\)\\(\\(\\([$]\\)\\([^   
\r\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^   \r\n,.$]\\)\\4\\)\\)\\([
.,?;:'\)]\\|$\\) 2 nil)
| ;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
| ($1 \\([^$]\\|^\\)\\(\\$[^ \r\n,;.$]\\$\\)\\([-
.,?;:'\)\000]\\|$\\) 2 nil)
| ($ \\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\([-   .,?;:'\)\000]\\|$\\) 2 nil)
| (\\( ([^\000]*?) 0 nil)
| (\\[ \\[[^\000]*?\\] 0 nil)
| ($$ \\$\\$[^\000]*?\\$\\$ 0 nil))
|   Regular expressions for matching embedded LaTeX.)
`


 3) the second equation looks a bit like this:

x=root(b)   (1)
Radicals

but I would have expected something like:

x=root(b)
Equation 1.: Radicals

 Is there a new variable that I need to set to get (e.g.) Equation
 1.?

Being a non-latex user, I am not familiar with what the usual practice
is. If the latter option is how captioned equations are normally typeset
I can take it up. Can you confirm that the expectations above are *not*
your own but that of *any* user?

 Just to be explicit, the test file latex-mathml.org I am referring to
 contains:

 #+TITLE: latex-mathml.org
 #+AUTHOR:Jambunathan K
 #+EMAIL: address@hidden
 #+DATE:  2011-09-09 Fri
 #+DESCRIPTION:
 #+KEYWORDS:
 #+LANGUAGE:  en
 #+OPTIONS:   H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
 #+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

 #+EXPORT_SELECT_TAGS: export
 #+EXPORT_EXCLUDE_TAGS: noexport
 #+LINK_UP:   
 #+LINK_HOME: 
 #+XSLT:

 * LaTeX Fragments

 ** LaTeX Fragment1
 #   See org-format-latex-options

 There is a equation down below.

\begin{equation}
  e = \frac{1}{2}mv^2
\end{equation}

 ** LaTeX Fragment2

 #+CAPTION: Radicals
 #+LABEL: Equation:1
\begin{equation}
x=\sqrt{b}
\end{equation}

If $a^2=b$ and \( b=2 \), then the solution must be either $$
a=+\sqrt{2} $$ or \[ a=-\sqrt{2} \].


 Myles



-- 



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Christian Moe

On 11/1/11 8:02 PM, Eric Schulte wrote:

As for variable handling, I think the solution is to ensure that on the
code-block side of things, a var string like foo=3, bar=2, foo=1
results in,

foo=1
bar=2

that is, subtree variable definitions will pre-empty earlier definitions
of the same variable..


Yes, that sounds like the way to go. My previous message implied that 
the var string should only contain unique variable names, but I see 
that that would be needlessly complicated.


This is an interesting approach; I like it better than the property 
block. I'm sure we will think of other useful applications for 
cumulative properties, too (conversely, there'll probably be some side 
effect that will turn around and bite us at some point, though I can't 
think what it would be).


Yours,
Christian



Re: [O] [odt] equation labels

2011-11-01 Thread Jambunathan K

 2) the first equation in latex-mathml.org is not numbered, I would
expect this if it was using a begin{equation*} environment but not a
begin{equation}.

 Currently the odt exporter doesn't peek in to the latex fragment and
 infer what manner of equation it is. This is something that I could take
 up ...

As thing stand today, to produce a numbered equation just attach
#+LABEL: to it. This is how odt exporter determines when a formula is
numbered or not.
-- 



Re: [O] [DEV] New package org-refer-by-number

2011-11-01 Thread Marc-Oliver Ihm

Hello all,

fixing some bugs I have published a new version of the package 
org-refer-by-number to Worg:

http://orgmode.org/worg/org-contrib/index.html

,where it available as a contributed package.

The location of the elisp file is:

http://ferntreffer.de/elisp/org-refer-by-number.el

The file is documented extensively, so I hope the package can be used readily by anyone, who 
finds it useful.



regards, Marc-Oliver Ihm




Re: [O] [DEV] New package org-refer-by-number

2011-11-01 Thread Jambunathan K

 The location of the elisp file is:

   http://ferntreffer.de/elisp/org-refer-by-number.el


Copyright line says it is FSF. In that case, you should consider adding
it to GNU ELPA -  http://elpa.gnu.org
-- 



Re: [O] About commit named Allow multi-line properties to be specified in property blocks

2011-11-01 Thread Eric Schulte
Christian Moe m...@christianmoe.com writes:

 On 11/1/11 8:02 PM, Eric Schulte wrote:
 As for variable handling, I think the solution is to ensure that on the
 code-block side of things, a var string like foo=3, bar=2, foo=1
 results in,

 foo=1
 bar=2

 that is, subtree variable definitions will pre-empty earlier definitions
 of the same variable..

 Yes, that sounds like the way to go. My previous message implied that
 the var string should only contain unique variable names, but I see
 that that would be needlessly complicated.

 This is an interesting approach; I like it better than the property
 block.

Me too.

 I'm sure we will think of other useful applications for cumulative
 properties, too (conversely, there'll probably be some side effect
 that will turn around and bite us at some point, though I can't think
 what it would be).


Hopefully more of the former and less of the later.

Attached is a new patch, which handles subtree inheritance
appropriately, resulting in the following behavior.

#+property: var foo=1
#+property: var bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) var t)
#+end_src

#+results:
: foo=1, bar=2

* heading
  :PROPERTIES:
  :var:  foo=7
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 7

#+begin_src emacs-lisp
  (org-entry-get (point) var t)
#+end_src

#+results:
: foo=1, bar=2, foo=7

Thanks -- Eric

From ff3330193da27a6b0dcf4be92ed54424040ddaec Mon Sep 17 00:00:00 2001
From: Eric Schulte schulte.e...@gmail.com
Date: Tue, 1 Nov 2011 10:56:36 -0600
Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist').

  The default value of this new variable is '((var . , ))
  resulting in the following behavior

  #+property: var foo=1
  #+property: var bar=2

  #+begin_src emacs-lisp
(+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
(org-entry-get (point) var t)
  #+end_src

  #+results:
  : foo=1, bar=2

  * heading
:PROPERTIES:
:var:  foo=7
:END:

  #+begin_src emacs-lisp
foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
(org-entry-get (point) var t)
  #+end_src

  #+results:
  : foo=1, bar=2, foo=7

* lisp/org.el (org-accumulated-properties-alist): Adding an alist
  which specifies which properties may be accumulated and how.
  (org-set-regexps-and-options): Make use of accumulating properties
  when collecting said.
  (org-property-from-plists): Return the (possibly accumulated) value
  of property from plists.
  (org-entry-get-with-inheritance): Inherit accumulated properties
  appropriately.
---
 lisp/org.el |   52 ++--
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 318ccfd..2fe8d92 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.)
 
+(defcustom org-accumulated-properties-alist
+  '((var . , ))
+  Alist of properties whose values should accumulate rather than overwrite.
+Each element of this alist should include both a string property
+name as well as the string connector used to join multiple values
+for this property.  So for example using the default value of
+this list which associates \var\ with \, \, the following
+Org-mode text,
+
+  #+PROPERTY: var foo=1
+  #+PROPERTY: var bar=2
+
+will result in the following being added to `org-file-properties'.
+
+  '(\var\ . \foo=1, bar=2\))
+
 (defun org-set-regexps-and-options ()
   Precompute regular expressions for current buffer.
   (when (eq major-mode 'org-mode)
@@ -4492,8 +4508,13 @@ means to push this value onto the list in the variable.)
 	  (setq prio (org-split-string value  +)))
 	 ((equal key PROPERTY)
 	  (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		  props)))
+		(let* ((prp (match-string 1 value))
+		   (val (match-string 2 value))
+		   (new (org-property-from-plists
+			 prp `((,prp . ,val)) props)))
+		  (setq props (cons (cons prp new)
+(org-remove-if (lambda (p) (string= (car p) prp))
+		   props))
 	 ((equal key FILETAGS)
 	  (when (string-match \\S- value)
 		(setq ftags
@@ -14170,6 +14191,24 @@ no match, the marker will point nowhere.
 Note that also `org-entry-get' calls this function, if the INHERIT flag
 is set.)
 
+(defun org-property-from-plists (property rest plists)
+  Return PROPERTY from PLISTS respecting `org-accumulated-properties-alist'.
+  (flet ((until (fn lst) (when (not (null lst))
+			   (or (funcall fn (car lst))
+			   (funcall fn (cdr lst))
+(let ((str (cdr (assoc property org-accumulated-properties-alist
+  (if str
+	  (let (result)
+	(mapc 

Re: [O] custom IDs not exported

2011-11-01 Thread Sten Lindner
On Sat, Jun 11, 2011 at 11:12:26PM -0400, Nick Dokos wrote:
 
 I have a minimal patch that I think fixes this problem, but there are
 other underscores used in various places in org-html.el so there might
 be additional problems. I'd appreciate it if you (and/or others) test it
 and report not only on this problem but on any other problems you find.

I'm having the same problem when exporting to Docbook, custom IDs are
being ignored.

For example, when I export some org-mode text using C-c C-e D:

* heading1
  :PROPERTIES:
  :CUSTOM_ID: h1
  :END:

** heading2
  :PROPERTIES:
  :CUSTOM_ID: h2
  :END:

some links:
- see [[#h1][heading1]]
- see [[#h2][heading2]]

I' getting the following XML output:

section xml:id=sec-1
titleheading1 /title
section xml:id=sec-1_1
titleheading2 /title
para
some links:
/para
itemizedlist
listitem
parasee link linkend=h1heading1/link
/para
/listitem
listitem
parasee link linkend=h2heading2/link
/para
/listitem
/itemizedlist
/section
/section
/article

I would expect to see my custom IDs H1 and H2 but instead get
auto-generated IDs sec-1 and sec-1_1.

I'm using the latest org-mode version 7.7.

best regards,
Sten

-- 
Sten Lindner

e-mail: s.lind...@stenlindner.de



[O] org-protocol is bitrotting away

2011-11-01 Thread Florian Hars
Of cousre my first error was to try to do something productive on a
current ubuntu, but since they have again broken the canonical way to
configure protocol handlers, 90% of all howtos describing how to
configure org-protocol plain don't work on ubuntu 11.10. gconftool
does no longer work, setting things in about:config in firefox has no
effect, the current season's incantantion is to put

[Desktop Entry]
Name=org-protocol
Exec=emacsclient %U
Type=Application
Terminal=false
Categories=System;
MimeType=x-scheme-handler/org-protocol;

into ~/.local/share/applications/org-protocol.desktop and then run
update-desktop-database .local/share/applications/ , as mentioned before:
http://permalink.gmane.org/gmane.emacs.orgmode/41733

More serious is the problen that firefox 7.0.1 steadfastly refuses
to set location.href to the URIs required by org-protocol, it throws
rather scary looking exceptions if the result of
encodeURIComponent(location.href) in the URI does not appear after a
question mark. I sort of got it working  by changing the URI to 
org-protocol://capture://?x=+encodeURIComponent(l)+/+...
and then added the same three characters in
org-protocol-check-filename-for-protocol:
 (regexp-quote (plist-get (cdr prolist) :protocol)) :/+\\(\\?x=\\)?)))

- Florian.



Re: [O] [Orgmode] Re: Can't import a remote reference to a whole column in orgtbl

2011-11-01 Thread Nick Dokos
Michael Brand michael.br...@alumni.ethz.ch wrote:

 Carsten Dominik wrote:
  this is neat, but still kind of hard to do, because you have to put
  all these formulas there by hand.  I am skipping this for the manual
  - maybe you'd like to put this into org-hacks, or into the FAQ on
  Worg?
 
 Ok, I have put it into Worg org-hacks.org:
 http://orgmode.org/worg/org-hacks.php
 in the section `Field coordinates in formulas', currently with this numbering
 http://orgmode.org/worg/org-hacks.php#sec-17.2
 
 And only now I have seen and answered this thread:
 `feature request: transpose a table'
 started here
 http://thread.gmane.org/gmane.emacs.orgmode/17453
 and continued here
 http://thread.gmane.org/gmane.emacs.orgmode/23809
 

Since this is  a reply to an old thread, let me set some context: there was a 
flurry
of activity about transposing a table about 1.5 years ago - in addition to the 
two
threads above, there was

http://thread.gmane.org/gmane.emacs.orgmode/22610

http://thread.gmane.org/gmane.emacs.orgmode/22930

The latter contains a patch by Michael Brand that  introduced field 
coordinates
that got incorporated into org. That allowed Michael to do a table transposition
that he also added to org-hacks (but the section number has changed - it is at

  http://orgmode.org/worg/org-hacks.html#sec-1-3-5

currently).

There were various other solutions too using lisp (by Tom Dye and Juan
Pechiar: iiuc, both of these were based on library-of-babel code), that might
be more efficient than Michael's solution (Carsten warns explicitly about
the inefficiency somewhere).

But Michael's solution is clever: the idea is to create an empty table of the
right dimensions, delete any separator lines manually and then apply a sequence
of (identical) formulas, one for each column in the destination table, that
populates the column from the corresponding row of the source table, then add
separator lines back manually. To simplify the discussion, here's an example
without separators:

#+TBLNAME: FOO
| year | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 |
| min  |  401 |  501 |  601 |  701 |  801 |  901 |
| avg  |  402 |  502 |  602 |  702 |  802 |  902 |
| max  |  403 |  503 |  603 |  703 |  803 |  903 |

So create a 7x4 table: M-x org-table-create RET 4x7 RET [fn:1]
delete the separator, and apply the formulas: 

|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
#+TBLFM: $1 = remote(FOO, @$#$@#) :: $2 = remote(FOO, @$#$@#) :: $3 = 
remote(FOO, @$#$@#) :: $4 = remote(FOO, @$#$@#) ::

Footnotes:

[fn:1] Note the order - not sure why org-table-create wants the dimensions in
the opposite order.



Re: [O] [Orgmode] Re: Can't import a remote reference to a whole column in orgtbl

2011-11-01 Thread Nick Dokos
[Aaaargh: premature communication - apologies to all and let me try again]

Michael Brand michael.br...@alumni.ethz.ch wrote:

 Carsten Dominik wrote:
  this is neat, but still kind of hard to do, because you have to put
  all these formulas there by hand.  I am skipping this for the manual
  - maybe you'd like to put this into org-hacks, or into the FAQ on
  Worg?
 
 Ok, I have put it into Worg org-hacks.org:
 http://orgmode.org/worg/org-hacks.php
 in the section `Field coordinates in formulas', currently with this numbering
 http://orgmode.org/worg/org-hacks.php#sec-17.2
 
 And only now I have seen and answered this thread:
 `feature request: transpose a table'
 started here
 http://thread.gmane.org/gmane.emacs.orgmode/17453
 and continued here
 http://thread.gmane.org/gmane.emacs.orgmode/23809
 

Since this is  a reply to an old thread, let me set some context: there was a 
flurry
of activity about transposing a table about 1.5 years ago - in addition to the 
two
threads above, there was

http://thread.gmane.org/gmane.emacs.orgmode/22610

http://thread.gmane.org/gmane.emacs.orgmode/22930

The latter contains a patch by Michael Brand that  introduced field 
coordinates
that got incorporated into org. That allowed Michael to do a table transposition
that he also added to org-hacks (but the section number has changed - it is at

  http://orgmode.org/worg/org-hacks.html#sec-1-3-5

currently).

There were various other solutions too using lisp (by Tom Dye and Juan
Pechiar: iiuc, both of these were based on library-of-babel code), that might
be more efficient than Michael's solution (Carsten warns explicitly about
the inefficiency somewhere).

But Michael's solution is clever: the idea is to create an empty table of the
right dimensions, delete any separator lines manually and then apply a sequence
of (identical) formulas, one for each column in the destination table, that
populates the column from the corresponding row of the source table, then add
separator lines back manually. To simplify the discussion, here's an example
without separators:

#+TBLNAME: FOO
| year | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 |
| min  |  401 |  501 |  601 |  701 |  801 |  901 |
| avg  |  402 |  502 |  602 |  702 |  802 |  902 |
| max  |  403 |  503 |  603 |  703 |  803 |  903 |

So create a 7x4 table: M-x org-table-create RET 4x7 RET [fn:1]
delete the separator, and apply the formulas: 

| year | min | avg | max |
| 2004 | 401 | 402 | 403 |
| 2005 | 501 | 502 | 503 |
| 2006 | 601 | 602 | 603 |
| 2007 | 701 | 702 | 703 |
| 2008 | 801 | 802 | 803 |
| 2009 | 901 | 902 | 903 |
#+TBLFM: $1 = remote(FOO, @$#$@#) :: $2 = remote(FOO, @$#$@#) :: $3 = 
remote(FOO, @$#$@#) :: $4 = remote(FOO, @$#$@#)

And voilà - transposition.

As Carsten notes however, this is kind of hard to do and at the time there was
no way to condense the multiple formulas into one; but ranges on the LHS have 
now
been added to org and can do just that:

| year | min | avg | max |
| 2004 | 401 | 402 | 403 |
| 2005 | 501 | 502 | 503 |
| 2006 | 601 | 602 | 603 |
| 2007 | 701 | 702 | 703 |
| 2008 | 801 | 802 | 803 |
| 2009 | 901 | 902 | 903 |
#+TBLFM: @1$1..@$ = remote(FOO, @$#$@#)

Nick

Footnotes:

[fn:1] Note the order - not sure why org-table-create wants the dimensions in
the opposite order.



Re: [O] Bug: Publishing with auto-sitemap is broken [7.7 (release_7.7.497.gae02e)]

2011-11-01 Thread Bernt Hansen
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Bernt Hansen be...@norang.ca writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Bernt Hansen be...@norang.ca writes:

 Publishing with an automatically generated index file is broken for me.

 With org-publish-projects set with 

   :auto-sitemap t
   :sitemap-filename index.html
   :sitemap-title Test Publishing Area
   :sitemap-style tree

 I think reverting changes on headlines in HTML and DocBook exporters is
 the best option for now.

 Does the following patch work?

 Yes, this patch works for me.

 Would you mind dismissing the previous patch and test the following
 instead? I think that the approach is better.

 Thank you in advance.

This patch works too - thanks!

-Bernt



Re: [O] notify, when something to do

2011-11-01 Thread Peter Münster
On Sun, Oct 23 2011, Bastien wrote:

 - Perhaps the main problem: appt does not know about warning periods.
   There are items with -3d, other with -5M[1]. There is only one
   universal appt-message-warning-time. Would it be possible, to have a
   individual warning-time for each todo-item, directly computed from the
   warning time in the org-timestamp?

 Check what info is available as text properties in the agenda 
 (with `C-u C-x =') and see if you can use this information in 
 a filter function.

There is `type = upcoming-deadline', so it should be doable.

Thanks for the filter-function and the scope-keywords!

-- 
   Peter




Re: [O] Tags included in subtree export title despite tags:nil in header

2011-11-01 Thread suvayu ali
Hi Bastien and all,

On Sun, 30 Oct 2011 09:48:06 +0100
Bastien b...@altern.org wrote:

 Suvayu Ali fatkasuvayu+li...@gmail.com writes:

  That said, the problem I am facing is org-export-with-tags
  evaluates to not-in-toc irrespective of what is set by the tags:
  option (see for example the test file earlier in the thread). So
  effectively the test is not checking what it is supposed to check.
  So I was wondering whether I missed something I should be doing.

 The problem is that `org-export-with-tags' is a global option,
 storing the default value for any buffer (and _a fortiori_ any
 subtree) -- while you want to check local options, which may
 be different at export time.

 Local options are stored in a `org-export-opt-plist'.  You get
 the value of the tags: option by checking the property list
 like this:

   (plist-get org-export-opt-plist :tags))

 Hence the patch below, which you can try to make sure it does
 what you want.


That seems to work only when the EXPORT_OPTIONS property is set for the
subtree. Without the property, it doesn't pick up the tags:nil option
from the file header. Actually, the property list doesn't even have
the tags: property in it.

However I did find a solution along those lines and the final patch is
attached. :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
From dac022f103f8498de96fa5d0e40e0b840ae9c7fb Mon Sep 17 00:00:00 2001
From: Suvayu Ali fatkasuvayu+li...@gmail.com
Date: Wed, 2 Nov 2011 00:26:07 +0100
Subject: [PATCH] Respect export options for subtree export title

* org-exp.el (org-solidify-link-text): Respect org-export-with-tags
  when forming the export title during subtree export.

TINY CHANGE
---
 lisp/org-exp.el |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index fa54242..e8ad0b9 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -2160,15 +2160,21 @@ (defun org-export-grab-title-from-buffer ()
 (defun org-export-get-title-from-subtree ()
   Return subtree title and exclude it from export.
   (let ((rbeg (region-beginning)) (rend (region-end))
-	(inhibit-read-only t) title)
+	(inhibit-read-only t)
+	(tags (plist-get (org-infile-export-plist) :tags))
+	title)
 (save-excursion
   (goto-char rbeg)
   (when (and (org-at-heading-p)
 		 (= (org-end-of-subtree t t) rend))
+	(when (plist-member org-export-opt-plist :tags)
+	  (setq tags (or (plist-get org-export-opt-plist :tags) tags)))
 	;; This is a subtree, we take the title from the first heading
 	(goto-char rbeg)
-	(looking-at org-todo-line-regexp)
-	(setq title (match-string 3))
+	(looking-at org-todo-line-tags-regexp)
+	(setq title (if (eq tags t)
+			(format %s\t%s (match-string 3) (match-string 4))
+		  (match-string 3)))
 	(org-unmodified
 	 (add-text-properties (point) (1+ (point-at-eol))
 			  (list :org-license-to-kill t)))
-- 
1.7.7



Re: [O] org-protocol is bitrotting away

2011-11-01 Thread Rafael
Florian Hars flor...@hars.de writes:

 Of cousre my first error was to try to do something productive on a
 current ubuntu, but since they have again broken the canonical way to
 configure protocol handlers, 90% of all howtos describing how to
 configure org-protocol plain don't work on ubuntu 11.10. gconftool
 does no longer work, setting things in about:config in firefox has no
 effect, the current season's incantantion is to put

 [Desktop Entry]
 Name=org-protocol
 Exec=emacsclient %U
 Type=Application
 Terminal=false
 Categories=System;
 MimeType=x-scheme-handler/org-protocol;

 into ~/.local/share/applications/org-protocol.desktop and then run
 update-desktop-database .local/share/applications/ , as mentioned before:
 http://permalink.gmane.org/gmane.emacs.orgmode/41733

Hmm. With Ubuntu 11.10 and Firefox that came with it, these steps were
not enough. I had Firefox asking for the application to open
org-protocol links, and choosing 'org-protocol' did not work, as it had
in Natty. However, choosing '/usr/bin/emacsclient' for the application,
worked for me.

 More serious is the problen that firefox 7.0.1 steadfastly refuses
 to set location.href to the URIs required by org-protocol, it throws
 rather scary looking exceptions if the result of
 encodeURIComponent(location.href) in the URI does not appear after a
 question mark. I sort of got it working  by changing the URI to 
 org-protocol://capture://?x=+encodeURIComponent(l)+/+...
 and then added the same three characters in
 org-protocol-check-filename-for-protocol:
  (regexp-quote (plist-get (cdr prolist) :protocol)) :/+\\(\\?x=\\)?)))

 - Florian.



[O] [bug] Org link dialog escapes URL spaces incorrectly

2011-11-01 Thread Jeff Horn
Org-mode version 7.7 (release_7.7.404.ga17c.dirty)
GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev

Inserting a link through the link dialog doesn't escape URLs with
spaces properly. Where a space is '%20', org will insert the link as
'%2520'. I'm not certain of URL escape codes, but could org be trying
to escape the % sign? Perhaps a missing slash in a regexp somewhere?

1) Use =C-c C-l= to use dialog. Paste a link, like the following.

http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf

2) Use =C-c C-o= to open the link. Be weirded out about a 404. Inspect URL.

,[ Actual ]
| - [ ] 
[[http://www.dartmouth.edu/~dirwin/Did%2520France%2520Cause%2520the%2520Great%2520Depression.pdf][Link
Description]]
`

,[ Expected ]
| - [ ] 
[[http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf][Link
Description]]
`

--
Jeffrey Horn
http://www.failuretorefrain.com/jeff/



[O] Pass LaTeX exporter option prior to \documentclass

2011-11-01 Thread John Hendy
Hi,

I'm creating a beamer presentation and screencasting a walkthrough of
it for work. I wanted to use impress!ve, but was getting errors about
there being no pages in the document. [1] In looking this error up, it
seems that impressive requires pdf version 1.4, which can be passed
with this:

\pdfminorversion=4

Unfortunately, exporting via Orgmode causes this error with that command:

,---
| ! pdfTeX error (setup): \pdfminorversion cannot be changed after data is
| written to the PDF file.
`---

In searching that error, I found the 1.4 documentation, which states:[2]

,---
| it probably means that some package loaded before pdf14 did write
data to the PDF file.
| In case the document class is (indirectly) doing it, you’ll need to
load pdf14 even before the
| \documentclass command, using \RequirePackage{pdf14} as the first
line of your source file.
`---

Using this suggestion solves my problem.

There doesn't seem to be a way to get this as the first line via
Orgmode; I have to export and then go to the .tex file directly to
change it. Any suggestions? I realize this is a pretty fringe case. If
it's one where it's just not worth it to implement something if
nothing already exists, that's completely acceptable to me. I just
thought I'd bring it up! It's primarily a nuisance because impressive
hasn't been updated in about a year. I wouldn't normally use it, but
the ability to zoom, use a spotlight for the mouse, and so on are
just really neat for something like this.

[1] http://impressive.sourceforge.net/
[2] ftp://152.19.134.44/CTAN/macros/latex/contrib/pdf14/pdf14.pdf


Thanks,
John



Re: [O] Pass LaTeX exporter option prior to \documentclass

2011-11-01 Thread suvayu ali
Hi John,

On Wed, Nov 2, 2011 at 03:22, John Hendy jw.he...@gmail.com wrote:

 I'm creating a beamer presentation and screencasting a walkthrough of
 it for work. I wanted to use impress!ve, but was getting errors about
 there being no pages in the document. [1] In looking this error up, it
 seems that impressive requires pdf version 1.4, which can be passed
 with this:

 \pdfminorversion=4


Disclaimer: What follows is an extremely hacky untested solution using
some shell foo.

By default org-latex-to-pdf-process is bound to something like this:

pdflatex -interaction nonstopmode -output-directory %o %f

You could try replacing that with the following:

pdflatex -interaction nonstopmode -output-directory %o
\pdfminorversion=4 $(cat %f)

Hope this helps.

-- 
Suvayu

Open source is the future. It sets us free.



[O] [OT] s/mime / mail encryption

2011-11-01 Thread Marcelo de Moraes Serpa
A bit off topic but related I think...

I've started using gpg to encrypt org-mode entries and it's amazing. I then
started to realize that I wasn't paying enough attention to security of my
own sensitive data. Scan of documents spread around without encryption
(also looking for a pragmatic way to encrypt whole files in OSX) and
specially email of sensitive data and documents.

I've then found out about S/MIME? I don't see it as widespread, I only
found geeky tutorials (some are quite comprehesive) but nothing really
mainstream. I also found a bit of material talking about encryption of
emails with gpg.

Do you guys ever encrypt your emails? I must say I never did, but it
doesn't sound bad for sensitive data, and if you have a business and or
need to deal with services that require your business or personal documents
(or any other sensitive data for that matter) I think that it could be a
good choice.

What do you think?

- Marcelo.


Re: [O] custom IDs not exported

2011-11-01 Thread Nick Dokos
Sten Lindner s.lind...@stenlindner.de wrote:

 On Sat, Jun 11, 2011 at 11:12:26PM -0400, Nick Dokos wrote:
  
  I have a minimal patch that I think fixes this problem, but there are
  other underscores used in various places in org-html.el so there might
  be additional problems. I'd appreciate it if you (and/or others) test it
  and report not only on this problem but on any other problems you find.
 
 I'm having the same problem when exporting to Docbook, custom IDs are
 being ignored.
 
 For example, when I export some org-mode text using C-c C-e D:
 
 * heading1
   :PROPERTIES:
   :CUSTOM_ID: h1
   :END:
 
 ** heading2
   :PROPERTIES:
   :CUSTOM_ID: h2
   :END:
 
 some links:
 - see [[#h1][heading1]]
 - see [[#h2][heading2]]
 
 I' getting the following XML output:
 
 section xml:id=sec-1
 titleheading1 /title
 section xml:id=sec-1_1
 titleheading2 /title
 para
 some links:
 /para
 itemizedlist
 listitem
 parasee link linkend=h1heading1/link
 /para
 /listitem
 listitem
 parasee link linkend=h2heading2/link
 /para
 /listitem
 /itemizedlist
 /section
 /section
 /article
 
 I would expect to see my custom IDs H1 and H2 but instead get
 auto-generated IDs sec-1 and sec-1_1.
 
 I'm using the latest org-mode version 7.7.
 
 best regards,
 Sten
 
 -- 
 Sten Lindner
 
 e-mail: s.lind...@stenlindner.de



This is because org-docbook.el does not implement custom ID handling at
all. I don't know if Baoqiu Cui, the author of org-docbook.el, watches
this list any longer (I haven't seen any mail from him for some time):
if he is around, he would be the logical person to fix it.  But if you
are interested in fixing this problem, I'd be happy to provide
guidance.[fn:1]

The problem is the following code in the function
org-export-docbook-level-start in lisp/org-docbook.el:

  ...
  (setq section-number (org-section-number level))
  (insert (format \nsection xml:id=\%s%s\\ntitle%s/title
  org-export-docbook-section-id-prefix
  (replace-regexp-in-string \\. _ section-number)
  ...

As you can see, the xml id is formed from
org-export-docbook-section-id-prefix (which has the value sec-) and
the section-number (which is 1 for the top level heading and 1.1 for
the second level heading). We replace periods with underscores in the
section number and then construct the id as sec-1_1. But there is no
provision anywhere for translating to custom IDs.

So one necessary change in order to conform to the changed convention is
to replace periods with hyphens in the section number. But in addition
to that, the xml id will have to be constructed differently if there is
a custom ID around.

Custom ids are passed to this function through a (dynamically scoped)
variable called org-export-preferred-target-alist which in the case
below has the value

((sec-1-1 . h2) (sec-1 . h1))

This variable provides the translations from the standard to the custom
IDs.

org-html.el provides a template to follow in reorganizing the above code
to do the translation. If you look at org-html-level-start [fn:2],
you'll find the following code

(setq href (cdr (assoc (concat sec- snu) 
org-export-preferred-target-alist)))
...
(setq href (org-solidify-link-text (or href (concat sec- snu
(insert (format \ndiv id=\outline-container-%s\ 
class=\outline-%d%s\\nh%d id=\%s\%s%s/h%d\ndiv 
class=\outline-text-%d\ id=\text-%s\\n
suffix level (if extra-class (concat   extra-class) 
)
level href
extra-targets
title level level suffix))

In this case, snu is the section number (with periods already replaced
by hyphens).  The local variable href is used to construct the id: the
conventional section number (sec-1-1 e.g.) is looked up in the alist
and it is either found, in which case href is set to the translation
(h2) or it is not found, in which case href is set to nil. Then the
second setq sets it to either the translated value or, if that is nil,
to the conventional value (sec-1-1). That is then used to fill in the
id in the html code.

With this information, do you think you could get a patch together?
Let me know if you have questions.

Nick

Footnotes:

[fn:1] For legal reasons, I cannot fix it myself.

[fn:2] As an aside, note the inconsistency in the function names. Bastien,
   is this worth fixing?



[O] How to format really long #+whatever lines

2011-11-01 Thread Robert McIntyre
In my literate org projects at http://aurellem.com/, I often have to
use very long lines such as:

#+description: Capture video from a JMonkeyEngine3 Application with
Xuggle, and use gstreamer to compress the video to upload to YouTube.

#+begin_src clojure :noweb yes :tangle ../src/pokemon/types.clj :var
pokemon-table-gen-one=pokemon-table-gen-one :var
pokemon-table-gen-two=pokemon-table-gen-two :exports none

They wrap off the end of my screen and are hard to edit.

Is there a way to use multiple lines to achieve the same effect?  I
couldn't find anything in the org manual.

sincerely,
--Robert McIntyre