Re: [O] wrap long table formula
Carsten Dominik 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
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"
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"
Hello, Eric Schulte writes: > Nicolas Goaziou 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"
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
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<=\"\"")
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)]
Hello,
Bernt Hansen writes:
> Nicolas Goaziou writes:
>
>> Bernt Hansen 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
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
>> 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 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)]
Hi Nicolas, Nicolas Goaziou writes: > Bernt Hansen writes: > >> Nicolas Goaziou writes: >> >>> Bernt Hansen 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"
Nicolas Goaziou 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
Christian Moe 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
Eric Schulte 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 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
Nick Dokos 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
Nick Dokos writes: > Nick Dokos 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"
Eric Schulte 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
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"
Nicolas Goaziou writes:
> Eric Schulte 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
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 S
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
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
Nick Dokos writes:
> Christian Moe 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"
Christian Moe 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
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
|
| http://www.w3.org/1998/Math/MathML";>
|
|
| b
| =
| 23
|
|
`
2. I am copy pasting the extra "stuff" that gets attached to the latex
fragment before it get "latex" ed and "dvipng"ed.
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
henry atting wrote:
> Nick Dokos writes:
>
> > Christian Moe 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
> 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
Myles
(I have read the followup post to this set of questions)
Myles English writes:
>>> On Mon, 31 Oct 2011 03:41:18 +0530, Jambunathan K said:
>
> > Myles English 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"
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
>> 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
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
> 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"
Christian Moe 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
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 st
Re: [O] custom IDs not exported
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: heading1 heading2 some links: see heading1 see heading2 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
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
Michael Brand 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
[Aaaargh: premature communication - apologies to all and let me try again] Michael Brand 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)]
Nicolas Goaziou writes: > Hello, > > Bernt Hansen writes: > >> Nicolas Goaziou writes: >> >>> Bernt Hansen 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
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
Hi Bastien and all, On Sun, 30 Oct 2011 09:48:06 +0100 Bastien wrote: > Suvayu Ali 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 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
Florian Hars 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
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
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
Hi John, On Wed, Nov 2, 2011 at 03:22, John Hendy 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
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
Sten Lindner 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:
>
>
> heading1
>
> heading2
>
> some links:
>
>
>
> see heading1
>
>
>
> see heading2
>
>
>
>
>
>
>
> 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 "\n\n%s"
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 "\n\n%s%s\n\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 #+ lines
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
