Re: [O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]

[David Maus]

At Sat, 19 Nov 2011 21:37:08 -0500,
Bernt Hansen wrote:
>
>
> Consider the following org file:
>
> --8<---cut here---start->8---
> * Orig Task 1
> SCHEDULED: <2011-11-19 Sat +1w>
> :LOGBOOK:
> - Note taken on [2011-11-19 Sat 21:24] \\
>   foo
> CLOCK: [2011-11-18 Fri 20:30]--[2011-11-18 Fri 21:24] =>  0:54
> CLOCK: [2011-11-19 Sat 20:23]--[2011-11-19 Sat 21:23] =>  1:00
> :END:
> [2011-11-19 Sat 21:23]
> --8<---cut here---end--->8---
>
> This is a repeating task with some clock time on it.
>
> Now I need to change the 2nd occurrence from now so I clone the task to
> create 2 more followed by the repeater as follows:
>
> On the task do C-c C-x c 2 RET +1w RET
>
> Now I get this so I can edit one of the individual entries
>
> --8<---cut here---start->8---
> * Orig Task 1
> SCHEDULED: <2011-11-19 Sat>
> :LOGBOOK:
> - Note taken on [2011-11-19 Sat 21:24] \\
>   foo
> :END:
> [2011-11-19 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-11-26 Sat>
> :LOGBOOK:
> - Note taken on [2011-11-26 Sat 21:24] \\
>   foo
> :END:
> [2011-11-26 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-12-03 Sat>
> :LOGBOOK:
> - Note taken on [2011-12-03 Sat 21:24] \\
>   foo
> :END:
> [2011-12-03 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-12-10 Sat +1w>
> :LOGBOOK:
> - Note taken on [2011-12-10 Sat 21:24] \\
>   foo
> :END:
> [2011-12-10 Sat 21:23]
> --8<---cut here---end--->8---
>
> I have the entries I want but my original clock lines have been deleted.
> I would expect this behaviour for the newly created clones only - not
> the original entry.
>
> I ran into this for a weekly meeting task I cloned and ended up
> recovering my clock lines from my hourly git repository but this
> shouldn't be necessary.
>
> I'm also not sure exactly why I get 3 entries when I ask for two --
> maybe that's a special case of the repeater in the original task but it
> feels weird.

I can confirm this bug for

Org-mode version 7.7 (release_7.7.583.gedef1)

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
2010-12-11 on raven, modified by Debian

Looks like 516b2fbb8763788585ac6a9f60ad7d51c4b0aab3 is the culprit:
`template' also contains the original entry.

I'll see to provide a fix for this.

Best,
  -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpMkJnxOhRnE.pgp
Description: PGP signature

Re: [O] [test] Mark tests with missing dependencies as "expected to fail"

[David Maus]

At Sun, 13 Nov 2011 12:31:20 -0700,
Eric Schulte wrote:
>
> [1  ]
> David Maus  writes:
>
> > Hi Eric,
> >
> > At Tue, 18 Oct 2011 10:22:34 -0600,
> > Eric Schulte wrote:
> >> Hi David,
> >>
> >> I agree it would be preferable to note that not all tests are run when
> >> dependencies are missing, although I don't think it is extremely
> >> important.  I think some version of the above would be worthwhile if it
> >> could be done in a file-wide manner (as are the current dependency
> >> checks) and wouldn't require duplicating the dependency check or
> >> changing every test form individually.  Perhaps a file-local-variable
> >> could be used to expect failures for every form defined in the file?
> >
> > I tried the approach with a file-local variable but it didn't work
> > out: A macro can be expanded at any time, i.e. looks like there is no
> > way to obtain a reference to the buffer where the macro is defined at
> > expansion time.
> >
> > But finally came up with this one:
> >
>
> Nice macro,
>
> The only downside I see is the requirement to wrap every single deftest
> form which (to me) is too much overhead for too little payoff.  How
> about the following which will register a failing test for each file of
> tests not loaded due to missing dependencies.

The macro operates not just on a single `ert-deftest' form, but all
deftests in BODY. It kind-of works like a file local variable.

The current solution does its job, too -- so there's no need to use
this macro. Getting feedback about tests not run because of missing
dependencies is all I every wanted.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpkNkO2Z5yxV.pgp
Description: PGP signature

Re: [O] [ANN] Org Elements in contrib

[Eric Abrahamsen]

On Tue, Nov 22 2011, Nicolas Goaziou wrote:

> Hello,
>
>
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.

This looks great! Is the eventual idea to use this library for other
basic org functionality? It seems ideal for replacing the guts of things
like `org-scan-tags' and family.

-- 
GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.6)
 of 2011-11-07 on pellet
Org-mode version 7.7 (release_7.7.578.ge3ec9)

Re: [O] [beamer] Can I just export one frame?

[zwz]

Herbert Sitz  writes:

> zwz  gmail.com> writes:
>
>> It takes long to export the whole file when it contains many babel
>> stuff. And in many cases, I just want to check if the current frame is
>> arranged as expected. SO I just want to know if there is some
> convenient
>> way to export just one frame without tagging all the other frames as
> :noexport.
>> 
>
> Have you tried just tagging the tree you want with :export:? Once that
> select
> tag is present in the buffer Org will automatically exclude any trees
> that don't
> have it.  From the docs:
>
> "Org first checks if any of the select tags is present in the buffer. If
> yes,
> all trees that do not carry one of these tags will be excluded. If a
> selected
> tree is a subtree, the heading hierarchy above it will also be selected
> for
> export, but not the text below those headings. "
> http://orgmode.org/manual/Selective-export.html#index-export_002c-selective-by-tags-or-TODO-keyword-1424

I did not know this! It is what I want. Thanks.

Re: [O] HTML export and Zotero-friendly headers

[Erik Hetzner]

At Mon, 21 Nov 2011 13:14:02 -0800,
Erik L. Arneson wrote:
> 
> On Mon, 21 Nov 2011, Christian Moe wrote:
> > Hi,
> >
> > Does Erik Hetzner's zotero-plain work for you?
> 
> I thought zotero-plain was used to add citations.  What I'm trying to do
> is use org-mode to export HTML files with Zotero-friendly headers that
> the Zotero plugin will pick-up on in the browser.
> 
> I can make the COinS  snippets myself using the tool available on
> the COinS website, but it would be handy if org-mode could do that
> automatically using the org header data that already exists.

Hi Erik,

There has been some discussion recently of export to ODT with
citations. Jambunathan K has outlined a way of doing this using a
binary added to zotero-plain, zotcite. This might be repurposed for an
HTML export.

best, Erik

Sent from my free software system .

Re: [O] Add publishing with utf8

[Nick Dokos]

sindikat  wrote:

> I use standard org-mode methods to publish my projects to
> html. However by default they are published with tag  http-equiv="Content-Type" content="text/html;charset=iso-8859-1"/>,
> however i need charset to be changed to "utf8", as i am using Russian
> in my blog too. Please make it possible somehow. Best wishes.
> 

My html files are exported with charset=utf-8. I believe that that's
because my org-mode buffers are utf-8 and ultimately because I've
set LANG=en_US.UTF-8.

Try the following when visiting your org file (actually, a backup of your org 
file :-))

 o C-x RET f utf-8 RET

 o Save the file.

 o Then export it to HTML.

HTH,
Nick

Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

Hi Torsten,

Torsten Anders  writes:

> Dear Sebastien and Eric,
>
> Thanks a lot for your kind replies. However, this is not yet quite what I am 
> after.
>
> I want to be able to manually execute each code block, but not
> automatically whenever the whole document is rendered. So, I would
> always switch on/off "eval never". Hm...
>

I've just pushed up a patch which adds a new option to the "eval" header
argument.  Setting eval to "non-export" will now allow interactive
evaluation, but will inhibit code block evaluation during export.  This
should address your need as I understand it.

>
> I will try out the ":cache" header argument. However, again this does
> not work so well, because for the languages I am using the :file
> argument does not work very well (I have to manually change
> extensions, so I include the resulting file links by hand anyway and
> set :results to silent.
>
> So, I it sounds like few org-babel users is really running larger
> applications in their code blocks which can delay the export of the
> whole document considerably.
>

I would not jump to that conclusion.  I have used babel code blocks to
cache the results of very long running results, however between the
:cache header argument and the ability to manually disassociate
generated results from code blocks I have not had any problems
inhibiting execution during export.

Best -- Eric

>
> Anyway, thanks a lot for your feedback.
>
> Best wishes,
> Torsten
>
>
>
>

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

Re: [O] [OT]: Search for missing :END:

[Markus Heller]

Nick Dokos  writes:

> Markus Heller  wrote:
>
>
>> AS for an example, I'm in one of my org files and I do C-TAB and get the
>> following error:
>> 
>> OVERVIEW
>> CONTENTS...done
>> SHOW ALL
>> if: :END: line missing at position 18720
>> Quit
>> Mark set
>> 
>> Where is position 18720?  I apologize if this is a stupid question, but
>> I can't seem to figure this out ...
>> 
>
> M-x goto-char RET 18720 RET
>
> will take you there, but it's probably at the very end of the buffer: search 
> backwards
> for :PROPERTIES: and you should be able to find it (if your diagnosis is
> indeed correct).

Thanks to Nick and the other posters for an enlightening answer.  This
worked beautifully :)

Thanks again and Cheers
Markus, who knew that there was some easy way to solve this but couldn't
figure it out himself

Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

Dear Sebastien and Eric,

Thanks a lot for your kind replies. However, this is not yet quite what I am 
after.

I want to be able to manually execute each code block, but not automatically 
whenever the whole document is rendered. So, I would always switch on/off "eval 
never". Hm... 

I will try out the ":cache" header argument. However, again this does not work 
so well, because for the languages I am using the :file argument does not work 
very well (I have to manually change extensions, so I include the resulting 
file links by hand anyway and set :results to silent.

So, I it sounds like few org-babel users is really running larger applications 
in their code blocks which can delay the export of the whole document 
considerably. 

Anyway, thanks a lot for your feedback.

Best wishes,
Torsten

Re: [O] [OT]: Search for missing :END:

[Jonathan Leech-Pepin]

I just tested this.

M-x goto-char RET  RET ;; In this case 18720

Sends you directly to the end of your :PROPERTIES: line that does not have
an associated :END:.

You'll simply have to then add :END: after the appropriate properties, or
remove the :PROPERTIES: line that shouldn't be present (as the case may be).

Jon

On Mon, Nov 21, 2011 at 6:54 PM, Nick Dokos  wrote:

> Markus Heller  wrote:
>
>
> > AS for an example, I'm in one of my org files and I do C-TAB and get the
> > following error:
> >
> > OVERVIEW
> > CONTENTS...done
> > SHOW ALL
> > if: :END: line missing at position 18720
> > Quit
> > Mark set
> >
> > Where is position 18720?  I apologize if this is a stupid question, but
> > I can't seem to figure this out ...
> >
>
> M-x goto-char RET 18720 RET
>
> will take you there, but it's probably at the very end of the buffer:
> search backwards
> for :PROPERTIES: and you should be able to find it (if your diagnosis is
> indeed correct).
>
> Nick
>
>

Re: [O] [OT]: Search for missing :END:

[Nick Dokos]

Markus Heller  wrote:

> Unfortunately, I cannot install cygwin on my work computer.  I'll have
> to figure something else out ...
> 

Just copy the file to a Linux/Unix/OSX/... machine and do the searches there.
USB sticks were invented for exactly that purpose :-)

> AS for an example, I'm in one of my org files and I do C-TAB and get the
> following error:
> 
> OVERVIEW
> CONTENTS...done
> SHOW ALL
> if: :END: line missing at position 18720
> Quit
> Mark set
> 
> Where is position 18720?  I apologize if this is a stupid question, but
> I can't seem to figure this out ...
> 
> Thanks again
> Markus
> 
> 

Re: [O] [OT]: Search for missing :END:

[Nick Dokos]

Markus Heller  wrote:


> AS for an example, I'm in one of my org files and I do C-TAB and get the
> following error:
> 
> OVERVIEW
> CONTENTS...done
> SHOW ALL
> if: :END: line missing at position 18720
> Quit
> Mark set
> 
> Where is position 18720?  I apologize if this is a stupid question, but
> I can't seem to figure this out ...
> 

M-x goto-char RET 18720 RET

will take you there, but it's probably at the very end of the buffer: search 
backwards
for :PROPERTIES: and you should be able to find it (if your diagnosis is
indeed correct).

Nick

Re: [O] [OT]: Search for missing :END:

[Andrew Stribblehill]

My guess is that it's the 18720th byte of the file. To get there, go
to the start of your buffer and type M-x goto-char 18720


On Mon, Nov 21, 2011 at 11:27 PM, Markus Heller  wrote:
> Nick Dokos  writes:
>
>> Markus Heller  wrote:
>>
>>> Hello all,
>>>
>>> I have an OT request that can hopefully be answered by emacs gurus in
>>> less than a minute:
>>>
>>> I'm looking for an emacs search expression that finds :PROPERTIES:
>>> *without* a matching :END: ...
>>>
>>
>> If you mean a regexp, you are wasting your time[fn:1]. Regexps are
>> powerful, but their range of applicability is limited to regular
>> languages and even then, you have to worry about their efficiency. The
>> above *is* a regular language: if P stands for :PROPERTIES: and E stands
>> for :END:, then the regexp is
>>
>>     ([^EP]*P[^EP]*E)*
>>
>> In words, the stuff inside the parens says: 0 or more "other" things
>> (non-P and non-E), followed by a P, followed by 0 or more "other"
>> things, followed by an E. You can then have 0 or more of the
>> parenthesized things. This will succeed on well formed "sentences" and
>> fail on others.  But it might have to backtrack over the inner [^EP]*
>> matches and then the outer matches, and rescan arbitrarily long
>> stretches, which in the worst case, can turn your search into an
>> exponentially slow descent into the abyss. You might be able to write
>> non-greedy regexps that might behave better in this case. In most cases,
>> you'd end up with a horrendous-looking regexp: good luck trying to
>> understand it next week. That's my biggest problem with complicated regexps.
>>
>> However, a change of tool will simplify the problem enormously. E.g. here's
>> a simple algorithm that can be used for this kind of problem:  start a
>> nesting depth at 0 - when you see a P, increment the nesting depth by 1;
>> when you see an E, decrement it by 1. If the nesting depth ever becomes
>> something other than 0 or 1, you got a problem - also, if at EOF, the
>> nesting depth is not 0, you got a problem. Easy variations of this will
>> check well-formedness even when nesting *is* allowed.
>>
>> You can easily write such a program in any language you are familiar
>> with (it does not have to be elisp, although you *can* write it in
>> elisp - personally, I'd use awk).
>>
>> But assuming that you are getting some error from org, you don't know
>> where the problem is and you are trying to find it, it will be simpler
>> to just use egrep:
>>
>>     grep -E -n ':PROPERTIES:|:END:' foo.org
>>
>> will filter out the relevant lines, so all you have to do is scan the
>> output by eye and spot any irregularity (consecutive :PROPERTIES: or
>> consecutive :END: lines). Even if you have hundreds of them, that's
>> *easy* for humans to do.[fn:2]
>>
>> Or, if you prefer, you can write trivial validation programs to operate
>> on the output, e.g.:
>>
>>         grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP | 
>> wc -l
>>       grep END foo.out | wc -l
>>
>> (the counts 'd better be the same).
>>
>> or
>>
>>       grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk
>>
>> where foo.awk implements the nesting depth algorithm above - something
>> like this:
>>
>> #! /bin/bash
>>
>> awk '
>> BEGIN          { d = 0;}
>> /:PROPERTIES:/ { d++; if (d > 1) { print $1, $d; exit; }}
>> /:END:/        { d--; if (d < 0) { print $1, $d; exit; }}
>> END            { if (d != 0) { print $1, $d; }}'
>>
>>
>> Even on Windoze, you can probably do all this stuff with cygwin.
>
> Hi Nick,
>
> thanks for this informative reply.
>
> Unfortunately, I cannot install cygwin on my work computer.  I'll have
> to figure something else out ...
>
> AS for an example, I'm in one of my org files and I do C-TAB and get the
> following error:
>
> OVERVIEW
> CONTENTS...done
> SHOW ALL
> if: :END: line missing at position 18720
> Quit
> Mark set
>
> Where is position 18720?  I apologize if this is a stupid question, but
> I can't seem to figure this out ...
>
> Thanks again
> Markus
>
>
>

Re: [O] Subscription to the mailing list

[Chris Malone]

Well, that message got through to the list :).

Chris

On Nov 21, 2011, at 8:45 AM, Stelian Iancu wrote:

> Hi,
> 
> Is the subscription to the mailing list working at the moment? Because
> I tried today to subscribe and I didn't get the confirmation mail. I
> tried a couple of hours ago and still nothing.
> 
> Thanks,
> S.
> 

-
Chris Malone (mal...@ucolick.org)

Dept. of Astronomy and Astrophysics
UC Santa Cruz
1156 High Street
Santa Cruz, CA 95064-1077

phone: 831-459-3809
-

Re: [O] [OT]: Search for missing :END:

[Markus Heller]

Nick Dokos  writes:

> Markus Heller  wrote:
>
>> Hello all,
>> 
>> I have an OT request that can hopefully be answered by emacs gurus in
>> less than a minute:
>> 
>> I'm looking for an emacs search expression that finds :PROPERTIES:
>> *without* a matching :END: ...
>> 
>
> If you mean a regexp, you are wasting your time[fn:1]. Regexps are
> powerful, but their range of applicability is limited to regular
> languages and even then, you have to worry about their efficiency. The
> above *is* a regular language: if P stands for :PROPERTIES: and E stands
> for :END:, then the regexp is
>
> ([^EP]*P[^EP]*E)*
>
> In words, the stuff inside the parens says: 0 or more "other" things
> (non-P and non-E), followed by a P, followed by 0 or more "other"
> things, followed by an E. You can then have 0 or more of the
> parenthesized things. This will succeed on well formed "sentences" and
> fail on others.  But it might have to backtrack over the inner [^EP]*
> matches and then the outer matches, and rescan arbitrarily long
> stretches, which in the worst case, can turn your search into an
> exponentially slow descent into the abyss. You might be able to write
> non-greedy regexps that might behave better in this case. In most cases,
> you'd end up with a horrendous-looking regexp: good luck trying to
> understand it next week. That's my biggest problem with complicated regexps.
>
> However, a change of tool will simplify the problem enormously. E.g. here's
> a simple algorithm that can be used for this kind of problem:  start a
> nesting depth at 0 - when you see a P, increment the nesting depth by 1;
> when you see an E, decrement it by 1. If the nesting depth ever becomes
> something other than 0 or 1, you got a problem - also, if at EOF, the
> nesting depth is not 0, you got a problem. Easy variations of this will
> check well-formedness even when nesting *is* allowed.
>
> You can easily write such a program in any language you are familiar
> with (it does not have to be elisp, although you *can* write it in
> elisp - personally, I'd use awk).
>
> But assuming that you are getting some error from org, you don't know
> where the problem is and you are trying to find it, it will be simpler
> to just use egrep:
>
> grep -E -n ':PROPERTIES:|:END:' foo.org
>
> will filter out the relevant lines, so all you have to do is scan the
> output by eye and spot any irregularity (consecutive :PROPERTIES: or
> consecutive :END: lines). Even if you have hundreds of them, that's
> *easy* for humans to do.[fn:2]
>
> Or, if you prefer, you can write trivial validation programs to operate
> on the output, e.g.:
>
> grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP | 
> wc -l
>   grep END foo.out | wc -l
>
> (the counts 'd better be the same).
>
> or
>
>   grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk
>
> where foo.awk implements the nesting depth algorithm above - something
> like this:
>
> #! /bin/bash
>
> awk '
> BEGIN  { d = 0;}
> /:PROPERTIES:/ { d++; if (d > 1) { print $1, $d; exit; }}
> /:END:/{ d--; if (d < 0) { print $1, $d; exit; }}
> END{ if (d != 0) { print $1, $d; }}'
>
>
> Even on Windoze, you can probably do all this stuff with cygwin.

Hi Nick, 

thanks for this informative reply.

Unfortunately, I cannot install cygwin on my work computer.  I'll have
to figure something else out ...

AS for an example, I'm in one of my org files and I do C-TAB and get the
following error:

OVERVIEW
CONTENTS...done
SHOW ALL
if: :END: line missing at position 18720
Quit
Mark set

Where is position 18720?  I apologize if this is a stupid question, but
I can't seem to figure this out ...

Thanks again
Markus

[O] Add publishing with utf8

[sindikat]

I use standard org-mode methods to publish my projects to html. However by 
default they are published with tag content="text/html;charset=iso-8859-1"/>, however i need charset to be 
changed to "utf8", as i am using Russian in my blog too. Please make it 
possible somehow. Best wishes.

[O] Subscription to the mailing list

[Stelian Iancu]

Hi,

Is the subscription to the mailing list working at the moment? Because
I tried today to subscribe and I didn't get the confirmation mail. I
tried a couple of hours ago and still nothing.

Thanks,
S.

Re: [O] Bugs in lisp/ob-lilypond.el

[Martyn Jago]

Martyn Jago  writes:
Hi Torsten
 
> Hi Torston
>
> Torsten Anders  writes:
>
>> Also, the setting results: silent seems to be ignored. 
>>
>> Best wishes,
>> Torsten
>>
>>
>> On 19 Nov 2011, at 15:22, Torsten Anders wrote:
>>
>>> Dear Martyn Jago, dear all,
>>> 
>>> I just pulled the latest version of Org mode and noticed a few bugs
>>> in the Lilypond support of Org babel that have not been there in the
>>> previous version (so far I was still using version 7.6).
>>> 
>>> In general, there seems to be problems in parsing the line that starts 
>>> #+begin_src lilypond. More specifically, 
>>> 
>>> - Global :noweb settings are now ignored
>>> - Any settings after the setting :file will be added to output file name!
>>> - Settings after :noweb yes cause trouble (disable this setting)
>>> 
>
> Thanks for the heads-up Torsten - there have been many changes to the
> bare-metal Org as you probably are aware. Your observations will come in
> very useful to sort out the transition to the new improved order (which
> I am totally in favor of by the way), and the details you provide will
> prove very useful.
>
> Certainly consider checking out a `less hot' release to get working
> again ( i.e. git checkout release_7.7 ). In the mean-time I will work on
> compatibility (tomorrow hopefully) - and better regression tests.
>
> Great to hear you're making use of ob-lilypond by the way!
>
> Best, Martyn
>
>>> Again, thanks for lisp/ob-lilypond.el in the first place.

(Apologies for miss-spelling your name previously).

I'm not seeing this. I've updated my examples to embrace the standard
source block syntax, and everything seems to be working for me - which
probably means I haven't considered your use-case. 

I've also moved my ob-lilypond documentation to Worg (but appear to have
broken the Worg build mechanism, so that is little help here), but it
would be useful to know if the examples at
http://github.com/mjago/ob-lilypond/examples work for you.

Some more detail would be useful - could you provide:
 -  a broken sample
 - Emacs version 
 - Lilypond version? 

Also are you using arrange-mode (C-h v ly-arrange-mode . Nil is no).

Regarding the `standard source block syntax', ensure that any #+srcname
or #+source commands are replaced with #+name, and update to the very
latest Org if you leave space in a `:var something = something-else'
assignment as I tend to do.

Best, Martyn
 
>>> 
>>> Best wishes,
>>> Torsten
>>> 
>>> --
>>> Dr Torsten Anders
>>> Course Leader, Music Technology
>>> University of Bedfordshire
>>> Park Square, Room A315
>>> torsten.and...@beds.ac.uk
>>> http://strasheela.sourceforge.net
>>> http://www.torsten-anders.de
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 

[O] [PATCH] Avoid lisp error with (org-deadline nil "+1d")

[Peter Münster]

* lisp/org.el (parse-time-weekdays): Must not be void.

TINYCHANGE
---
 lisp/org.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 253703b..41d418a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15229,7 +15229,7 @@ user."
 (setq org-read-date-analyze-futurep futurep)
 (list second minute hour day month year)))
 
-(defvar parse-time-weekdays)
+(defvar parse-time-weekdays nil)
 
 (defun org-read-date-get-relative (s today default)
   "Check string S for special relative date string.
-- 
1.7.3.4

Re: [O] [ANN] Org Elements in contrib

[Martyn Jago]

Nicolas Goaziou  writes:
Hi Nicolas

> Hello,
>
>
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.
>
> While it was written to be extensible, it is also an attempt to
> normalize current syntax and provide guidance for its evolution.
>
> Org syntax can be divided into three categories: "Greater elements",
> "Elements" and "Objects".
>
> An object can be defined anywhere on a line. It may span over more than
> a line but never contains a blank one. Objects belong to the following
> types: `emphasis', `entity', `export-snippet', `footnote-reference',
> `inline-babel-call', `inline-src-block', `latex-fragment', `line-break',
> `link', `macro', `radio-target', `statistics-cookie', `subscript',
> `superscript', `target', `time-stamp' and `verbatim'.
>
> An element always starts and ends at the beginning of a line. The only
> element's type containing objects is called a `paragraph'. Other types
> are: `comment', `comment-block', `example-block', `export-block',
> `fixed-width', `horizontal-rule', `keyword', `latex-environment',
> `babel-call', `property-drawer', `quote-section', `src-block', `table'
> and `verse-block'.
>
> Elements containing paragraphs are called greater elements. Concerned
> types are: `center-block', `drawer', `dynamic-block',
> `footnote-definition', `headline', `inlinetask', `item', `plain-list',
> `quote-block' and `special-block'.
>
> Greater elements (excepted `headline' and `item' types) and elements
> (excepted `keyword', `babel-call', and `property-drawer' types) can have
> a fixed set of keywords as attributes. Those are called "affiliated
> keywords", to distinguish them from others keywords, which are
> full-fledged elements. In particular, the "name" affiliated keyword
> allows to label almost any element in an Org buffer.
>
> Notwithstanding affiliated keywords, each greater element, element and
> object has a fixed set of properties attached to it. Among them, three
> are shared by all types: `:begin' and `:end', which refer to the
> beginning and ending buffer positions of the considered element or
> object, and `:post-blank', which holds the number of blank lines, or
> white spaces, at its end.
>
> Some elements also have special properties whose value can hold objects
> themselves (i.e. an item tag, an headline name, a table cell). Such
> values are called "secondary strings".
>
> Lisp-wise, an element or an object can be represented as a list. It
> follows the pattern (TYPE PROPERTIES CONTENTS), where: TYPE is a symbol
> describing the Org element or object. PROPERTIES is the property list
> attached to it. See docstring of appropriate parsing function to get an
> exhaustive list. CONTENTS is a list of elements, objects or raw strings
> contained in the current element or object, when applicable.
>
> An Org buffer is a nested list of such elements and objects, whose type
> is `org-data' and properties is nil.
>
> The first part of this file implements a parser and an interpreter for
> each type of Org syntax.
>
> The next two parts introduce two accessors and a function retrieving the
> smallest element containing point (respectively
> `org-element-get-property', `org-element-get-contents' and
> `org-element-at-point').
>
> The following part creates a fully recursive buffer parser. It also
> provides a tool to map a function to elements or objects matching some
> criteria in the parse tree. Functions of interest are
> `org-element-parse-buffer', `org-element-map' and, to a lesser extent,
> `org-element-parse-secondary-string'.
>
> The penultimate part is the cradle of an interpreter for the obtained
> parse tree: `org-element-interpret-data' (and its relative,
> `org-element-interpret-secondary').
>
> The library ends by furnishing a set of interactive tools for element's
> navigation and manipulation.
>
> More specifically, that last part includes some tools like
> `org-element-forward', `org-element-backward',
> `org-element-drag-forward', `org-element-drag-backward',
> `org-element-mark-element', `org-element-up',
> `org-element-unindent-buffer'... 
>
> For the impatient (well, not quite as you're still reading this), you
> can evaluate the following examples in an Org buffer :
>
>(org-element-parse-buffer)
>   (org-element-parse-buffer 'headline)
>(org-element-parse-buffer 'headline 'visible-only)
>
> Also, the following code will parse the buffer, interpret the parsed
> tree, and create a canonical copy of it (no indentation, lowercased
> blocks, standard keywords):
>
> #+begin_src org
> (let ((out (org-element-interpret-data (org-element-parse-buffer
>   (switch-to-buffer (get-buffer-create "*Bijectivep*"))
>   (erase-buffer)
>   (insert out)
>   (goto-char (point-min))
>   (org-mode))
> #+end_src
>
> Beside allowing to add keywords like "#+name:", "#+caption:" or
> "#+attr_latex:" to almost any Org element, it also introduces two less
> noticable chang

Re: [O] [OT]: Search for missing :END:

[Nick Dokos]

Markus Heller  wrote:

> Hello all,
> 
> I have an OT request that can hopefully be answered by emacs gurus in
> less than a minute:
> 
> I'm looking for an emacs search expression that finds :PROPERTIES:
> *without* a matching :END: ...
> 

If you mean a regexp, you are wasting your time[fn:1]. Regexps are
powerful, but their range of applicability is limited to regular
languages and even then, you have to worry about their efficiency. The
above *is* a regular language: if P stands for :PROPERTIES: and E stands
for :END:, then the regexp is

([^EP]*P[^EP]*E)*

In words, the stuff inside the parens says: 0 or more "other" things
(non-P and non-E), followed by a P, followed by 0 or more "other"
things, followed by an E. You can then have 0 or more of the
parenthesized things. This will succeed on well formed "sentences" and
fail on others.  But it might have to backtrack over the inner [^EP]*
matches and then the outer matches, and rescan arbitrarily long
stretches, which in the worst case, can turn your search into an
exponentially slow descent into the abyss. You might be able to write
non-greedy regexps that might behave better in this case. In most cases,
you'd end up with a horrendous-looking regexp: good luck trying to
understand it next week. That's my biggest problem with complicated regexps.

However, a change of tool will simplify the problem enormously. E.g. here's
a simple algorithm that can be used for this kind of problem:  start a
nesting depth at 0 - when you see a P, increment the nesting depth by 1;
when you see an E, decrement it by 1. If the nesting depth ever becomes
something other than 0 or 1, you got a problem - also, if at EOF, the
nesting depth is not 0, you got a problem. Easy variations of this will
check well-formedness even when nesting *is* allowed.

You can easily write such a program in any language you are familiar
with (it does not have to be elisp, although you *can* write it in
elisp - personally, I'd use awk).

But assuming that you are getting some error from org, you don't know
where the problem is and you are trying to find it, it will be simpler
to just use egrep:

grep -E -n ':PROPERTIES:|:END:' foo.org

will filter out the relevant lines, so all you have to do is scan the
output by eye and spot any irregularity (consecutive :PROPERTIES: or
consecutive :END: lines). Even if you have hundreds of them, that's
*easy* for humans to do.[fn:2]

Or, if you prefer, you can write trivial validation programs to operate
on the output, e.g.:

grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP | wc 
-l
grep END foo.out | wc -l

(the counts 'd better be the same).

or

grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk

where foo.awk implements the nesting depth algorithm above - something
like this:

--8<---cut here---start->8---
#! /bin/bash

awk '
BEGIN  { d = 0;}
/:PROPERTIES:/ { d++; if (d > 1) { print $1, $d; exit; }}
/:END:/{ d--; if (d < 0) { print $1, $d; exit; }}
END{ if (d != 0) { print $1, $d; }}'
--8<---cut here---end--->8---


Even on Windoze, you can probably do all this stuff with cygwin.

Nick

> Thanks and Cheers and sorry for the OT ...
> 
> Markus
> 
>

Footnotes:

[fn:1] In the (approximate) words of Jamie Zawinski: "You have a
   problem. You think 'I know, let me use regexps to solve it'. Now
   you have two problems."

[fn:2] Of course, if you have formatted your file perversely or done
other naughty things, this might not work. The point is that although
this is not foolproof, it should deal with the vast majority of
"reasonable" files out there.

[O] [PATCH] Timestamps: Fix org-schedule and org-deadline with absolute time arguments

[Peter Münster]

* lisp/org.el (org-add-planning-info): Treat absolute time too.

TINYCHANGE
---
 lisp/org.el |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index fffb0c1..3342b87 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12078,9 +12078,8 @@ be removed."
  default-input (and ts (org-get-compact-tod ts))
   (when what
(setq time
- (if (and (stringp time)
-  (string-match "^[-+]+[0-9]" time))
- ;; This is a relative time, set the proper date
+ (if (stringp time)
+ ;; This is a string (relative or absolute), set proper date
  (apply 'encode-time
 (org-read-date-analyze
  time default-time (decode-time default-time)))
@@ -14807,7 +14806,7 @@ The prompt will suggest to enter an ISO date, but you 
can also enter anything
 which will at least partially be understood by `parse-time-string'.
 Unrecognized parts of the date will default to the current day, month, year,
 hour and minute.  If this command is called to replace a timestamp at point,
-of to enter the second timestamp of a range, the default time is taken
+or to enter the second timestamp of a range, the default time is taken
 from the existing stamp.  Furthermore, the command prefers the future,
 so if you are giving a date where the year is not given, and the day-month
 combination is already past in the current year, it will assume you
-- 
1.7.3.4

Re: [O] HTML export and Zotero-friendly headers

[Erik L. Arneson]

On Mon, 21 Nov 2011, Christian Moe wrote:
> Hi,
>
> Does Erik Hetzner's zotero-plain work for you?

I thought zotero-plain was used to add citations.  What I'm trying to do
is use org-mode to export HTML files with Zotero-friendly headers that
the Zotero plugin will pick-up on in the browser.

I can make the COinS  snippets myself using the tool available on
the COinS website, but it would be handy if org-mode could do that
automatically using the org header data that already exists.

-- 
Erik L. Arneson 
  GPG Key ID : 1024D/62DA1D25   BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
  Office : +1.541.291.9776Skype : callto://pymander
   http://www.leisurenouveau.com/ http://www.transformason.org/

Re: [O] HTML export and Zotero-friendly headers

[Christian Moe]

Hi,

Does Erik Hetzner's zotero-plain work for you?

If so, I'd try this experiment: set zotero-default-bibliography-style 
to "COinS". Then insert a citation in Org using zotero-plain. In the 
link description, instead of a nicely formatted bibliographic 
reference, I imagine you should get the COinS data.


If that works, zotero-plain could be very easily extended with a 
function to insert COinS data for all items in zotero links, and it 
could be run as a hook on HTML export.


It hasn't worked for me lately, so I can't try the experiment myself.

Yours,
Christian


On 11/21/11 7:19 PM, Erik L. Arneson wrote:

Howdy,

I've just stumbled across Zotero and have been reading about how folks
are working to integrate it with org-mode, but from what I've read so
far, all of the work has been on the citation end.

Has anybody pursued creating Zotero-friendly headers/metadata in HTML
exports?  I use org-mode to manage a few websites and it would be handy
to have the HTML snippets generated automatically.  It looks like both
COinS[1] and Dublin Core are fairly straightforward.



I'm looking forward to hearing if anybody has done anything with this
yet.

Thanks,

Erik

Footnotes:
[1]  http://ocoins.info/

[O] [ANN] Org Elements in contrib

[Nicolas Goaziou]

Hello,


I've added org-element.el in contrib directory. It is a complete parser
and interpreter for Org syntax.

While it was written to be extensible, it is also an attempt to
normalize current syntax and provide guidance for its evolution.

Org syntax can be divided into three categories: "Greater elements",
"Elements" and "Objects".

An object can be defined anywhere on a line. It may span over more than
a line but never contains a blank one. Objects belong to the following
types: `emphasis', `entity', `export-snippet', `footnote-reference',
`inline-babel-call', `inline-src-block', `latex-fragment', `line-break',
`link', `macro', `radio-target', `statistics-cookie', `subscript',
`superscript', `target', `time-stamp' and `verbatim'.

An element always starts and ends at the beginning of a line. The only
element's type containing objects is called a `paragraph'. Other types
are: `comment', `comment-block', `example-block', `export-block',
`fixed-width', `horizontal-rule', `keyword', `latex-environment',
`babel-call', `property-drawer', `quote-section', `src-block', `table'
and `verse-block'.

Elements containing paragraphs are called greater elements. Concerned
types are: `center-block', `drawer', `dynamic-block',
`footnote-definition', `headline', `inlinetask', `item', `plain-list',
`quote-block' and `special-block'.

Greater elements (excepted `headline' and `item' types) and elements
(excepted `keyword', `babel-call', and `property-drawer' types) can have
a fixed set of keywords as attributes. Those are called "affiliated
keywords", to distinguish them from others keywords, which are
full-fledged elements. In particular, the "name" affiliated keyword
allows to label almost any element in an Org buffer.

Notwithstanding affiliated keywords, each greater element, element and
object has a fixed set of properties attached to it. Among them, three
are shared by all types: `:begin' and `:end', which refer to the
beginning and ending buffer positions of the considered element or
object, and `:post-blank', which holds the number of blank lines, or
white spaces, at its end.

Some elements also have special properties whose value can hold objects
themselves (i.e. an item tag, an headline name, a table cell). Such
values are called "secondary strings".

Lisp-wise, an element or an object can be represented as a list. It
follows the pattern (TYPE PROPERTIES CONTENTS), where: TYPE is a symbol
describing the Org element or object. PROPERTIES is the property list
attached to it. See docstring of appropriate parsing function to get an
exhaustive list. CONTENTS is a list of elements, objects or raw strings
contained in the current element or object, when applicable.

An Org buffer is a nested list of such elements and objects, whose type
is `org-data' and properties is nil.

The first part of this file implements a parser and an interpreter for
each type of Org syntax.

The next two parts introduce two accessors and a function retrieving the
smallest element containing point (respectively
`org-element-get-property', `org-element-get-contents' and
`org-element-at-point').

The following part creates a fully recursive buffer parser. It also
provides a tool to map a function to elements or objects matching some
criteria in the parse tree. Functions of interest are
`org-element-parse-buffer', `org-element-map' and, to a lesser extent,
`org-element-parse-secondary-string'.

The penultimate part is the cradle of an interpreter for the obtained
parse tree: `org-element-interpret-data' (and its relative,
`org-element-interpret-secondary').

The library ends by furnishing a set of interactive tools for element's
navigation and manipulation.

More specifically, that last part includes some tools like
`org-element-forward', `org-element-backward',
`org-element-drag-forward', `org-element-drag-backward',
`org-element-mark-element', `org-element-up',
`org-element-unindent-buffer'... 

For the impatient (well, not quite as you're still reading this), you
can evaluate the following examples in an Org buffer :

   (org-element-parse-buffer)
  (org-element-parse-buffer 'headline)
   (org-element-parse-buffer 'headline 'visible-only)

Also, the following code will parse the buffer, interpret the parsed
tree, and create a canonical copy of it (no indentation, lowercased
blocks, standard keywords):

#+begin_src org
(let ((out (org-element-interpret-data (org-element-parse-buffer
  (switch-to-buffer (get-buffer-create "*Bijectivep*"))
  (erase-buffer)
  (insert out)
  (goto-char (point-min))
  (org-mode))
#+end_src

Beside allowing to add keywords like "#+name:", "#+caption:" or
"#+attr_latex:" to almost any Org element, it also introduces two less
noticable changes:

  1. "#+label:" keywords are deprecated in favor of "#+name:". Though,
 for now, "label" is still considered as a synonym of "name".

  2. Protected HTML snippets (like @) are no longer supported, as
 they were too spec

[O] [OT]: Search for missing :END:

[Markus Heller]

Hello all,

I have an OT request that can hopefully be answered by emacs gurus in
less than a minute:

I'm looking for an emacs search expression that finds :PROPERTIES:
*without* a matching :END: ...

Thanks and Cheers and sorry for the OT ...

Markus

Re: [O] [BUG] Inconsistency in src block hiding

[Eric Schulte]

Nicolas Goaziou  writes:

> Eric Schulte  writes:
>
>> "name" is and should be an element of the `org-babel-data-names' list as
>> it is the preferred way to name data in an Org-mode file, e.g.,
>>
>> #+name: foo
>> - 1
>> - 2
>> - 3
>
> I agree.
>
>> The only reason that "tblname" and "results" are included in the list
>> are because "tblname" is used by other parts of Org-mode, and "results"
>> was retained because it was felt that a "name" line without an actual
>> name (e.g., as the results of an un-named code block) would look funny.
>>
>> I don't view the "results style" hiding as inconsistent
>
> It is inconsistent when keywords stack on top of each other. If you have
> only a "#+name:" keyword, block with fold at the "#+name:" level. If you
> have both "#+name:" and, for example "#+results" below, block will fold
> at the "#+result:" level and TAB will not respond at "#+name:".

Can you provide an example, I'm thinking that what you describe may not
be legal syntax.  For example

#+name: one
#+results: two
- 1
- 2

doesn't make any more sense than

#+name: one
#+name: two
- 1
- 2

> If you have, from top to bottom, "name", "results" "header", nothing
> will fold.  In all those cases, I think a consistent behaviour could
> be to hide the block, with any number of keywords above, and TAB
> pressed at any of them.
>

Yes, I would agree, the hiding should be smart enough to find the whole
unit and hide it.  I'll take a look at the code.

>
> I'm not sure that "#+results:" or "#+name:" keywords should allow to
> hide whole parts of the buffer. I realize that toggling "#+results:"
> visibility has been in core for a while. But now that every Org blob can
> have a "#+name" attached to it, one can hide almost anything in the
> buffer.
>
> Until now we could hide contents with headlines, blocks, drawers, and
> items (with an option to prevent it). And we had a global mechanism to
> handle visibility toggling just fine (namely S-TAB with different
> numbers of prefixes). But hiding independently each list, table or
> paragraph with no possibility to make them appear in groups just doesn't
> sound right.
>
> Hence, I suggest to think again about it: we can live happily with
> outlines, blocks and drawers as folding entities.
>

The hiding was added because code blocks occasionally generate *huge*
results which make it impossible to read further down in the buffer.
Hiding such large results can be very useful when you want to keep the
data in-buffer, but still want to be able to read down the page.

Is there a way to bring the hiding of results more in-line with the
other methods of hiding in Org-mode?  Should S-Tab be made to toggle the
hidden states of named entities as well as outline levels?

>
> Moreover, there is another problem related to that.
>
> `org-export-blocks-preprocess' will remove all "#+name:" keywords in the
> buffer.  It mustn't: again "#+name:" is a general naming mechanism for
> almost any Org syntax. It may/will be also used for other purpose than
> Babel. That information is important even after blocks have been
> processed.
>

I'll take a look at this and submit a patch.

Best -- Eric

>
>
> Regards,

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

[O] HTML export and Zotero-friendly headers

[Erik L. Arneson]

Howdy,

I've just stumbled across Zotero and have been reading about how folks
are working to integrate it with org-mode, but from what I've read so
far, all of the work has been on the citation end.

Has anybody pursued creating Zotero-friendly headers/metadata in HTML
exports?  I use org-mode to manage a few websites and it would be handy
to have the HTML snippets generated automatically.  It looks like both
COinS[1] and Dublin Core are fairly straightforward.

I'm looking forward to hearing if anybody has done anything with this
yet.

Thanks,

Erik

Footnotes: 
[1]  http://ocoins.info/

-- 
Erik L. Arneson 
  GPG Key ID : 1024D/62DA1D25   BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
  Office : +1.541.291.9776Skype : callto://pymander
   http://www.leisurenouveau.com/ http://www.transformason.org/

Re: [O] beamer email address isn't showed up

[Nick Dokos]

Haluk Dogan  wrote:

> Hi, 
> 
> how can I display my email address in the first page of my presentation?
> 
> Thanks.
> 
> p.s. #+EMAIL property has been already set.
> 

Have you read the manual? Hint: sec. 12.2, "Export Options".

Alternatively, press C-x C-e after the closing paren:

(info "(org) Export Options")

Make sure you read the whole page.

Nick

Re: [O] [org-babel] [PATCH] Improve ditta.jar finding heuristics

[Eric Schulte]

>> Org-mode has *many* customization variables, and for most problems a
>> variable will exist to solve the problem,
>
> I understand where you're coming from. True, it is not possible to
> handle all obscure and arcane cases, that's what all these variables are
> for, but I don't think that a situation where user installs ditaa and
> later emacs, both via the package management system and find themselves
> unable to draw awesome ditaa diagrams without looking a variable up in
> documentation, adding appropriate code to his configuration file and
> hitting C-x C-e is some sort of a fringe use-case. If only
> myself and maybe another person has ever hit that roadblock, than I
> agree, it is not worth adding any additional code, and I rest my case.
>

I would agree the above situation is not desirable.  It is hard to tell
how many people have run into this issue, as it is probably more trouble
to post to this list than it is to find the appropriate variable and set
it to an appropriate value.

I don't know how the Emacs apt-get package is maintained, but it seems
to me that the variable should be set by the apt-get package
maintainers.  I assume the Emacs packages already have to set a number
of customization variables perhaps the best approach would be to find
out how to add org-ditaa-jar-path to their list.

Best -- Eric

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

[O] beamer email address isn't showed up

[Haluk Dogan]

Hi, 

how can I display my email address in the first page of my presentation?

Thanks.

p.s. #+EMAIL property has been already set.

--
HD

Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

"Sebastien Vauban"  writes:

> Hi Torsten,
>
> Torsten Anders wrote:
>> Dear Org-Babel developers,
>>
>> When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the
>> code blocks of at least some languages are executed during the export
>> process. (Has this always been like that, I noticed this for the first
>> time?)
>>
>> I would like to switch that off completely. I prefer evaluating code blocks
>> individually to check their results. Also, many of by code blocks run
>> substantial programs which slow down the export process considerably.
>>
>> I could not find an option to switch this off in the documentation.
>> Apologies if I missed something obvious. I assume it is there somewhere, but
>> I could not find it.
>
> #+PROPERTY:  eval never
>
> does inhibit evaluation of the code blocks.
>

You could also look into using the ":cache" header argument to only
re-run code blocks when their inputs have changed, or sometimes I find
it easy to simply disassociate the results of a code block from the code
block itself (e.g., through a rename), and then change the export
property of the code block to either "code" or "none".

Best -- Eric

>
> Best regards,
>   Seb

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

Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export

[Sebastien Vauban]

Hi Torsten,

Torsten Anders wrote:
> Dear Org-Babel developers,
>
> When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the
> code blocks of at least some languages are executed during the export
> process. (Has this always been like that, I noticed this for the first
> time?)
>
> I would like to switch that off completely. I prefer evaluating code blocks
> individually to check their results. Also, many of by code blocks run
> substantial programs which slow down the export process considerably.
>
> I could not find an option to switch this off in the documentation.
> Apologies if I missed something obvious. I assume it is there somewhere, but
> I could not find it.

#+PROPERTY:  eval never

does inhibit evaluation of the code blocks.

Best regards,
  Seb

-- 
Sebastien Vauban

[O] [org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

Dear  Org-Babel developers, 

When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the code 
blocks of at least some languages are executed during the export process. (Has 
this always been like that, I noticed this for the first time?)

I would like to switch that off completely. I prefer evaluating code blocks 
individually to check their results. Also, many of by code blocks run 
substantial programs which slow down the export process considerably. 

I could not find an option to switch this off in the documentation. Apologies 
if I missed something obvious. I assume it is there somewhere, but I could not 
find it. 

Thank you! 

Best wishes,
Torsten

--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
torsten.and...@beds.ac.uk
http://strasheela.sourceforge.net
http://www.torsten-anders.de

Re: [O] beamer right aligned table

[suvayu ali]

On Mon, Nov 21, 2011 at 17:24, Haluk Dogan  wrote:
> Even though table column are right aligned, in my pdf result they are still 
> left aligned. What am I supposed to do?
>

#+ATTR_LATEX: align=lr

to left align the first column and right align the second column.

HTH

-- 
Suvayu

Open source is the future. It sets us free.

[O] beamer right aligned table

[Haluk Dogan]

Hi,

I have the following table.

| | |
|  1. | gaaccgacct |
|  2. |  aaccgacct |
|  3. |   accgacct |
|  4. |ccgacct |
|  5. | cgacct |
|  6. |  gacct |
|  7. |   acct |
|  8. |cct |
|  9. | ct |
| 10. |  t |

Even though table column are right aligned, in my pdf result they are still 
left aligned. What am I supposed to do?

Thanks.

--
HD

Re: [O] [beamer] Can I just export one frame?

[Herbert Sitz]

zwz  gmail.com> writes:

> It takes long to export the whole file when it contains many babel
> stuff. And in many cases, I just want to check if the current frame is
> arranged as expected. SO I just want to know if there is some convenient
> way to export just one frame without tagging all the other frames as 
> :noexport.
> 

Have you tried just tagging the tree you want with :export:?  Once that select
tag is present in the buffer Org will automatically exclude any trees that don't
have it.  From the docs:

"Org first checks if any of the select tags is present in the buffer. If yes,
all trees that do not carry one of these tags will be excluded. If a selected
tree is a subtree, the heading hierarchy above it will also be selected for
export, but not the text below those headings. "
http://orgmode.org/manual/Selective-export.html#index-export_002c-selective-by-tags-or-TODO-keyword-1424

Re: [O] TABLES: split cells on columns

[Michael Brand]

Hi Daniel

Yes, there is:
1) M- to add the new line
2) mark the region from "t" down to any char from the field below
3) M-Ret

The opposite direction is:
- C-u M-Ret to join the content of a field to the one above

See also C-h f org-table-wrap-region for more tricks.

Michael

On Mon, Nov 21, 2011 at 14:31, Daniel Martins  wrote:
> The feature of remove/add cell is quite important. Should be a feature
> request.
> Another important feature request is to split cells.
> Example (copying and paste the example above)
>
> Example:
> I have the following table:
> |        1 |        1 |
> |        2 | two words|
> |        3 |        4 |
> |        4 |          |
> Now I want to split cell  @2$2 and thus move the second part to the
> following cell below  in column 2 down one step.
> After:
> |        1 |        1 |
> |        2 |       two|
> |          |     words|
> |        3 |        4 |
> |        4 |          |
>
>
> I do it several times when I put much comments on an entry and the column
> becomes much wider.
> It is several commands (sometimes with rectangles, sometimes not depending
> on the remaining of the table) .
> Is there an easy way to do this?

Re: [O] [PATCH] Implement priority inheritance for agenda views.

[Martin Pohlack]

Hi All,

On 26.05.2011 14:21, Michael Hohmuth wrote:
> * lisp/org.el (org-use-prio-inheritance): New customizable for using
> priority inheritance in agenda views.  Defaults to off
> (org-get-priority-char): Factored out from org-get-priority.  Return
> priority token from headline, defaulting to an optional fallback or
> org-default-priority.
> (org-get-priority): Use org-get-priority-char. Default to an optional
> fallback or org-default-priority.
> (org-scan-tags): Assign and display priority according to
> org-use-prio-inheritance.
> ---
> This patch can be pulled from branch prio-inherit at
> git://github.com/altruizine/org-mode.git .
> 
> I am aware that priority inheritance for to-do items has been
> requested and rejected in the past, on the grounds of inherited
> priorities allegedly inflating the number of assigned priorities,
> thereby defeating the purpose of priorities.  Well, I disagree, as I
> have found inherited priorities useful in practice.

I would be interested in this functionality.  What is needed to merge this?

Thanks,
Martin

[O] TABLES: split cells on columns

[Daniel Martins]

The feature of remove/add cell is quite important. Should be a feature
request.

Another important feature request is to split cells.

Example (copying and paste the example above)


Example:
I have the following table:
|1 |1 |
|2 | two words|
|3 |4 |
|4 |  |

Now I want to split cell  @2$2 and thus move the second part to the
following cell below  in column 2 down one step.

After:
|1 |1 |
|2 |   two|
|  | words|
|3 |4 |
|4 |  |



I do it several times when I put much comments on an entry and the column
becomes much wider.

It is several commands (sometimes with rectangles, sometimes not depending
on the remaining of the table) .

Is there an easy way to do this?

Daniel


Is there a s

2011/10/1 suvayu ali 

> 2011/9/30 Michael Brand :
> > Ehm - it is doable, but not by editing commands from Org table. Only
> > with several rectangular edits or an Org table formula with a few
> > tricks and a temporary column to be removed afterward.
>
> There are some org-table specific rectangle edit commands that should
> make it easier. Cut the cells with org-table-cut-region, and paste by
> org-table-paste-rectangle.
>
> Hope this helps.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
>

[O] odt export to google-docs problem continues

[Rustom Mody]

On Fri, Nov 18, 2011 at 11:21 AM, Jambunathan K wrote:

> Suvayu/Rustom
>
> suvayu ali  writes:
>
> > Hi Jambunathan,
> >
> > On Thu, Nov 17, 2011 at 11:06, Jambunathan K 
> wrote:
> >> Can anyone else reproduce this?
> >
> > I can replicate this. The odt file exported by org-odt is not accepted
> > by google docs even though libreoffice opens it without problems.
> > However it I open it with libreoffice and say edit and save, google
> > docs then accepts the new file.
>
> With my some experimentation, I am able to reproduce it now. I have this
> in my .emacs.
>
> ,
> | (setq org-export-odt-prettify-xml t)
>

Well now google docs accepts but libreoffice itself says "file is corrupt
shall I repair?"
If I take the odt file directly made by exporter direcly in googledocs
there are lots of spurious spaces eg between bullets and the first word.

If I push it through libreoffice and resave then googledocs does a better
job of displaying

Re: [O] [babel] :var assignment no longer tolerant of whitespace

[Martyn Jago]

Eric Schulte  writes:
Hi Eric

> Hi Martyn,
>
> Tom mentioned this regression earlier and I treated it as a new
> restriction on variable specifications, but if multiple people are
> running into this issue I suppose spaces around equals should be
> supported.
>
> I have just pushed up a change and a test case ensuring that examples
> like yours below will work.
>

Many thanks

Best, Martyn


> Cheers -- Eric
>

Re: [O] [beamer] Can I just export one frame?

[suvayu ali]

On Mon, Nov 21, 2011 at 06:40, zwz  wrote:
> SO I just want to know if there is some convenient
> way to export just one frame without tagging all the other frames as 
> :noexport.

Subtree export?

-- 
Suvayu

Open source is the future. It sets us free.