Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Bastien
Hi Suvayu,

Suvayu Ali  writes:

> Rest of the documentation is worked on at the moment.  Worg is a
> community resource, so you can contribute too!  There was a recent (~1
> month) post by Bastien outlining a procedure to mark deprecated
> documentation on Worg.

Yes.  The idea is simply to use 

#+OrgVersion: 8.0 

in the head of the document if the document describes things that are
for Org >=8.0, and a :OrgVersion: 8.0 (multi-valued) property for the
subtrees that require a specific version.

It's not widely used and difficult to use retroactively, but might be
a good habit to have from now on.

-- 
 Bastien



Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Suvayu Ali
On Mon, Apr 22, 2013 at 01:03:28AM +0200, Alexander Baier wrote:
> Nicolas Goaziou  writes:
> 
> > Hello,
> >
> > Suvayu Ali  writes:
> >
> >> Not sure why, but your -shell-escape option is being ignored.  Untill
> >> you can solve this properly, maybe you can put the LaTeX calls in a
> >> shell script and set that as your org-latex-pdf-process.
> >
> > I think the problem is that the OP uses `org-latex-to-pdf-process'
> > instead of `org-latex-pdf-process'.
> >
> >
> > Regards,
> 
> Hello Nicolas,
> 
> You are right, using org-latex-pdf-process solves the -shell-escape
> issue and C-c C-e l P produces the PDF without compaints.  Maybe the
> documentation [1] i got the code from should be updated?

Presently the manual is the most reliable source of information.
Followed by the Worg articles listed here:

  
  

Rest of the documentation is worked on at the moment.  Worg is a
community resource, so you can contribute too!  There was a recent (~1
month) post by Bastien outlining a procedure to mark deprecated
documentation on Worg.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] [PATCH 03/10] Clean up various org-babel-*-maybe commands

2013-04-21 Thread Aaron Ecay
Hi Eric,

2013ko apirilak 20an, Eric Schulte-ek idatzi zuen:
> Could re-calculating the info cause referenced blocks to be executed
> more than once?
> 
> If so then we should continue passing the info and *not* simply
> re-calculate it later on.

This is a very good question.  I will look into it and send an update
when I have found out the answer.

Thanks,

-- 
Aaron Ecay



Re: [O] [PATCH 04/10] Add 'light argument to some uses of org-babel-get-src-block-info

2013-04-21 Thread Aaron Ecay
Hi Eric,

2013ko apirilak 20an, Eric Schulte-ek idatzi zuen:
> 
> Then please go ahead and apply this patch (or re-send it to me and I can
> apply it).

Done.  :)

-- 
Aaron Ecay



[O] [BUG] Hotkeys defined in org-tag-alist repeated in agenda filter dispatcher

2013-04-21 Thread Viktor Rosenfeld
Hi,

I have the following tags defined in my initialization code:

#+BEGIN_SRC emacs-lisp
(setq org-tag-alist '((:startgroup . nil)
  ("@home" . ?h)
  ("@comp" . ?c)
  ("@otg" . ?o)
  ("@fon" . ?f)
  ("@agenda" . ?a) 
  ("@read" . ?r)
  ("@write" . ?w)
  (:endgroup . nil)
  (:startgroup . nil)
  ("IMPORTANT" . ?*)
  ("SOMEDAY" . ??)
  (:endgroup . nil)))
#+END_SRC

If I hit the =/= key in the agenda to filter the agenda by tag, the
hotkeys defined in the list above are repeated multiple times. That
is, the string in the Emacs minibuffer reads:

#+BEGIN_EXAMPLE
Narrow by tag 
[hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?
 ], [TAB], ...
#+END_EXAMPLE

This only happens if =org-agenda-files= is set to a directory (or list
of directories), e.g.:

#+BEGIN_SRC emacs-lisp
(setq org-agenda-files '( "~/org" ))
#+END_SRC

If =org-agenda-files= is set to a list of files the hotkeys are not
repeated. E.g.:

#+BEGIN_SRC emacs-lisp
(setq org-agenda-files '( "~/org/openloops.org" 
  "~/org/dokumente.org"))
#+END_SRC

With the setting above the string in the Emacs minibuffer reads, as
expected:

#+BEGIN_EXAMPLE
Narrow by tag [hcofarw*? ], [TAB], ...
#+END_EXAMPLE

git bisect reveals the following commit as the culprit:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=575c9f16c3a1dc6660dd1aebdd560ec7caa1365e

However, before this commit, none of the hotkeys appear in the
minibuffer, which is another bug. Apparently, the last commit where
everything works as expected is:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=a9880a7710415218d3940e380968a9ed56367880
 

I am on Ubuntu 12.04.2 with a backported Emacs 24.3.1.

Cheers,
Viktor



[O] [babel] Purpose of :results raw

2013-04-21 Thread Samuel Wales
[headers were somehow set to other than the mailing list itself.
maybe a gmane bug?]

On 4/20/13, Nicolas Goaziou  wrote:
> I will slowly integrate org-element-at-point in core interactive
> functions, like visibility cycling. Though, fontification will have to
> wait, because the parser isn't ready for that yet.

In the grand scheme, this might be a minor point, but:

While consistency is a good thing, I am nevertheless glad for that
last point.  I am concerned that incorporating the parser into
fontification will break inline footnotes that have more than one
paragraph (unless it is designed to be flexible enough to allow that).

To me, paragraphs naturally fit in inline footnotes, just as they do
in non-inline ones, but that is incompatible with the current parser,
which treats paragraphs as semantically larger units than inline
footnotes.

I appreciate your workaround for making them work again in export,
which works.  Fontification currently works perfectly also as it
always has; I just don't want that to stop working for those who, like
me, use inline footnotes similarly to non-inline ones, occasionally
with more than one paragraph.

This of course leaves us open to the accusation that nobody should be
so long-winded in a footnote as to have more than one paragraph (and
quotes and more, which currently work perfectly, ), but the same
would apply to non-inline footnotes also, and Org is in any case by
tradition highly flexible.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is NO hope without action.  This means YOU.



Re: [O] merging per-file (or heading) TODO sequences

2013-04-21 Thread Eric Abrahamsen
Carsten Dominik  writes:

> On 21.4.2013, at 11:08, Eric Abrahamsen  wrote:
>
>> I could have sworn I've done this successfully before, but...
>> 
>> I need a special sequence of TODO keywords for one file -- actually just
>> one headline in particular. I thought I remembered this used to be
>> possible, but it doesn't seem to be anymore.
>> 
>> Setting #+SEQ_TODO: FOO | BAR at the top of the file actually
>> overwrites the existing value of `org-todo-keywords' for that file. In
>> this case I'd like to either:
>> 
>> 1. Create this sequence for a single subtree (it's okay if it clobbers
>> the global value of `org-todo-keywords', so long as it's *only* for this
>> subtree), or
>
> This is currently not possible.
>
>> 
>> 2. Set the new sequence at the top of the file, but merge this sequence
>> with the global value of `org-todo-keywords'.
>
> And neither is this.
>
> But you do have the options Richard mentions in his post.

Thanks to you both -- I guess I wasn't mis-remembering. I'd rather not
replicate my other TODO sequences at the top of the file; I might
experiment with a separate file altogether.

Thanks again,
Eric




Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Alexander Baier
Suvayu Ali  writes:

> Hi Alexander,
>
> On Sun, Apr 21, 2013 at 09:25:55PM +0200, Alexander Baier wrote:
>> 
>> I am trying to syntax-color the code in my source blocks that is
>> exported to LaTeX. As proposed in this thread [1] over a year ago I
>> followed this guide [2], but could not get the generated .tex file to
>> compile.
>
> [...chomp...chomp...chomp...]
>
>> Package ifplatform Warning: 
>> shell escape is disabled, so I can only detect \ifwindows.
>> 
>> )
>> \minted@bgbox=\box61
>> \minted@code=\write6
>> \@float@every@listing=\toks51
>> \c@listing=\count166
>> )
>> 
>> ! Package minted Error: You must invoke LaTeX with the -shell-escape flag.
>> 
>> See the minted package documentation for explanation.
>> Type  H   for immediate help.
>>  ...  
>>   
>> l.20 \usetheme
>>   {default}
>> Pass the -shell-escape flag to LaTeX. Refer to the minted.sty documentation 
>> for
>>  more information.
>> 
>> runsystem(which pygmentize && touch output.aex)...disabled (restricted).
>> 
>> 
>> ! Package minted Error: You must have `pygmentize' installed to use this 
>> packag
>> e.
>> 
>> See the minted package documentation for explanation.
>> Type  H   for immediate help.
>>  ...  
>>   
>> l.20 \usetheme
>>   {default}
>> Refer to the installation instructions in the minted documentation for more 
>> inf
>> ormation.
>
> [...chomp...chomp...chomp...]
>
>> runsystem(pygmentize -S default -f latex > output.pyg)...disabled 
>> (restricted).
>> 
>> 
>> 
>> ! LaTeX Error: File `output.pyg' not found.
>> 
>> Type X to quit or  to proceed,
>> or enter new name. (Default extension: pyg)
>
> Not sure why, but your -shell-escape option is being ignored.  Untill
> you can solve this properly, maybe you can put the LaTeX calls in a
> shell script and set that as your org-latex-pdf-process.
>
> Hope this helps,

Hello Suvayu,

Thank you for your answer.

Following your proposal:
---
(setq org-latex-to-pdf-process
  '("/home/delexi/orgtest/pdflatex-escaped.sh %o %f"
"/home/delexi/orgtest/pdflatex-escaped.sh %o %f"
"/home/delexi/orgtest/pdflatex-escaped.sh %o %f"))
---
Btw: Why is this a list of 3 identical tools/calls?

And pdflatex-escaped.sh:
---
#! /bin/bash
#
pdflatex -shell-escape -interaction nonstopmode -output-directory "$1" "$2"
---

Sadly, this leads to the same problem, complaining about -shell-escape.

When I only produce the .tex file (C-c C-e l b) and then manually
execute the before mentioned bash script on it, the PDF is generated without
any complaints.

Albeit there are not errors when creating the PDF file, the desired
syntax coloring does not take place and the source code simply appears
in black verbatim(?).

Do you have any more ideas?

Regards,

Alex




Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Alexander Baier
Nicolas Goaziou  writes:

> Hello,
>
> Suvayu Ali  writes:
>
>> Not sure why, but your -shell-escape option is being ignored.  Untill
>> you can solve this properly, maybe you can put the LaTeX calls in a
>> shell script and set that as your org-latex-pdf-process.
>
> I think the problem is that the OP uses `org-latex-to-pdf-process'
> instead of `org-latex-pdf-process'.
>
>
> Regards,

Hello Nicolas,

You are right, using org-latex-pdf-process solves the -shell-escape
issue and C-c C-e l P produces the PDF without compaints.  Maybe the
documentation [1] i got the code from should be updated?


[1] http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-3




Re: [O] New maintainer

2013-04-21 Thread Bastien
Hi Andreas,

thanks for the kind words.

The decision to step down after 8.0 was taken a long time ago,
before the recent problems on the list.  I had to find someone
willing to step in before I could announce this.

I agree "maintainer" is not necessary a single person: my main
purpose was to build a team, so that future maintainer(s) would
feel okay to act as you suggest, for strategic decisions rather
than everyday ground-level stuff.

This position is easy to describe but difficult to hold, because
it depends so much on the community.

This *is* the real challenge I see now: that each of us endorses
some kind of responsability, some co-maintainership feeling, and
act as constructively as possible---be it for org-mode, worg, the
website or whatever.

I already can feel some go in this direction and that's great :)

-- 
 Bastien



Re: [O] [bug] list sorting wrong-type-argument error

2013-04-21 Thread Bastien
Samuel Wales  writes:

> I am getting a hang while sorting this:
>
> ===
> :LOGBOOK:
> - State "DONE"   from "NEXTREPEAT" [2013-04-15 Mon 21:03]
> - State "DONE"   from "NEXTREPEAT" [2013-03-24 Sun 16:27]
> :END:
> ===

This is now fixed, thanks.

-- 
 Bastien



Re: [O] New maintainer

2013-04-21 Thread AG
Bastien  gnu.org> writes:

> 
> Dear all,
> 
> I'm stepping down as the Org maintainer.
> 
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
> 
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
> 
> :)
> 


Dear Bastien,
 I too would like to express my thanks for all your hard work in keeping
org running smoothly over the last couple of years, and unfailing
(preternatural) graciousness even in the face of personal and unprofessional
attacks. I hope you are leaving of your own volition. Illegitimi non
carborundum.


I am also grateful to Carsten for his great contributions of Org, reftex and
cdlatex, and happy to hear he will be taking over.

AG




Re: [O] ox-taskjuggler : Correct a small typo and deal with Scheduled and deadline in task

2013-04-21 Thread Bastien
Hi Baptiste and Christian,

Christian Egli  writes:

> This looks a bit fishy. Shouldn't this be 
>
> ((start) (format "  start %s\n" start))

I guess this should be

 (start (format "  start %s\n" start))

Otherwise (start) will bite as not being a function.

>> +   ((and end) (format "  start %s\n" end
> Ditto

-- 
 Bastien



Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Nicolas Goaziou
Hello,

Suvayu Ali  writes:

> Not sure why, but your -shell-escape option is being ignored.  Untill
> you can solve this properly, maybe you can put the LaTeX calls in a
> shell script and set that as your org-latex-pdf-process.

I think the problem is that the OP uses `org-latex-to-pdf-process'
instead of `org-latex-pdf-process'.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]

2013-04-21 Thread Bastien
Nicolas Goaziou  writes:

> I went a bit further. Footnotes will always be ignored in ics
> export.

Great, thanks!

-- 
 Bastien



Re: [O] New Exporter: plain list depth

2013-04-21 Thread Nicolas Goaziou
Hello,

Yasushi SHOJI  writes:

> What is the best way to know the depth of list entries when I writing
> an exporter back-end?
>
> let's say I have:
>
> #+BEGIN_SRC org
>   * headline 1
> - list 1
> - list 2
>   - list 2.1
> #+END_SRC
>
> I'd like to convert it to:
>
> #+BEGIN_EXAMPLE
>   * headline 1
>   - list 1
>   - list 2
>   -- list 2.1
> #+END_EXAMPLE
>
>
> To generate "--" at the list 2.1, I'd like to find out the list 2.1 is
> at depth 2, so that I can use (make-string 2 ?-) for my bullet.

Something like the following should work, assuming ITEM is the item
element you have to transcode:

#+begin_src emacs-lisp
(let ((parent item) (depth 0))
  (while (and (setq parent (org-export-get-parent parent))
  (case (org-element-type parent)
(item t)
(plain-list (incf depth)
  depth)
#+end_src

> Does org-list-to-generic work in this situation?

As a good rule of thumb, it's best to rely on tools provided in ox.el.


Regards,

-- 
Nicolas Goaziou



Re: [O] Greater Elements

2013-04-21 Thread Nicolas Goaziou
Hello,

Thorsten Jolitz  writes:

> citing from 'org-element.el':
>
> ,--
> | Element containing other elements (and only elements) are called
> | greater elements.  Concerned types are: `center-block', `drawer',
> | `dynamic-block', `footnote-definition', `headline', `inlinetask',
> | `item', `plain-list', `property-drawer', `quote-block', `section'
> | and `special-block'.
> `--
>
> I find the 'containing other elements (and only elements)' confusing.
> Don't some of these greater elements contain plain text as well as Org
> objects?

None of them contains _directly_ plain text or an object.

But they can contain an element that will, in turn, contain plain text
or an object. Note that there are only three such elements: paragraphs,
verse-blocks and table-rows (the latter being a special case as it can
only contain one object type: table-cells).


Regards,

-- 
Nicolas Goaziou



Re: [O] [bug] list sorting wrong-type-argument error

2013-04-21 Thread Samuel Wales
On 4/15/13, Bastien  wrote:
> bad bug indeed, fixed now.  Thanks for reporting this.

It works, thank you.

I am getting a hang while sorting this:

===
:LOGBOOK:
- State "DONE"   from "NEXTREPEAT" [2013-04-15 Mon 21:03]
- State "DONE"   from "NEXTREPEAT" [2013-03-24 Sun 16:27]
:END:
===

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is NO hope without action.  This means YOU.



Re: [O] [PATCH] tiny fixes in ox-ascii.el [was: Re: Bug: Footnotes break iCalendar export]

2013-04-21 Thread Nicolas Goaziou
Richard Lawrence  writes:

> Here is a patch for a couple of tiny issues I encountered in ox-ascii.el
> while debugging ox-icalendar.el.  Explanation:

I applied the changes. Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]

2013-04-21 Thread Nicolas Goaziou
Hello,

Bastien  writes:

>
>> I've been trying to get iCalendar export working with my agenda files
>> again since upgrading to 8.0, and I've found that footnotes break the
>> agenda export to .ics.  The problem is that a plain text version of the
>> footnotes in the file ends up in the output "floating loose"---not
>> wrapped by VEVENT tags or any other tags---resulting in an unparseable
>> .ics file (at least according to Google Calendar).
>
> I tried this patch but for some reason it does not work.
>
> I did not look further, surely Nicolas has something that
> works.  I agree footnotes should be turned off by default
> for the .ics export.

I went a bit further. Footnotes will always be ignored in ics export.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]

2013-04-21 Thread Nicolas Goaziou
Hello,

Richard Lawrence  writes:

> I've been trying to get iCalendar export working with my agenda files
> again since upgrading to 8.0, and I've found that footnotes break the
> agenda export to .ics.  The problem is that a plain text version of the
> footnotes in the file ends up in the output "floating loose"---not
> wrapped by VEVENT tags or any other tags---resulting in an unparseable
> .ics file (at least according to Google Calendar).
>
> Here's a sample Org file to illustrate:
>
> * Entry 1
>   This entry has some text with an inline footnote[fn:: which isn't
>   very interesting]
> * Entry 2
>   This entry has some text with an external footnote[fn:1]
> * Appointment with Someone
>   <2013-04-20 Sat 15:00>
> * Footnotes
> [fn:1] which still isn't very interesting

This should be fixed. Thank you for the report.


Regards,

-- 
Nicolas Goaziou



[O] New Exporter: plain list depth

2013-04-21 Thread Yasushi SHOJI
Hi,

What is the best way to know the depth of list entries when I writing
an exporter back-end?

let's say I have:

#+BEGIN_SRC org
  * headline 1
- list 1
- list 2
  - list 2.1
#+END_SRC

I'd like to convert it to:

#+BEGIN_EXAMPLE
  * headline 1
  - list 1
  - list 2
  -- list 2.1
#+END_EXAMPLE


To generate "--" at the list 2.1, I'd like to find out the list 2.1 is
at depth 2, so that I can use (make-string 2 ?-) for my bullet.

What I came up with instead was to

 1) mark each item in item handler with "-"
 2) add a "-" in each plain-list handler
 3) remove one "-" from all list entries at final-function

it works, but it doesn't look good to me (tm).

I've checked a few exporters, including ox-html and ox-md but couldn't
find a function like org-export-get-relative-level for headline. Does
org-list-to-generic work in this situation?

Thanks,
-- 
yashi





Re: [O] Source Code Syntax Highlighting in Beamer slides

2013-04-21 Thread Suvayu Ali
Hi Alexander,

On Sun, Apr 21, 2013 at 09:25:55PM +0200, Alexander Baier wrote:
> 
> I am trying to syntax-color the code in my source blocks that is
> exported to LaTeX. As proposed in this thread [1] over a year ago I
> followed this guide [2], but could not get the generated .tex file to
> compile.

[...chomp...chomp...chomp...]

> Package ifplatform Warning: 
> shell escape is disabled, so I can only detect \ifwindows.
> 
> )
> \minted@bgbox=\box61
> \minted@code=\write6
> \@float@every@listing=\toks51
> \c@listing=\count166
> )
> 
> ! Package minted Error: You must invoke LaTeX with the -shell-escape flag.
> 
> See the minted package documentation for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.20 \usetheme
>   {default}
> Pass the -shell-escape flag to LaTeX. Refer to the minted.sty documentation 
> for
>  more information.
> 
> runsystem(which pygmentize && touch output.aex)...disabled (restricted).
> 
> 
> ! Package minted Error: You must have `pygmentize' installed to use this 
> packag
> e.
> 
> See the minted package documentation for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.20 \usetheme
>   {default}
> Refer to the installation instructions in the minted documentation for more 
> inf
> ormation.

[...chomp...chomp...chomp...]

> runsystem(pygmentize -S default -f latex > output.pyg)...disabled 
> (restricted).
> 
> 
> 
> ! LaTeX Error: File `output.pyg' not found.
> 
> Type X to quit or  to proceed,
> or enter new name. (Default extension: pyg)

Not sure why, but your -shell-escape option is being ignored.  Untill
you can solve this properly, maybe you can put the LaTeX calls in a
shell script and set that as your org-latex-pdf-process.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.



[O] Greater Elements

2013-04-21 Thread Thorsten Jolitz

Hi Nicolas, Hi List, 

citing from 'org-element.el':

,--
| Element containing other elements (and only elements) are called
| greater elements.  Concerned types are: `center-block', `drawer',
| `dynamic-block', `footnote-definition', `headline', `inlinetask',
| `item', `plain-list', `property-drawer', `quote-block', `section'
| and `special-block'.
`--

I find the 'containing other elements (and only elements)' confusing.
Don't some of these greater elements contain plain text as well as Org
objects?

-- 
cheers,
Thorsten





Re: [O] ox-taskjuggler : Correct a small typo and deal with Scheduled and deadline in task

2013-04-21 Thread Christian Egli
Hi Baptiste

Thanks for the patch. It fixes a pretty bad oversight that you currently
apparently cannot define a start and an end using SCHEDULED and DEADLINE
(I thought this worked in the old exporter and was maybe lost in the
translation). I would like to use the patch but there are a couple of
issues:

Baptiste  writes:

>   (effort (org-element-property :EFFORT task))
> + (start (org-taskjuggler-get-start task))
> + (end (org-taskjuggler-get-end task))

This is obviously OK.

> @@ -775,6 +777,14 @@ a unique id will be associated to it."
>   (org-taskjuggler-get-id task info)
>   (org-taskjuggler-get-name task))
>   ;; Add default attributes.
> + (and milestone
> +  (cond
> +   ((and start end) (format "  start %s\n  maxend %s\n" start end))

Are you saying that if we have a milestone, a start and an end date we
should define the start and use the end date as a maxend? This seems
like an interesting approach. Unfortunately currently `milestone' is
true only if there is not both and start and an end date. We should
probably also change the definition of milestone (see
http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/ox-taskjuggler.el#n757).

> +   ((and start) (format "  start %s\n" start))

This looks a bit fishy. Shouldn't this be 

((start) (format "  start %s\n" start))

> +   ((and end) (format "  start %s\n" end
Ditto

Also we should probably change the definition of
`org-taskjuggler-get-start' to also look for a "start" attribute but
that's another story.

Can you fix these issues and resend?

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland




[O] Gentoo ebuild for app-emacs/org-mode-8.0.1

2013-04-21 Thread Christoph LANGE
Hi all,

Gentoo users may find my ebuild for app-emacs/org-mode-8.0.1 useful.
Please download it from
https://466720.bugs.gentoo.org/attachment.cgi?id=346230 and let's hope
this ebuild (or alternatively Emacs 24.4) will be included with Portage
soon (subscribe to https://bugs.gentoo.org/show_bug.cgi?id=466720 to
track the progress).

Thanks to Bastien et al. for version 8!

Cheers,

Christoph

-- 
Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701



[O] [PATCH] tiny fixes in ox-ascii.el [was: Re: Bug: Footnotes break iCalendar export]

2013-04-21 Thread Richard Lawrence

Here is a patch for a couple of tiny issues I encountered in ox-ascii.el
while debugging ox-icalendar.el.  Explanation:

1) There is no function called `org-ascii-footnote-definition' (though
it looks like maybe there once was?), so I changed a reference to it to
`ignore' to be more explicit.

I'm not sure if this is the right thing to do -- maybe the point was to
let the user define such a function if she wishes?  That however would
be inconsistent with the comment that such definitions are ignored (see
below).

2) A tiny change to the comment explaining why there is no such
function: footnote definitions are ignored because they are compiled by
`org-ascii-inner-template', not `org-ascii-template'.

Best,
Richard

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 2191539..4543c34 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -68,7 +68,7 @@
 (export-block . org-ascii-export-block)
 (export-snippet . org-ascii-export-snippet)
 (fixed-width . org-ascii-fixed-width)
-(footnote-definition . org-ascii-footnote-definition)
+(footnote-definition . ignore)
 (footnote-reference . org-ascii-footnote-reference)
 (headline . org-ascii-headline)
 (horizontal-rule . org-ascii-horizontal-rule)
@@ -1147,7 +1147,7 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
  Footnote Definition
 
 ;; Footnote Definitions are ignored.  They are compiled at the end of
-;; the document, by `org-ascii-template'.
+;; the document, by `org-ascii-inner-template'.
 
 
  Footnote Reference


Re: [O] [Bug] HTML Exporter Does Not Convert \\ To

2013-04-21 Thread T.F. Torrey
On Sun, Apr 21, 2013 at 4:02 AM, Eric Abrahamsen
 wrote:
> Hi Terry,
>
> I just tried with emacs -Q (I'm on 24.3.1) and git Org mode, and the \\
> is exported as "". Can you check with emacs -Q? If you look in
> ox-html.el, you'll see that the function `org-html-line-break' should
> produce a "\n".
>
> Could something else be going wrong?

Thanks for the verification. Indeed, it does work with emacs -Q, and
even with a simple restart of Emacs. Sorry for the noise. -- T.




Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]

2013-04-21 Thread Richard Lawrence
Hi Bastien,

Bastien  writes:

> Richard Lawrence  writes:
>
>> I've been trying to get iCalendar export working with my agenda files
>> again since upgrading to 8.0, and I've found that footnotes break the
>> agenda export to .ics.  The problem is that a plain text version of the
>> footnotes in the file ends up in the output "floating loose"---not
>> wrapped by VEVENT tags or any other tags---resulting in an unparseable
>> .ics file (at least according to Google Calendar).
>
> I tried this patch but for some reason it does not work.

This patch does not work for me, either, but thanks for trying!

> I did not look further, surely Nicolas has something that
> works.  I agree footnotes should be turned off by default
> for the .ics export.

I also tried the following modifications in the definition of the
icalendar backend, without much effect:

1) Adding (footnote-definition . ignore) and
(footnote-reference . ignore) to the :translate-alist

2) Adding (:filter-footnote-definition . ignore) and
(:filter-footnote-reference . ignore) to the :filters-alist

Both of these looked like they might work based on the
org-export-define-backend documentation, but the footnotes still show up
in the output.

[...further tinkering...]

It looks like the problem is this: the icalendar backend does not
specify a transcoder for the "inner-template" element.  Thus it falls
back to the org-ascii-inner-template transcoder, which appends footnotes
to the end of the exported content.

Thus, one solution is to define an org-icalendar-inner-template
transcoder which does nothing to modify the content (but overrides the
fallback); that is the solution I've used in the attached patch.

Best,
Richard

diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 49299b0..39ba383 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -261,6 +261,7 @@ re-read the iCalendar file.")
 		 (inlinetask . ignore)
 		 (planning . ignore)
 		 (section . ignore)
+		 (inner-template . org-icalendar-inner-template)
 		 (template . org-icalendar-template))
   :options-alist
   '((:exclude-tags
@@ -747,7 +748,18 @@ END:VALARM\n"
 		 (if (zerop alarm-time) org-icalendar-alarm-time alarm-time)
 
 
- Template
+ Templates
+
+(defun org-icalendar-inner-template (contents info)
+  "Return inner contents string after iCalendar conversion.
+CONTENTS is the transcoded contents string. INFO is a plist used
+as a communication channel.
+
+This function just returns CONTENTS unchanged.  Its purpose is to
+override the inner-template transcoder of the ascii
+backend (`org-ascii-inner-template'), which appends footnotes
+that break the iCalendar format."
+  contents)
 
 (defun org-icalendar-template (contents info)
   "Return complete document string after iCalendar conversion.


[O] org-blog 0.9 release

2013-04-21 Thread Michael Alan Dorman
Dear org-mode users,

I've just tagged version 0.90 of my org-blog minor mode on github[1].

This is intended to be a simple but powerful assistant to using Org for
writing blog posts---there's only two commands at this point, and I
don't anticipate that number going beyond three anytime soon (though I
do have that third one planned! ;)

At the moment it only supports WordPress blogs, but the design is very
modular, and adding support for other back-ends (including, I hope,
static publishing back-ends) should be relatively painless.  If it's
not, I would be happy to change things to make it so, once I understand
the issues.

I have one outstanding bug[2], that timestamps get mangled.  I thought
I'd squashed it, but apparently not.  I need to create a test and track
that down.

The only other immediate issue I see is that it is still using the 7.8.x
exporter---converting to (or supporting in parallel if possible) the 8.0
exporter is next on my list of things to do.

I wrote a series of posts going through the implementation on my
blog[3]---all authored with org-blog itself.

Although this is the first thing I've written for Emacs outside of
hacking on my .emacs.d, I think the code is fairly clear.  I would
appreciate feedback, and would enjoy and even solicit assitance with
some things: for instance, as a Debian user, I turn out to not know
MELPA/Marmalade from a hole in the ground---so if someone was motivated
to create the changes to support package installation though emacs, I
would be quite happy to merge it. ;)

There's a TODO list of things I hope to work on, and I would be happy to
add to that as well; knowing that people are using it is going to be the
greatest motivation for things to happen---otherwise I will probably
plod along doing things in my own sweet time, since it's working pretty
well for me so far.

Cheers,

Mike.

[1] https://github.com/mdorman/org-blog
[2] https://github.com/mdorman/org-blog/issues/16
[2] http://doyouevenlisp.com/tag/org-blog/



Re: [O] New maintainer

2013-04-21 Thread Andreas Röhler

Am 18.04.2013 18:53, schrieb Bastien:

Dear all,

I'm stepping down as the Org maintainer.

Carsten accepted to step up, if the community agrees.
Please raise your thumbs up or your concerns, if any.

I'm glad I had this opportunity to work as "Robin" and
I'm even more glad "Batman" may strike back!

:)



Hi Bastien,

have been afk for some days, please let me close up to all thanks seen here.
What's have been quite impressive already was the pure amount of mailings, you 
delt with day by day.

Having seen you working that hard also raises some concern for now: that daily galeere must be costly: whoever undertakes it, will pay a price. It's your honor having payed 
it for all of us. So far can't consider this stepping down anything else as a loss for org-mode.


While ignoring circumstances of your resign, it's no secret, some unpleasant 
events happended last weeks, made your task more burdensome as necessary.
I'm not speaking of possible errors - everyone who works will make errors. Who 
works outstanding might make outstanding errors.
Purely abstractly spoken(!)

OTHO the very best mind a team has --i.e. Carsten--, should not take the most burdensome tasks. IMHO Carsten should be spared for strategic decisions, define and decide the 
path of further development.


In case you didn't lose your interest and just that recent unpleasant experiences caused your resign, what about staying maintainer backed by all this confidence revealed 
beside of some new experience?


Also maintainer must not mean being strictly a single person, even if languages 
grammar doesn't foresee otherwise.
Regarding recent difficulties, probably it's wise, if Carsten has a closer 
look, decides in cases from time to time.
IIUC Emacs itself was driven in a similar way last years more or less outspoken 
- consider this part of it's success story.

Best regards,

Andreas





[O] [PATCH] Improve configurability of ox-koma-letter

2013-04-21 Thread Viktor Rosenfeld
Hi,

I've hacked the ox-koma-letter exporter to make it more configurable.
See the Changelog of the attached patch, hopefully I've followed the
Changelog guidelines propertly.

Also, I could not find an ox-koma-letter tutorial on Worg. I would be
willing to create such a tutorial, maybe next weekend. Can anybody edit
the contents on Worg or do I need special priviledges?

Cheers, Viktor
KOMA scrlttr2 export: Improve export configuration options.

* ox-koma-letter.el (org-koma-letter-sender): New option for
the letter's author.
(org-koma-letter-from-address): Do not set default personal information.
(org-koma-letter-phone-number): Do not set default personal information.
(org-koma-letter-email): New option for the sender's email.
(org-koma-letter-place): Specify the letter's place.
(org-koma-letter-opening): Gendered opening.
(org-koma-letter-closing): More business-like closing
(org-koma-letter-use-subject): Configure the appearance of the
subject line.
(org-koma-letter-use-backaddress): Configure the presence of
the backaddress.
(org-koma-letter-use-foldmarks): Configure the presence of foldmarks.
(org-koma-letter-use-phone): Configure the presence of the
sender's phone number.
(org-koma-letter-use-email): Configure the presence of the
sender's email address.
(org-koma-letter-use-place): Configure the presence of the
letter's place.
(koma-letter): Add new options to koma-letter export backend
(org-koma-letter-template): Better KOMA configuration; support for 
multiple LCO files.

This patch changes the KOMA-letter exporter in four ways:

* Same hotkeys as the LaTeX exporter

Use =L= (instead of =K=) to export to a buffer, =l= (instead of =k=)
to export to a file, and =O= (instead of =o=) to open the PDF file.

This was already suggested by Rasmus
(http://thread.gmane.org/gmane.emacs.orgmode/67026).

* Setting of KOMA variables

LCO files are loaded first and KOMA variables are only set in the
LaTeX output if their value is not nil. This way most configuration
options can be set once in an LCO file and overwritten if needed.

Consider for example an LCO file =DefaultAddress.lco= in
=~/texmf/tex/latex=.

#+BEGIN_SRC latex
\ProvidesFile{DefaultAddress.lco}
\setkomavar{fromname}{Max Mustermann}
\setkomavar{fromaddress}{Musterstraße 1\\12345 Musterstadt}
#+END_SRC

The default address can then be overwritten in the actual letter. Note
the additional country in the address below.

#+LCO: DefaultAddress
#+FROM_ADDRESS: Musterstraße 1\\12345 Musterstadt\\Germany

* Setting of KOMA options

The presence of the sender's phone and email, the letter's place and
subject, as well as foldmarks and the backaddress are
configurable. Consider:

#+OPTIONS: subject:titled place:nil phone:t email:t foldmarks:nil backaddress:nil

Note, that except for =subject=, all options are boolean, e.g., they
accept the values =t= and =nil=. Subject can also be nil to surpress
printing, or otherwise any possible value for the KOMA option subject,
i.e., afteropening, beforeopening, centered, left, right, titled,
underlined, or untitled.

* Multiple LCO files

Multiple LCO files, separated by spaces, can be specified. This way
one can add optional behavior to the letter export. Consider, e.g., an
LCO file with a default address and a simple textual signature:

#+BEGIN_SRC latex
\ProvidesFile{Default.lco}

% default address
\setkomavar{fromname}{Max Mustermann}
\setkomavar{fromaddress}{Musterstraße 1\\12345 Musterstadt}

% default signature
\renewcommand*{\raggedsignature}{\raggedright}
\setkomavar{signature}{\usekomavar{fromname}}
#+END_SRC

And a second LCO file defining a signature graphic:

#+BEGIN_SRC latex
\ProvidesFile{Signed.lco}

% use signature graphic
\usepackage{graphicx}
\setkomavar{signature}{\\[-2.5\baselineskip]\includegraphics{/home/he-sk/org/data/12/441E34-D2DE-4207-9B4A-23A4DA7AF870/Unterschrift.png}\\[-0.9\baselineskip]\usekomavar{fromname}}
#+END_SRC

Then, a signed letter can be created as follows:

#+LCO: Default Signed


diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1ffb455..31ccd89 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,23 +80,38 @@
   :group 'org-export-koma-letter
   :type 'string)
 
-(defcustom org-koma-letter-closing "See you soon,"
-  "Koma-Letter's closing, as a string."
+(defcustom org-koma-letter-sender nil
+  "Sender's name, as a string."
   :group 'org-export-koma-letter
   :type 'string)
 
-(defcustom org-koma-letter-from-address "Somewhere \\ Over the rainbow."
+(defcustom org-koma-letter-from-address nil
   "Sender's address, as a string."
   :group 'org-export-koma-letter
   :type 'string)
 
-(defcustom org-koma-letter-opening "Dear Sir,"
+(defcustom org-koma-letter-phone-number nil
+  "Sender's phone number, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-koma-letter-email nil
+  "Sender's email, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-kom

Re: [O] Best practices for literate programming [was: Latex export of tables]

2013-04-21 Thread Rasmus Pank Roulund

Dear Tom,

> I suppose this depends on what is meant by "reproducible."
>
> My goal is to produce a compendium as defined by Gentleman and Lang
> (see Gentleman R, Lang DT (2004). "Statistical Analyses and Reproducible
> Research." Technical report, Bioconductor Project. URL
> http://www.bepress.com/bioconductor/paper2).  
>
> I keep the init.el file as a babel source block with the reproducible
> document, so it can be tangled. I also have an editing setup in a babel
> source block that activates many of the same features handled by the
> init.el file, but also configures the new exporter to look for init.el
> (which might have a different name). The filters are all part of the Org
> document, too, and get pulled into the init.el file with noweb
> references.

My issue here is that this approach might lead to copy-paste
"preambles" which may or may not be desirable.  I can certainly see
the attraction in being able to just tangle the setup.  In fact for my
thesis I also had a preamble.tex blog in my file.  Your proposed setup
here is perhaps better in that it uses emacs-lisp.

Still, say I'm working on two files A and B.  If I fix a bug in
"preamble" A I would have to manually copy it over to B.  

Thus, the main question is how to distribute updates?  I guess one
could keep a separate file, but then we are back at square one in a
way. . .

One possibility might be a file structure like this

setup.org
A/project-A.org
A/setup-A.org
B/project-B.org
B/setup-B.org

where A and B both has a block like
#+BEGIN_SRC org
* Preamlbe:noexport:
#+INCLUDE: "../setup.org"
#+INCLUDE: "setup-A.org"
#+END_SRC

To ship it off one would only have to write a command to replacing
#+INCLUDE with its content.  The exporter could likely be used for
this and one could produce an archive version when signing off a
project.

Even more robust, #+INCLUDE: would look for files in org-directory (it
might already do, I didn't check).

Am I missing something obvious (probably?) in the above stream of
random thoughts?  It's kind of a LaTeX-ish way of dealing with it, I
guess.

> I am able to distribute the compendium, typically as a single
> document (sometimes with associated data files produced by an
> on-line service that can't be used programmatically), which I
> believe is a good step toward reproducibility.

Agreed.

–Rasmus

-- 
Send from my Emacs



[O] Error after moving from 7.9.4 to 8.0: Cannot open load file org-element

2013-04-21 Thread Brice Waegeneire
Hello org-mode users,

In moving from 7.9.4 to 8.0 org-mode I stumbled upon the following
error (emacs --debug-init). The "[...]" is a portion i couldn't copy:

Debugger entered--Lisp error: (file-error "Cannot open load file"
"org-mode/lisp/org-element")
org-element-at-point()
org-store-link(nil)
org-babel-tangle-single-block(1)
org-babel-tangle-collect-blocks("emacs-lisp" nil)
org-babel-tangle(nil "~/.emacs.d/ldk-emacs.el" "emacs-lisp")
org-babel-tangle-file("~/.emacs.d/ldk-emacs.org"
"~/.emacs.d/ldk-emacs.el" "emacs-lisp")
org-babel-load-file("~/.emacs.d/ldk-emacs.org")
eval-buffer(# nil "/home/lambda/.emacs.d/init.el" nil
t) ; Reading at buffer position 397
load-with-code-conversion("/home/lambda/.emacs.d/init.el"
"/home/lambda/.emacs.d/init.el" t t)
load("/home/lambda/.emacs.d/init" t t)
#[0 " \205\262

[...]

[init-file-user system-type delayed-warnings-list user-init-file
inhibit-default-init inhibit-startup-screen ms-dos "~" "/_emacs"
windows-nt "/.emacs" directory-files nil "^\\.emacs\\(\\.elc?\\)?$"
"~/.emacs" "^_emacs\\(\\.elc?\\)?$" (initialization "`_emacs' init
file is deprecated, please use `.emacs'") "~/_emacs" t load
expand-file-name "init" file-name-as-directory "/.emacs.d"
file-name-extension "elc" file-name-sans-extension ".el" file-exists-p
file-newer-than-file-p message "Warning: %s is newer than %s" sit-for
1 "default"] 7 "\n\n(fn)"]()
command-line()
normal-top-level()

For the upgrade I've deleted the org-mode folder, replaced in my emacs
configuration file "release_7.9.4" by "release_8.0" and then restarted
emacs. el-get had then installed org-mode 8.0, after that I don't have
the issue yet but it occurs after I had modified my emacs'
configurartion  (whatever the modification) and restarted it.

You can find my emacs configuration here :
https://gist.github.com/korthaerd/27877114462e2475f82e#file-emacs-debug-init-8-0

Can some help me with that ?

Coridally, liberdiko.



Re: [O] merging per-file (or heading) TODO sequences

2013-04-21 Thread Carsten Dominik

On 21.4.2013, at 11:08, Eric Abrahamsen  wrote:

> I could have sworn I've done this successfully before, but...
> 
> I need a special sequence of TODO keywords for one file -- actually just
> one headline in particular. I thought I remembered this used to be
> possible, but it doesn't seem to be anymore.
> 
> Setting #+SEQ_TODO: FOO | BAR at the top of the file actually
> overwrites the existing value of `org-todo-keywords' for that file. In
> this case I'd like to either:
> 
> 1. Create this sequence for a single subtree (it's okay if it clobbers
> the global value of `org-todo-keywords', so long as it's *only* for this
> subtree), or

This is currently not possible.

> 
> 2. Set the new sequence at the top of the file, but merge this sequence
> with the global value of `org-todo-keywords'.

And neither is this.

But you do have the options Richard mentions in his post.

Regards

- Carsten



Re: [O] merging per-file (or heading) TODO sequences

2013-04-21 Thread Richard Lawrence
Hi Eric,

Eric Abrahamsen  writes:

> I could have sworn I've done this successfully before, but...
>
> I need a special sequence of TODO keywords for one file -- actually just
> one headline in particular. I thought I remembered this used to be
> possible, but it doesn't seem to be anymore.
>
> Setting #+SEQ_TODO: FOO | BAR at the top of the file actually
> overwrites the existing value of `org-todo-keywords' for that file. In
> this case I'd like to either:
>
> 1. Create this sequence for a single subtree (it's okay if it clobbers
> the global value of `org-todo-keywords', so long as it's *only* for this
> subtree), or
>
> 2. Set the new sequence at the top of the file, but merge this sequence
> with the global value of `org-todo-keywords'.
>

Not sure if this is exactly what you want, but you can have multiple
#+SEQ_TODO lines at the top of your file, e.g.:

#+SEQ_TODO: TODO INPROGRESS WAITING | DONE CANCELED
#+SEQ_TODO: FIND PRINT READ NOTES | DONE CANCELED

Then trees will use the different sequences depending on which state you
place them in initially.

Best,
Richard




Re: [O] odt export not working

2013-04-21 Thread Manfred Lotz
On Sun, 21 Apr 2013 22:29:10 +0800
Eric Abrahamsen  wrote:

> Manfred Lotz  writes:
> 
> > Hi there,
> > Using org-mode 8.0-2-g77476c (fedora 18 system) exporting to odt
> > doesn't work. zip program is available. When I do =C-c C-e= the
> > *Org Export Dispatcher* buffer pops up but showing nothing related
> > to odt. When now typing =o o= I get =Invalid Key=.
> >
> > Any idea what's going wrong.
> 
> Are you calling (require 'ox-odt) somewhere in your config? Or
> configuring `org-export-backends'? ODT export isn't loaded by default,
> you'll have to load it explicitly by one of those two methods.
> 
> Hope that's the extent of the problem,
> 
> Eric
> 
> 
> 

Yep, that was it. I didn't know that.

Thanks a lot, Eric.


-- 
Manfred




Re: [O] odt export not working

2013-04-21 Thread Eric Abrahamsen
Manfred Lotz  writes:

> Hi there,
> Using org-mode 8.0-2-g77476c (fedora 18 system) exporting to odt
> doesn't work. zip program is available. When I do =C-c C-e= the
> *Org Export Dispatcher* buffer pops up but showing nothing related to
> odt. When now typing =o o= I get =Invalid Key=.
>
> Any idea what's going wrong.

Are you calling (require 'ox-odt) somewhere in your config? Or
configuring `org-export-backends'? ODT export isn't loaded by default,
you'll have to load it explicitly by one of those two methods.

Hope that's the extent of the problem,

Eric




[O] odt export not working

2013-04-21 Thread Manfred Lotz
Hi there,
Using org-mode 8.0-2-g77476c (fedora 18 system) exporting to odt
doesn't work. zip program is available. When I do =C-c C-e= the
*Org Export Dispatcher* buffer pops up but showing nothing related to
odt. When now typing =o o= I get =Invalid Key=.

Any idea what's going wrong.

-- 
Thanks,
Manfred





Re: [O] New maintainer

2013-04-21 Thread Eric Abrahamsen
Bastien  writes:

> Eric Abrahamsen  writes:
>
>> It's also been a pleasure to witness the surprisingly successful
>> marriage of two different coding styles: Bastien's damn-the-torpedoes
>> patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
>> return to first principles: structure and cleanliness. I'm quite
>> convinced that the two approaches have been equally essential to Org
>> mode's current success (and advance apologies for any perceived
>> mischaracterizations!).
>
> Yeah.
>
> Let me quote Jamie Zawinski's interview from "Coders at work":
>
>   Zawinski: [...] It's great to rewrite your code and make it cleaner
>   and by the third time it'll actually be pretty.  But that's not the
>   point---you're not here to write code, you're here to ship products.
>   
>   Seibel: Folks engaged in overengineering usually say, "Well, once
>   I've got this framework in place everything will be easy after that.
>   So I'll actually save time by doing this.
>   
>   Zawinski: That is always the theory.
>
>   Seibel: And there are times when that theory is true, when someone
>   has good sense and the framework isn't too elaborate, and it does
>   save time.
>
> I actually agree with both points of view, especially with the last
> sentence.  And it's easy to play jwz when you can trust someone for
> playing the other role :)

And, without re-opening any tedious discussions that we've already put
behind us, it's generally the person playing the jwz role who ends up as
"maintainer" -- and that's probably as it should be.




Re: [O] agenda: personal priority for today

2013-04-21 Thread Christopher Allan Webber
Bastien writes:

> Hi Christopher,
>
> Christopher Allan Webber  writes:
>
>> Just store the property on the item itself
>
> But this solution is task-based, not agenda-based.
>
> The "Sorting" property you describe would be useful in one
> agenda and not in one other -- so this does not really fit
> for the OP use-case I guess.

That's true...
I gues it would still be useful for me on my main agenda ;)



Re: [O] org-agenda is not working after org-mode update

2013-04-21 Thread Bastien
Hi Sergey,

Sergey Pashinin  writes:

> I updated org-mode yesterday through Melpa.
> After that org-agenda stopped working for me.

Please read the release notes carefully:

  http://orgmode.org/Changes.html

When installing from Melpa (or GNU ELPA, or Org ELPA),
this needs to be done in a fresh Emacs session.

I hope this fixes your problem.

-- 
 Bastien



Re: [O] Release 8.0

2013-04-21 Thread Bastien
Hi Memnon,

Memnon Anon  writes:

>> To include other entries too, you can set the
>> limit to a negative number.  For example (setq org-agenda-max-tags 3)
> (setq org-agenda-max-tags -3) ? 

Indeed.

>> will not show the fourth tagged headline (and beyond), but it will also
>> show non-tagged headlines.
>
>
>> Use `%s' for displaying "breadcrumbs" in the agenda view
>> 
>^%b

Ditto.

Fixed, thanks!

-- 
 Bastien



Re: [O] New maintainer

2013-04-21 Thread Bastien
Eric Abrahamsen  writes:

> It's also been a pleasure to witness the surprisingly successful
> marriage of two different coding styles: Bastien's damn-the-torpedoes
> patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
> return to first principles: structure and cleanliness. I'm quite
> convinced that the two approaches have been equally essential to Org
> mode's current success (and advance apologies for any perceived
> mischaracterizations!).

Yeah.

Let me quote Jamie Zawinski's interview from "Coders at work":

  Zawinski: [...] It's great to rewrite your code and make it cleaner
  and by the third time it'll actually be pretty.  But that's not the
  point---you're not here to write code, you're here to ship products.
  
  Seibel: Folks engaged in overengineering usually say, "Well, once
  I've got this framework in place everything will be easy after that.
  So I'll actually save time by doing this.
  
  Zawinski: That is always the theory.

  Seibel: And there are times when that theory is true, when someone
  has good sense and the framework isn't too elaborate, and it does
  save time.

I actually agree with both points of view, especially with the last
sentence.  And it's easy to play jwz when you can trust someone for
playing the other role :)

-- 
 Bastien



Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]

2013-04-21 Thread Bastien
Hi Richard,

Richard Lawrence  writes:

> I've been trying to get iCalendar export working with my agenda files
> again since upgrading to 8.0, and I've found that footnotes break the
> agenda export to .ics.  The problem is that a plain text version of the
> footnotes in the file ends up in the output "floating loose"---not
> wrapped by VEVENT tags or any other tags---resulting in an unparseable
> .ics file (at least according to Google Calendar).

I tried this patch but for some reason it does not work.

I did not look further, surely Nicolas has something that
works.  I agree footnotes should be turned off by default
for the .ics export.

diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 49299b0..ceb2df0 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -266,6 +266,7 @@ re-read the iCalendar file.")
   '((:exclude-tags
  "ICALENDAR_EXCLUDE_TAGS" nil org-icalendar-exclude-tags split)
 (:with-timestamps nil "<" org-icalendar-with-timestamps)
+(:with-footnotes nil "f" nil)
 (:with-vtodo nil nil org-icalendar-include-todo)
 ;; The following property will be non-nil when export has been
 ;; started from org-agenda-mode.  In this case, any entry without

-- 
 Bastien


Re: [O] [solution] Chinese characters in Beamer export

2013-04-21 Thread Feng Shu
James Harkins  writes:

Maybe my org config can give you some informations:

https://github.com/tumashu/emacs-helper/blob/master/eh-org.el



> FWIW, this is what it took for me to get Chinese characters to export
> in beamer. (Adding a TODO to write this up for worg.)
>
> 1. Use texlive 2012. (The Ubuntu packages for 12.04 date back to 2009.
> I couldn't get them to work for this.)
>
> 2. In the preamble of your org document:
>
> #+LaTeX_HEADER: \usepackage{CJKutf8}
> #+BEGIN_LaTeX
> \AtBeginDocument{%
> \begin{CJK}{UTF8}{gbsn}}
> \AtEndDocument{%
> \end{CJK}}
> #+END_LaTeX
>
> These LaTeX snippets come from the documentation of the CJK package.
> "gbsn" is for simplified Chinese characters (used on the mainland).
> Other options for Chinese may be found at:
>
> http://en.wikibooks.org/wiki/LaTeX/Internationalization#Chinese
>
> That pretty much did it (although it took quite a bit of sleuthing to
> find this, thanks to a fair amount of out of date information that
> will never, ever die in the big search engines).
>
> Except for one problem. LaTeX inputenc will complain about the Chinese
> characters being "not set up for use with LaTeX," but the document
> does render. I'll have to leave that question aside for the moment,
> but this isn't the last time I'll need Chinese characters in a
> presentation so I'll come back to that before posting anything on
> worg. (Or, maybe a sophisticated LaTeX user knows what is wrong?)
>
> hjh

-- 



Re: [O] New maintainer

2013-04-21 Thread Carsten Dominik

On 21.4.2013, at 10:06, Jambunathan K  wrote:

> Jambunathan K  writes:
> 
>>> Well, the FSF's intention here is to make sure that contributors report
>>> back when they change employers, and the new employer doesn't want that
>>> his employees contribute to some GNU project (maybe because that project
>>> is in the same business as the company).  So I think of that more of a
>>> safety measure in order not to run into long-running, painful
>>> lawsuits.
> 
> You are missing out an important aspect - that of "enforcement".  An
> organization will most likely "choose to enforce" but an RJH (like me)
> won't.
> 
> That is, the employer can (presumably) send his lawyer to a the court
> with the employment contract and say
> 
>"Employee can assign rights (and FSF can very well accept it).  But
> the assignation has no legal validity because it is not within
> employee's right to do so.  Employee himself agreed that he will
> abide by  while on our pay.  We are asserting and
> enforcing our position now."
> 
> For an assignment to have legal validity, multiple parties - FSF,
> contributor and contributor's employer - should *converge*.
> 
> When there is no convergence of *all* parties , the "assignment" stands
> on weaker grounds.
> 
> Standing on weaker ground is precisely what FSF wants to avoid at all
> costs.
> 
> Jambunathan K.

This discussion is now considered off-topic for this list.
Please take it elsewhere.

- Carsten




[O] org-agenda is not working after org-mode update

2013-04-21 Thread Sergey Pashinin

I updated org-mode yesterday through Melpa.
After that org-agenda stopped working for me.

It says:

Invalid function: org-with-silent-modifications

In my script I had this:

(org-agenda nil "n")

Trying to execute it now gives:

Debugger entered--Lisp error: (invalid-function 
org-with-silent-modifications)

  org-with-silent-modifications(nil)
  org-refresh-category-properties()
  byte-code("\306!\203\.
  org-agenda-prepare-buffers(("/data/org/work.org" ...))
  org-agenda-prepare("Agenda and all TODO's")
  (let nil (org-agenda-prepare name))
  eval((let nil (org-agenda-prepare name)))
  org-let(nil (org-agenda-prepare name))
  org-agenda-run-series("Agenda and all TODO's" (((agenda "") (alltodo 
""

  org-agenda(nil "n")
  eval((org-agenda nil "n") nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

-

Also have to add:

I had only "(require 'org)" in my file and it started to complain: "I 
don't know org-agenda-buffer-name variable"


So I had to add:

(require 'org)
(require 'org-agenda)
;;(require 'org-compat)

But still got an error I described above.
Looks like a bug



Re: [O] Release 8.0

2013-04-21 Thread Memnon Anon
Bastien  writes:

> I'm releasing Org 8.0.

Excellent.

> To include other entries too, you can set the
> limit to a negative number.  For example (setq org-agenda-max-tags 3)
(setq org-agenda-max-tags -3) ? 
> will not show the fourth tagged headline (and beyond), but it will also
> show non-tagged headlines.


> Use `%s' for displaying "breadcrumbs" in the agenda view
> 
   ^%b

>   • New speedy key `s' pour org-narrow-to-subtree

Memnon




Re: [O] [Bug] HTML Exporter Does Not Convert \\ To

2013-04-21 Thread Eric Abrahamsen
"T.F. Torrey"  writes:

> The old exporter would convert \\ at the end of a line to  to
> force a line break. The manual still says that \\ will force a line
> break, but the new HTML exporter, while indeed breaking the line
> there, does not insert the  to make it render as a new line.
>
> This is using the latest version from Git.
>
> I think this is a bug, not a limitation of the new exporter.
>
> Best regards,
> Terry

Hi Terry,

I just tried with emacs -Q (I'm on 24.3.1) and git Org mode, and the \\
is exported as "". Can you check with emacs -Q? If you look in
ox-html.el, you'll see that the function `org-html-line-break' should
produce a "\n".

Could something else be going wrong?

E




Re: [O] New maintainer

2013-04-21 Thread Eric Abrahamsen
Bastien  writes:

> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)

Hats off, Bastien, it was deftly done.

It's also been a pleasure to witness the surprisingly successful
marriage of two different coding styles: Bastien's damn-the-torpedoes
patch-the-SOB-and-get-it-out-the-door approach, matched with Nicolas'
return to first principles: structure and cleanliness. I'm quite
convinced that the two approaches have been equally essential to Org
mode's current success (and advance apologies for any perceived
mischaracterizations!).

I'm one of the post-Carsten young'uns, but I can't imagine we'll have
any complaints with the man who started it all...

Eric




[O] [Bug] HTML Exporter Does Not Convert \\ To

2013-04-21 Thread T.F. Torrey
The old exporter would convert \\ at the end of a line to  to
force a line break. The manual still says that \\ will force a line
break, but the new HTML exporter, while indeed breaking the line
there, does not insert the  to make it render as a new line.

This is using the latest version from Git.

I think this is a bug, not a limitation of the new exporter.

Best regards,
Terry
-- 
T.F. Torrey



Re: [O] New maintainer

2013-04-21 Thread T.F. Torrey
Thank you for your hard work, Bastien. You've done a fantastic job
under unusually adversarial conditions.

On Thu, Apr 18, 2013 at 9:53 AM, Bastien  wrote:
> Dear all,
>
> I'm stepping down as the Org maintainer.
>
> Carsten accepted to step up, if the community agrees.
> Please raise your thumbs up or your concerns, if any.
>
> I'm glad I had this opportunity to work as "Robin" and
> I'm even more glad "Batman" may strike back!
>
> :)
>
> --
>  Bastien
>
>



Re: [O] [PATCH] adjust C-c C-c behavior on headlines whose text is a link

2013-04-21 Thread Eric Abrahamsen
Eric Abrahamsen  writes:

> An alternate version would pass the funcall to the :parent element *no
> matter what*, seeing as 'C-c C-c' is currently always a no-op

"on a link", I should have said

>, and user-defined hooks have already been run. We could just pass it
>on up and see what happens...
>
> Eric




[O] [PATCH] adjust C-c C-c behavior on headlines whose text is a link

2013-04-21 Thread Eric Abrahamsen
If you've got a headline where the text is a link, C-c C-c on that
headline will only consider the fact that it's in a link, not that it's
in a headline. Ie, you get "can do nothing useful", rather than setting
tags.

This patch checks for this condition and passes the C-c C-c to the
headline.

An alternate version would pass the funcall to the :parent element *no
matter what*, seeing as 'C-c C-c' is currently always a no-op, and
user-defined hooks have already been run. We could just pass it on up
and see what happens...

Eric

>From 2980cd31a05a7b2accc04ce431842a6bf27f6c6c Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sun, 21 Apr 2013 17:32:26 +0800
Subject: [PATCH] lisp/org.el (org-ctrl-c-ctrl-c): Set tags for headlines whose
 text is a link

* lisp/org.el (org-ctrl-c-ctrl-c): 'C-c C-c' on a link is usually a
  no-op. If that link is in a headline, act as if the 'C-c C-c' was
  called on the headline, not the link.
---
 lisp/org.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 691f880..74d9d61 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20106,6 +20106,12 @@ This command does many different things, depending on context:
 	(when (and (eq (org-element-type parent) 'item)
 		   (= (point-at-bol) (org-element-property :begin parent)))
 	  (setq context parent type 'item
+	;; When heading text is a link, treat the heading, not the link,
+	;; as the current element
+	(when (eq type 'link)
+	  (let ((parent (org-element-property :parent context)))
+	(when (and (eq (org-element-type parent) 'headline))
+	  (setq context parent type 'headline
 	;; Act according to type of element or object at point.
 	(case type
 	  (clock (org-clock-update-time-maybe))
-- 
1.8.2.1



[O] merging per-file (or heading) TODO sequences

2013-04-21 Thread Eric Abrahamsen
I could have sworn I've done this successfully before, but...

I need a special sequence of TODO keywords for one file -- actually just
one headline in particular. I thought I remembered this used to be
possible, but it doesn't seem to be anymore.

Setting #+SEQ_TODO: FOO | BAR at the top of the file actually
overwrites the existing value of `org-todo-keywords' for that file. In
this case I'd like to either:

1. Create this sequence for a single subtree (it's okay if it clobbers
the global value of `org-todo-keywords', so long as it's *only* for this
subtree), or

2. Set the new sequence at the top of the file, but merge this sequence
with the global value of `org-todo-keywords'.

I was sure this was possible! What am I missing?

Thanks,
Eric




Re: [O] New maintainer

2013-04-21 Thread Jambunathan K
Jambunathan K  writes:

>> Well, the FSF's intention here is to make sure that contributors report
>> back when they change employers, and the new employer doesn't want that
>> his employees contribute to some GNU project (maybe because that project
>> is in the same business as the company).  So I think of that more of a
>> safety measure in order not to run into long-running, painful
>> lawsuits.

You are missing out an important aspect - that of "enforcement".  An
organization will most likely "choose to enforce" but an RJH (like me)
won't.

That is, the employer can (presumably) send his lawyer to a the court
with the employment contract and say

"Employee can assign rights (and FSF can very well accept it).  But
 the assignation has no legal validity because it is not within
 employee's right to do so.  Employee himself agreed that he will
 abide by  while on our pay.  We are asserting and
 enforcing our position now."

For an assignment to have legal validity, multiple parties - FSF,
contributor and contributor's employer - should *converge*.

When there is no convergence of *all* parties , the "assignment" stands
on weaker grounds.

Standing on weaker ground is precisely what FSF wants to avoid at all
costs.

Jambunathan K.



Re: [O] Does Org support Related or "See Also" Properties?

2013-04-21 Thread David Rogers
"Nick M. Daly"  writes:

> Hi Bastien, thanks for the prompt reply.
>
> Bastien writes:
>
>>> When exported into an agenda, the consolidated org agenda would read:
>>>
>>> Friday   19 April 2013
>>>   customer:  09:00-09:30 Scheduled:  TODO Meeting with Pete
>>
>> The problem is: what would RET do on this agenda line?  Go to which
>> entry?  You can always put some hacks in `org-agenda-finalize-hook'
>> but it's easier to try to keep your Org files clean ;)
>
> I would assume that RET would jump to the source item (the one with the
> "See also" property).

If I were using this, I would forget to mark any "See also", or else I
would do it, and forget I had already done so, and end up marking _both_
of them "See also". :)

Knowing that you have an entry elsewhere for this person or that event,
might give you the opportunity to do some kind of clever tricks with
links...

-- 
David R