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

[Suvayu Ali]

On Mon, Apr 22, 2013 at 01:03:28AM +0200, Alexander Baier wrote:
 Nicolas Goaziou n.goaz...@gmail.com writes:
 
  Hello,
 
  Suvayu Ali fatkasuvayu+li...@gmail.com 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:

  http://orgmode.org/worg/org-8.0.html
  http://orgmode.org/worg/exporters/

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] Source Code Syntax Highlighting in Beamer slides

[Bastien]

Hi Suvayu,

Suvayu Ali fatkasuvayu+li...@gmail.com 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

[Suvayu Ali]

On Mon, Apr 22, 2013 at 08:29:57AM +0200, Bastien wrote:
 Hi Suvayu,
 
 Suvayu Ali fatkasuvayu+li...@gmail.com 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.

Okay cool.  Thanks for repeating it again.  One of the weekends I'll try
to go through the tutorials and add the properties as appropriate.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

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

[Christian Egli]

Bastien b...@gnu.org writes:

 Hi Baptiste and Christian,

 Christian Egli christian.e...@sbs.ch 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))

Doh, yes of course.

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

Re: [O] New maintainer

[Andreas Röhler]

Hi Bastien,

Am 22.04.2013 00:39, schrieb 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.



Okay, a good news in circumstances.


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,


Precisely.


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 :)



Indeed.

Nonetheless, WRT the amount of traffic IMHO having someone to range things a 
little bit before Carsten must tell will be a great advantage.

Thanks all proving that great stuff,

Andreas

Re: [O] Using helm only for org refiling

[Alan Schmitt]

Sylvain Rousseau writes:

 Hello,

 I use the following patch (against release_8.0) to refile with helm. Just
 set org-completion-handler to 'helm.

Thanks a lot, this is very nice!

Any chance this patch may be applied in the official repository?

Alan

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

[Baptiste]

Hi,

you will find hereafter the patch after the little cleanup.

BTW, there is a  way (by code reading, not tested)  to force a milestone
with both  start and end : if  I am not  wrong, you may use  a :milestone
property of an org-entry to create a milestone task.

Not to  say that  it is not  advised to both  use :start  properties and
:SCHEDULED mechanism  in an  org entry  (you would  end with two /start/
elements in tj3).

*Le lun., avril 22 2013, Christian Egli a écrit*

Bastien b...@gnu.org writes:

   Hi Baptiste and Christian,
  
   Christian Egli christian.e...@sbs.ch 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))

Doh, yes of course.
--

: ~^v^~ Bat

From d36be8faf6ecbc722d75950f5bc664f2b9d87e27 Mon Sep 17 00:00:00 2001
From: Baptiste Fouques bate...@bat.fr.eu.org
Date: Mon, 22 Apr 2013 10:59:15 +0200
Subject: [PATCH] ox-taskjuggler.el: use :SCHEDULED and :DEADLINE as start and
 end for tasks

as a special behavior, for milestones, if both :SCHEDULED and :DEADLINE ar specified, then :SCHEDULED will be mark as the milestone date, and :DEADLINE will be checked against actual scheduled date by TJ3.

TINYCHANGE
---
 contrib/lisp/ox-taskjuggler.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 4724ec3..2c1dee7 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -754,6 +754,8 @@ a unique id will be associated to it.
 (org-element-property :COMPLETE task)))
  (depends (org-taskjuggler-resolve-dependencies task info))
  (effort (org-element-property :EFFORT task))
+ (start (org-taskjuggler-get-start task))
+ (end (org-taskjuggler-get-end task))
  (milestone
   (or (org-element-property :MILESTONE task)
   (not (or (org-element-map (org-element-contents task) 'headline
@@ -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))
+   (start (format   start %s\n start))
+   (end (format   start %s\n end
+ (and start (not milestone) (format   start %s\n start))
+ (and end (not milestone) (format   end %s\n end))
+
  (and depends
   (format   depends %s\n
   (org-taskjuggler-format-dependencies depends task info)))
--
1.8.1.2

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

[Alan Schmitt]

Hi,

Viktor Rosenfeld writes:

 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.

This looks very nice, thanks a lot.

I'm not sure about the procedure to apply this patch, however. Should I
do it myself?

 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?

You need to ask for write access.

I started writing a tutorial, but I was caught up in too many things and
could not finish it. If you want I can send you privately what I have
written (or I can push it to worg and we can edit it together).

Best,

Alan

[O] Tracking flexitime

[Thomas Koch]

Hi,

I'm searching for best practices to track flexi time with orgmode. I've a work 
contract of 8 hours per day in average. So I'd like to start a clock when I 
arrive at work, pause it for lunch and stop it when I leave.

I wouldn't like to rely only on the sum of the time spent on tasks since there 
is always work time that can hardly be assigned to a specific task.

So in my understanding I'd need two clocks: One for the time that I'm at work 
and the other one for the task I'm currently working on. The sum of the second 
clock will always be a little bit less than the first. But org-mode only 
supports one clock at a time?

The next question is, how can I see my current overtime account?

Google results:

There has been a similar question on stackoverflow:
http://stackoverflow.com/questions/10122813/tracking-flexitime-using-emacs-org-mode

Somewhat related: lisp code for weekly timesheets
http://lvalue.blogspot.ch/2010/02/weekly-timesheets-in-org-mode.html

What have I done today?
http://superuser.com/questions/196441/emacs-org-mode-as-a-work-diary

Thank you,

Thomas Koch, http://www.koch.ro

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

[Nicolas Goaziou]

Hello,

Alan Schmitt alan.schm...@polytechnique.org writes:

 I'm not sure about the procedure to apply this patch, however. Should I
 do it myself?

You're the file maintainer, aren't you? :)


Regards,

-- 
Nicolas Goaziou

Re: [O] Tracking flexitime

[Detlef Steuer]

Hi Thomas,

my way to handle this situation is a datetime tree.

In the morning 
C-c a a i j 
jumps to today and C-u C-c ! inserts a timestamp.
In the evening the same procedure followed by a 
C-u C-c y to calculate my time in the office.

Friday evening I calculate over/under time for that week (in my head)
and note it.

A typical Friday entry looks like that:

*** 2013-04-19 Freitag
[2013-04-19 Fr 08:45]--[2013-04-19 Fr 17:05] 08:20 (+2:00 +11:10)


+2:00 over/undertime this week +11:10 is total over/undertime.

Very litte automatisation, but only say 1 min effort a week. 

Hth
Detlef


On Mon, 22 Apr 2013 10:35:58 +0200
Thomas Koch tho...@koch.ro wrote:

 Hi,
 
 I'm searching for best practices to track flexi time with orgmode. I've a 
 work 
 contract of 8 hours per day in average. So I'd like to start a clock when I 
 arrive at work, pause it for lunch and stop it when I leave.
 
 I wouldn't like to rely only on the sum of the time spent on tasks since 
 there 
 is always work time that can hardly be assigned to a specific task.
 
 So in my understanding I'd need two clocks: One for the time that I'm at work 
 and the other one for the task I'm currently working on. The sum of the 
 second 
 clock will always be a little bit less than the first. But org-mode only 
 supports one clock at a time?
 
 The next question is, how can I see my current overtime account?
 
 Google results:
 
 There has been a similar question on stackoverflow:
 http://stackoverflow.com/questions/10122813/tracking-flexitime-using-emacs-org-mode
 
 Somewhat related: lisp code for weekly timesheets
 http://lvalue.blogspot.ch/2010/02/weekly-timesheets-in-org-mode.html
 
 What have I done today?
 http://superuser.com/questions/196441/emacs-org-mode-as-a-work-diary
 
 Thank you,
 
 Thomas Koch, http://www.koch.ro
 
 

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

[Bastien]

Hi Viktor,

Viktor Rosenfeld listuse...@gmail.com writes:

 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.

Can you test this patch against latest maint or master branch?

Thanks,

From 4c5a5d0fd1433f82e66344d2038f735c09643e3f Mon Sep 17 00:00:00 2001
From: Bastien Guerry b...@altern.org
Date: Mon, 22 Apr 2013 11:25:39 +0200
Subject: [PATCH] org.el (org-agenda-prepare-buffers): Fix setting of
 `org-tag-alist'

* org.el (org-agenda-prepare-buffers): Don't append tags to
`org-tag-alist-for-agenda' when `org-tag-alist-for-agenda' is
not initially set.

Thanks to Viktor Rosenfeld for reporting this.
---
 lisp/org.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 70bee87..2f04f1c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17974,7 +17974,8 @@ When a buffer is unmodified, it is just killed.  When modified, it is saved
 		  (append org-todo-keyword-alist-for-agenda org-todo-key-alist))
 	(setq org-drawers-for-agenda
 		  (append org-drawers-for-agenda org-drawers))
-	(unless (equal org-tag-alist-for-agenda org-tag-alist)
+	(unless (and org-tag-alist-for-agenda
+			 (equal org-tag-alist-for-agenda org-tag-alist))
 	  (setq org-tag-alist-for-agenda
 		(append org-tag-alist-for-agenda org-tag-alist)))
 	(if org-group-tags
-- 
1.8.2


-- 
 Bastien

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

[Alan Schmitt]

Nicolas Goaziou writes:

 Hello,

 Alan Schmitt alan.schm...@polytechnique.org writes:

 I'm not sure about the procedure to apply this patch, however. Should I
 do it myself?

 You're the file maintainer, aren't you? :)

;-)

A couple notes about the patch:
- Could you create it using git format-patch? This way we'll have
more metadata in the commit.
- I think there is an issue with the handling of signatures. I tried
with an old letter that uses a LCO with a graphical signature in it, but
it gets overridden upon export. Here is the generated TeX.

#+BEGIN_SRC latex
\LoadLetterOption{InriaRennesFR}
\setkomavar{signature}{\usekomavar{fromname}}
#+END_SRC

It seems to come from this part of the patch:

#+BEGIN_SRC emacs-lisp
 (signature (plist-get info :signature)))
 (concat
  ;; Letter Class Option File
  (when lco 
(let ((lco-files (split-string lco  ))
  (lco-def ))
  (dolist (lco-file lco-files lco-def)
(setq lco-def (format %s\\LoadLetterOption{%s}\n lco-def 
lco-file)))
  lco-def))
  ;; Define From data.
  (when sender (format \\setkomavar{fromname}{%s}\n sender))
  (when from-address (format \\setkomavar{fromaddress}{%s}\n 
from-address))
  (when phone-number (format \\setkomavar{fromphone}{%s}\n phone-number))
  (when email (format \\setkomavar{fromemail}{%s}\n email))
  (when signature (format \\setkomavar{signature}{%s}\n signature
#+END_SRC

If signature is set for some reason (and it seems to be by default),
then it will override what is in the LCO. I have not found a way to
set the options such that the signature from the LCO gets picked up.

Alan

[O] Ignore following space coding?

[Hideki Saito]

Hello,
I briefly searching the list and but I'm unsure if this was discussed
before, so excuse me if this was discussed before.

I've got a question regarding how I can make this work with languages
that doesn't separate words with spaces.

The problem is if I'm trying to write:
文字*太字*文字

This essentially prevents text surrounded by * treated as a regular
character as opposed to marked as bold, as this is pretty much
equivalent of the following case:

aa*bb*aa

I could make the previous text so it says:
文字 *太字* 文字 (aa *bb* aa)

inserting space between them. But this means that space gets exported.
I'm curious if there are any way I can tell Org-mode yes there's a
space here so you know where to separate but do not treat like so when
you are exporting.

If there are any suggestions, that will be helpful!

Cheers,

Hideki Saito hide...@gmail.com
http://goo.gl/ErBLy

Re: [O] Using helm only for org refiling

[Sylvain Rousseau]

Glad to be of some help!

I doubt this will be applied since helm is not bundled in emacs but we
could definitely use a more general completion handler that may take a
function and write that function outside of org's code.


Sylvain.

Re: [O] Tracking flexitime

[Thomas Koch]

On Monday, April 22, 2013 10:53:08 AM Detlef Steuer wrote:
 Hi Thomas,
 
 my way to handle this situation is a datetime tree.
 
 In the morning
 C-c a a i j
 jumps to today and C-u C-c ! inserts a timestamp.
 In the evening the same procedure followed by a
 C-u C-c y to calculate my time in the office.
 
 Friday evening I calculate over/under time for that week (in my head)
 and note it.
 
 A typical Friday entry looks like that:
 
 *** 2013-04-19 Freitag
 [2013-04-19 Fr 08:45]--[2013-04-19 Fr 17:05] 08:20 (+2:00 +11:10)
 
 
 +2:00 over/undertime this week +11:10 is total over/undertime.
 
 Very litte automatisation, but only say 1 min effort a week.

Thank you Detlef for sharing this. However I can not follow.

- C-c a runs the command org-agenda
- a selects calendar for current week or day
- i runs the command org-agenda-diary-entry
- j ???

- What is a datetime tree?

- Do you have an extra file only to track you time at work? Could you share 
(privately?) such a file?

- I also could not find the binding for C-c y. What does it do?

I guess you also use functionality of the calendar/diary package of emacs?

Regards,

Thomas Koch, http://www.koch.ro

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

[Rasmus]

Viktor,

Looks nice!

 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?

Ask Bastien or perhaps Carsten now for write access (you need to
provide your public key).  I can look through it when uploaded.

 KOMA scrlttr2 export: Improve export configuration options.

 [...]
 
 * 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).

Thanks.  And sorry for not providing a final patch myself; school/work
suddenly exploded.

 * 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.

This was certainly an outstanding bug that I've also been annoyed with.


 [...]
 * 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

In a similar spirit to subject is firsthead.  First head is displayed
by default in scrlttr2 as far as I recall, which is annoying.

If we make foldmark an option should it not be a string accepting
values from Table 4.3.: Combinable values for the configuration of
folding marks with option foldmarks in the KOMA-Script manual?

 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.

I wasn't aware of these options.  Thanks.

 * 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:

Cool.


 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

I agree with getting rid of silly defaults. 


  
 +(defcustom org-koma-letter-opening Dear Madam or Sir,
Letter's opening, as a string.
:group 'org-export-koma-letter
:type 'string)

While I also mainly write English letters I don't think we need to
assume everyone does.  I'd also opt for a default nil here.

  
 +(defcustom org-koma-letter-closing Sincerely yours,
 +  Koma-Letter's closing, as a string.
:group 'org-export-koma-letter
:type 'string)

ditto.
  
 +(defcustom org-koma-letter-use-subject untitled
 +  Use the title as the letter's subject.
 +  :group 'org-export-koma-letter
 +  :type 'string)

Perhaps the default should depend on whether a title is present?

 +(defcustom org-koma-letter-use-foldmarks t
 +  Print foldmarks.
 +  :group 'org-export-koma-letter
 +  :type 'boolean)
 +
 +(defcustom org-koma-letter-use-phone t
 +  Print sender's phone number.
 +  :group 'org-export-koma-letter
 +  :type 'boolean)
 +
 +(defcustom org-koma-letter-use-email t
 +  Print sender's email address.
 +  :group 'org-export-koma-letter
 +  :type 'boolean)
 +
 +(defcustom org-koma-letter-use-place t
 +  Print the letter's place next to the date.
 +  :group 'org-export-koma-letter
 +  :type 'boolean)
 +

Sorry for not testing this myself, but what is the behavior if
e.g. org-koma-letter-use-place is t but I didn't specify a place?
Will it print a nil or nothing?


'(?k Export with KOMA Scrlttr2
 -   ((?K As LaTeX buffer org-koma-letter-export-as-latex)
 - (?k As LaTeX file org-koma-letter-export-to-latex)
 +   ((?L As LaTeX buffer org-koma-letter-export-as-latex)
 + (?l As LaTeX file org-koma-letter-export-to-latex)
   (?p As PDF file org-koma-letter-export-to-pdf)
 - (?O As PDF file and open
 + (?o As PDF file and open
   (lambda (a s v b)

Another approach (which I also somehow like) is to put it under the
LaTeX menu.  E.g. like beamer or like org-ravel ¹  

 +   (let ((with-place (plist-get info :with-place))
 +  (place (plist-get info :place)))
 + (when (or place (not with-place)) 
 +   (format \\setkomavar{place}{%s}\n (if with-place place 

Wouldn't this work better: E.g. it wouldn't allow a place when place
is nil or when with-place is nil?

(when (and place (not with-place))
  (format 

Re: [O] Tracking flexitime

[Memnon Anon]

Thomas Koch tho...@koch.ro writes:

 I'm searching for best practices to track flexi time with orgmode. I've a 
 work 
 contract of 8 hours per day in average. So I'd like to start a clock when I 
 arrive at work, pause it for lunch and stop it when I leave.

 I wouldn't like to rely only on the sum of the time spent on tasks since 
 there 
 is always work time that can hardly be assigned to a specific task.

Nebulous tasks that can hardly be assigned should be avoided IMHO.
However, if you really find you have them and don't want to bother
expressing them in a precise fashion, what about a task for that, e.g. 
Project A Clean-up?

Your work day starts when the clock starts on a :WORK: task.
You want to have lunch? Clock in a Lunch or Break task, that does
not have a :WORK: tag.

I don't really see the need for a second clock so far?!

Memnon

Re: [O] New maintainer

[Julian M. Burgos]

I echo all the thanks that other people already gave.  My digital life
orbits around org-mode, so thanks to everyone who contributed to this
project.  Keep it up!!

Julian  

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnunin/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: jul...@hafro.is


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!

 :)

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

[Viktor Rosenfeld]

Hi Alan,

Alan Schmitt wrote:

  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?
 
 You need to ask for write access.

Will do.
 
 I started writing a tutorial, but I was caught up in too many things and
 could not finish it. If you want I can send you privately what I have
 written (or I can push it to worg and we can edit it together).

I'm fine with either way. But if you push to worg, please add a line at
the top that the koma exporter is a work in progress.

Cheers,
Viktor

 
 Best,
 
 Alan
 

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

[Viktor Rosenfeld]

Hi Alan,

Alan Schmitt wrote:

 A couple notes about the patch:
 - Could you create it using git format-patch? This way we'll have
 more metadata in the commit.

I actually did that first and liked it more because then the patch was
split into more logical blocks (nine patches in total). However, I did
not add correct changelog entries to the commits. Should I resend the
individual patches nevertheless? I could add/change the commit message
manually in the email, I suppose.

 - I think there is an issue with the handling of signatures. I tried
 with an old letter that uses a LCO with a graphical signature in it, but
 it gets overridden upon export. Here is the generated TeX.
 
 #+BEGIN_SRC latex
 \LoadLetterOption{InriaRennesFR}
 \setkomavar{signature}{\usekomavar{fromname}}
 #+END_SRC
 

Have you tried clearing the signature?

#+BEGIN_SRC emacs-lisp
(setq org-koma-letter-signature nil)
#+END_SRC

Cheers,
Viktor

 
 It seems to come from this part of the patch:
 
 #+BEGIN_SRC emacs-lisp
(signature (plist-get info :signature)))
  (concat
   ;; Letter Class Option File
   (when lco 
   (let ((lco-files (split-string lco  ))
 (lco-def ))
 (dolist (lco-file lco-files lco-def)
   (setq lco-def (format %s\\LoadLetterOption{%s}\n lco-def 
 lco-file)))
 lco-def))
   ;; Define From data.
   (when sender (format \\setkomavar{fromname}{%s}\n sender))
   (when from-address (format \\setkomavar{fromaddress}{%s}\n 
 from-address))
   (when phone-number (format \\setkomavar{fromphone}{%s}\n 
 phone-number))
   (when email (format \\setkomavar{fromemail}{%s}\n email))
   (when signature (format \\setkomavar{signature}{%s}\n signature
 #+END_SRC
 
 If signature is set for some reason (and it seems to be by default),
 then it will override what is in the LCO. I have not found a way to
 set the options such that the signature from the LCO gets picked up.
 
 Alan
 

Re: [O] Tracking flexitime

[Detlef Steuer]

Sorry for being inexact.

 Thank you Detlef for sharing this. However I can not follow.
 
 - C-c a runs the command org-agenda
 - a selects calendar for current week or day
 - i runs the command org-agenda-diary-entry
 - j ???
 
 - What is a datetime tree?

It is a date tree in org speak, sorry.
See section 9.1.3 Capture Templates in the Manual.

 
 - Do you have an extra file only to track you time at work? Could you share 
 (privately?) such a file?
 

Yes, but it contains, well, a date tree and nothing else.

 - I also could not find the binding for C-c y. What does it do?

C-u C-c C-y calculates the difference between time stamps.

See 8.2 in the manual. (entry on org-evaluate-time-range)

Regards
Detlef

 
 I guess you also use functionality of the calendar/diary package of emacs?
 
 Regards,
 
 Thomas Koch, http://www.koch.ro
 
 

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

[Viktor Rosenfeld]

Hi Rasmus,

Rasmus wrote:

  * 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
 
 In a similar spirit to subject is firsthead.  First head is displayed
 by default in scrlttr2 as far as I recall, which is annoying.

Is firsthead something that you change on a letter-by-letter basis? Or
do you configure it once for your letters and never change it? In the
latter case the configuration can be moved of to an LCO file. In the
former case an option would be nice. I had to actually change the
options I introduced so far for different letters (e.g., I don't want
foldmarks if I send the letter by email). 

 If we make foldmark an option should it not be a string accepting
 values from Table 4.3.: Combinable values for the configuration of
 folding marks with option foldmarks in the KOMA-Script manual?

Same as above. If I read the scrguide correctly, the foldmark variable
can be set multiple times, e.g.,

#+BEGIN_SRC latex
\KOMAoption{foldmarks}{blmtP}
\KOMAoption{foldmarks}{true}
#+END_SRC

The first line sets the behavior (and could be moved to an LCO file),
the second line can be used to switch foldmarks on or off (and could be
set by the exporter). Haven't tried this though.

 [...]
  +(defcustom org-koma-letter-opening Dear Madam or Sir,
 Letter's opening, as a string.
 :group 'org-export-koma-letter
 :type 'string)
 
 While I also mainly write English letters I don't think we need to
 assume everyone does.  I'd also opt for a default nil here.

Fair enough.

 [...]
  +(defcustom org-koma-letter-use-subject untitled
  +  Use the title as the letter's subject.
  +  :group 'org-export-koma-letter
  +  :type 'string)
 
 Perhaps the default should depend on whether a title is present?

The way I understand the org exporter, a title is always present. If not
explicitly set using #+TITLE it defaults to the file name or the org
heading.

 [...]
  +(defcustom org-koma-letter-use-place t
  +  Print the letter's place next to the date.
  +  :group 'org-export-koma-letter
  +  :type 'boolean)
  +
 
 Sorry for not testing this myself, but what is the behavior if
 e.g. org-koma-letter-use-place is t but I didn't specify a place?
 Will it print a nil or nothing?

It will print nil. Maybe this variable should also be configured to nil
then.
 
 
 '(?k Export with KOMA Scrlttr2
  -   ((?K As LaTeX buffer org-koma-letter-export-as-latex)
  -   (?k As LaTeX file org-koma-letter-export-to-latex)
  +   ((?L As LaTeX buffer org-koma-letter-export-as-latex)
  +   (?l As LaTeX file org-koma-letter-export-to-latex)
  (?p As PDF file org-koma-letter-export-to-pdf)
  -   (?O As PDF file and open
  +   (?o As PDF file and open
  (lambda (a s v b)
 
 Another approach (which I also somehow like) is to put it under the
 LaTeX menu.  E.g. like beamer or like org-ravel ¹  

I didn't know this was possible. I don't care either way, but I suppose
an advantage would be that some commands could be then consolidated to
save space.
 
  +   (let ((with-place (plist-get info :with-place))
  +(place (plist-get info :place)))
  + (when (or place (not with-place)) 
  +   (format \\setkomavar{place}{%s}\n (if with-place place 
 
 Wouldn't this work better: E.g. it wouldn't allow a place when place
 is nil or when with-place is nil?
 
 (when (and place (not with-place))
   (format \\setkomavar{place}{%s}\n place ))

This will print the place if it is configured somewhere, even if 
=place:nil= is set in #+OPTIONS. Note that I use the empty string  to
surpress the space in my code. For example, I have in my LCO file

#+BEGIN_SRC latex
\setkomavar{place}{Berlin}
#+END_SRC

That is, the space is usually printed in every letter. 

If I use #+OPTIONS: place:nil in a particular letter, the following code
is emitted:

#+BEGIN_SRC latex
\LoadLetterOption{myletter.lco} % place is set here
\setkomavar{place}{}% this surpresses the printing of place
#+END_SRC

  +   ;; KOMA options
  +   (let ((with-backaddress (plist-get info :with-backaddress))
  +(with-foldmarks (plist-get info :with-foldmarks))
  +(with-phone (plist-get info :with-phone))
  +(with-email (plist-get info :with-email)))
  + (concat
  +  (format \\KOMAoption{backaddress}{%s}\n (if with-backaddress 
  true false))
  +  (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks true 
  false))
  +  (format \\KOMAoption{fromphone}{%s}\n (if with-phone true 
  false))
  +  (format \\KOMAoption{fromemail}{%s}\n (if with-email true
  false
 
 Relating to configurable foldmarks:
 
 (if with-foldmarks
 (format \\KOMAoption{foldmarks}{%s}\n (if foldmarks
 foldmarks true)))
 
 (untested).

I would rather adapt the with-foldmarks option to accept a string rather than
adding another 

[O] open exported document without export

[Andreas Leha]

Hi all,

it would be great it there was (well, this is orgmode, so maybe there
is?) an option to use the exporter to open the result of a (previous)
export without doing the export again.

Such an option would spare me from searching the org-file for the file name
the exporter would use, and then switching to dired/shell to open the
document.

Especially useful, 
- if the export takes long (e.g. a beamer presentation) or 
- if I am not sure the export will go through or
- if I suspect the exported document to look different when exported
  again (my documents from half a year ago tend to not export smoothly
  with an up-to-date orgmode)

Regards,
Andreas

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

[Alan Schmitt]

Viktor Rosenfeld writes:

 Hi Alan,

 Alan Schmitt wrote:

 A couple notes about the patch:
 - Could you create it using git format-patch? This way we'll have
 more metadata in the commit.

 I actually did that first and liked it more because then the patch was
 split into more logical blocks (nine patches in total). However, I did
 not add correct changelog entries to the commits. Should I resend the
 individual patches nevertheless? I could add/change the commit message
 manually in the email, I suppose.

Or you could do a git rebase interactive to merge all the commits
together.

 - I think there is an issue with the handling of signatures. I tried
 with an old letter that uses a LCO with a graphical signature in it, but
 it gets overridden upon export. Here is the generated TeX.
 
 #+BEGIN_SRC latex
 \LoadLetterOption{InriaRennesFR}
 \setkomavar{signature}{\usekomavar{fromname}}
 #+END_SRC
 

 Have you tried clearing the signature?

 #+BEGIN_SRC emacs-lisp
 (setq org-koma-letter-signature nil)
 #+END_SRC

Yes, I changed it globally and I still get the same thing. I also
tried doing a

#+BEGIN_SRC org
#+signature: 
#+END_SRC

and it inserts it in the LaTeX file as such, after my LCO declaration.

Alan

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

[Rasmus]

Viktor,

 In a similar spirit to subject is firsthead.  First head is displayed
 by default in scrlttr2 as far as I recall, which is annoying.

 Is firsthead something that you change on a letter-by-letter basis? Or
 do you configure it once for your letters and never change it? In the
 latter case the configuration can be moved of to an LCO file. In the
 former case an option would be nice. I had to actually change the
 options I introduced so far for different letters (e.g., I don't want
 foldmarks if I send the letter by email). 

How I use scrlttr2: I rarely use firsthead as I find ugly.  I use
firstfoot all of the time and I change it regularly.  E.g. for some
letters I include bank addresse.  Still, I see your point.

 If we make foldmark an option should it not be a string accepting
 values from Table 4.3.: Combinable values for the configuration of
 folding marks with option foldmarks in the KOMA-Script manual?

 Same as above. If I read the scrguide correctly, the foldmark variable
 can be set multiple times, e.g.,
 #+BEGIN_SRC latex
 \KOMAoption{foldmarks}{blmtP}
 \KOMAoption{foldmarks}{true}
 #+END_SRC

This is true.

 The first line sets the behavior (and could be moved to an LCO file),
 the second line can be used to switch foldmarks on or off (and could be
 set by the exporter). Haven't tried this though.

Yeah, I guess it's true.  Still, since foldmarks depends on which
envelopes you have at hand it might make sense to have it accept a
string.  In lisp-terms a string is still t.  On the other hand the
current approach is consistent with your approach above so that's a
merit.


 [...]
  +(defcustom org-koma-letter-use-subject untitled
  +  Use the title as the letter's subject.
  +  :group 'org-export-koma-letter
  +  :type 'string)
 
 Perhaps the default should depend on whether a title is present?

 The way I understand the org exporter, a title is always present. If not
 explicitly set using #+TITLE it defaults to the file name or the org
 heading.

Could be.  It seems you are right.  In the 'main' LaTeX exporter a
\maketitle is inserted only if title is not nil:

#+begin_src emacs-lisp
;; snip from ox-latex.el, Org-mode version 8.0-pre (release_8.0-pre-523-g7248fb 
@ /usr/share/emacs/site-lisp/org/)
 (format \\title{%s}\n title)
;;   [...]
 (org-element-normalize-string
  (cond ((string=  title) nil)
((not (stringp org-latex-title-command)) nil)
((string-match \\(?:[^%]\\|^\\)%s
   org-latex-title-command)
 (format org-latex-title-command title))
(t org-latex-title-command)))
 ;; Table of contents.
#+end_src

 Another approach (which I also somehow like) is to put it under the
 LaTeX menu.  E.g. like beamer or like org-ravel ¹  

 I didn't know this was possible. I don't care either way, but I suppose
 an advantage would be that some commands could be then consolidated to
 save space.

I slightly prefer the org-ravel mode of adding it to LaTeX (l).
It make sense in the way that Beamer is also there.  I don't know if
there exists an official opinion on such practices.
  
  +   (let ((with-place (plist-get info :with-place))
  +   (place (plist-get info :place)))
  + (when (or place (not with-place)) 
  +   (format \\setkomavar{place}{%s}\n (if with-place place 
 
 Wouldn't this work better: E.g. it wouldn't allow a place when place
 is nil or when with-place is nil?
 
 (when (and place (not with-place))
   (format \\setkomavar{place}{%s}\n place ))

 This will print the place if it is configured somewhere, even if 
 =place:nil= is set in #+OPTIONS.

I see.  I wasn't thinking of the possibility you outline below as I
would configure the variable with my default location (which
unfortunately isn't Berlin).

 Note that I use the empty string  to
 surpress the space in my code. For example, I have in my LCO file
 #+BEGIN_SRC latex
 \setkomavar{place}{Berlin}
 #+END_SRC

 That is, the space is usually printed in every letter. 

 If I use #+OPTIONS: place:nil in a particular letter, the following code
 is emitted:
 #+BEGIN_SRC latex
 \LoadLetterOption{myletter.lco} % place is set here
 \setkomavar{place}{}% this surpresses the printing of place
 #+END_SRC



 I would rather adapt the with-foldmarks option to accept a string rather than
 adding another foldmarks variable.

Agree.  I think it shold.  It's almost free to add since a string is
true in both and Emacs lisp sense and a scrlttr2 sense (in this case).

Thanks!

–Rasmus


-- 
And let me remind you also that moderation in the pursuit of justice
is no virtue

Re: [O] Bug: Append new heading when :END: exists

[John Hendy]

On Apr 22, 2013 4:02 AM, Muchenxuan Tong demon...@gmail.com wrote:

 1. Assume that the content is:
 * Hello
   :LOGBOOK:
   - Note taken on [2013-04-22 Mon 16:57] \\
 hello
   :END:

 2. Fold it, so that it becomes
 * Hello…

 3. Put the cursor at the end of the heading, and press M-RET or C-RET
 * Hello…(here)

 The new * will be in the beginning of :END:, which is incorrect.


This may be related to my post:
- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg70302.html

John

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

[Viktor Rosenfeld]

Hi Bastian,

Bastien wrote:

 Hi Viktor,
 
 Viktor Rosenfeld listuse...@gmail.com writes:
 
  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.
 
 Can you test this patch against latest maint or master branch?

The problem still remains with the patch. However, I was able to narrow
the problem to a specific line and can provide a minimal example:

Consider the following configuration (which is loaded in init.el via
org-babel-load-file):

#+BEGIN_SRC emacs-lisp
(global-set-key (kbd f12) 'org-agenda)

(setq org-agenda-files '(
  ~/org/dokumente.org
  ~/org/openloops.org
  ~/org/routine.org
  ~/org/arbeit.org
 ))

(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

The four agenda files are as follows: The first file, dokumente.org
caontains a single headline and a #+TAGS: definition:

#+BEGIN_SRC org :tangle dokumente.org
#+TAGS: foo

* 1996
#+END_SRC

The other three files only contain a heading and no #+TAGS: definition:

#+BEGIN_SRC org :tangle openloops.org
* Inbox
#+END_SRC

#+BEGIN_SRC org :tangle routine.org
* Review
#+END_SRC

#+BEGIN_SRC org :tangle arbeit.org
* 1996
#+END_SRC

With this setup the tag hotkeys are repeated three times, one time for
each file with no tags definition. If I remove the #+TAGS definition in
dokumente.org, the bug disappears. If I add a #+TAGS definition to every
other file, then no tag hotkeys are printed, which is another unexpected
behavior. In other words, the presence of #+TAGS in a file causes the
tag hotkeys to repeated once for every file which does not have a #+TAGS
definition. To achieve the correct behavior, either no #+TAGS:
definition must appear anywhere or there must be exactly one file
without a #+TAGS definition.

Note that the number of repetions also depends on where the file with
the #+TAGS definition is located in the org-agenda-files list. Using the
four files above, if I move the file dokumente.org with the #+TAGS
definition to the end of the list then there are no repetitions.

Cheers,
Viktor

 
 Thanks,
 

[O] Using Eric Schulte's starter kit with org mode from source

[Alan Schmitt]

Hello,

I would like to try using Eric Schulte's starter kit, mainly to have my
configuration file in org-mode, using an org-mode installation from
source. An issue on github
(https://github.com/eschulte/emacs24-starter-kit/pull/29) suggests using
a command line argument to do so, but this is not convenient (especially
since I'm using emacs on OS X). Is there a way to pick up a source
install directly from the configuration files (for instance from
init.el)?

Thanks,

Alan

Re: [O] Using Eric Schulte's starter kit with org mode from source

[Eric Schulte]

Alan Schmitt alan.schm...@polytechnique.org writes:

 Hello,

 I would like to try using Eric Schulte's starter kit, mainly to have my
 configuration file in org-mode, using an org-mode installation from
 source. An issue on github
 (https://github.com/eschulte/emacs24-starter-kit/pull/29) suggests using
 a command line argument to do so, but this is not convenient (especially
 since I'm using emacs on OS X). Is there a way to pick up a source
 install directly from the configuration files (for instance from
 init.el)?

 Thanks,

 Alan


Adding a line to init.el will allow you to specify the Org-mode instill
to use.  Something like the following should work.

(add-hook 'after-init-hook
 `(lambda ()
;; remember this directory
(setq starter-kit-dir
  ,(file-name-directory (or load-file-name (buffer-file-name
;; load up the starter kit
(add-to-list 'load-path ~/path/to/org-mode/lisp/)
(require 'org)
(org-babel-load-file (expand-file-name starter-kit.org 
starter-kit-dir

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

Re: [O] Paths including spaces fail the installation: Patch

[Bernd Haug]

Hello Achim!

Finally got to it; pulled up to current (cf shell output below),
appended your snippet to local.mk and did a clean install:

On 14 March 2013 07:49, Achim Gratz strom...@nexgo.de wrote:
 BS-Quoting and Doublequote-ing were the first things I tried:
 […]

 Yes I see, that is due to inadvertent double quoting.  Try this
 definition in local.mk (not the extra two single quotes around
 $(datadir)):

 --8---cut here---start-8---
 # How to generate org-version.el
 MAKE_ORG_VERSION = $(BATCHL) \
   --eval '(load org-compat.el)' \
   --eval '(load ../mk/org-fixup.el)' \
   --eval '(org-make-org-version $(ORGVERSION) $(GITVERSION) 
 '$(datadir)')'
 --8---cut here---end---8---

 Please test, I'll push the fix if it solves your problem.



bernd.haug@sliver:~/Library/Application Support/Aquamacs
Emacs/org-mode$ git describe --always --long --dirty
release_8.0.1-14-g2e67699
bernd.haug@sliver:~/Library/Application Support/Aquamacs
Emacs/org-mode$ make clean install
rm -f
make -C lisp clean
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
org-install.elc
rm -f *.elc
make -C doc clean
rm -f org *.pdf *.html *_letter.tex org-version.inc \
  *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs \
  *.toc *.tp *.tps *.vr *.vrs *.log *.html *.ps
make -C doc install
org-version: 8.0.1 (release_8.0.1-14-g2e6769)
makeinfo --no-split org.texi -o org
if [ ! -d /Users/bernd.haug/Library/Application Support/Aquamacs
Emacs/org/info ]; then install -m 755 -d
/Users/bernd.haug/Library/Application Support/Aquamacs Emacs/org/info;
else true; fi ;
/bin/sh: line 0: [: too many arguments
install -m 644 -p org /Users/bernd.haug/Library/Application
Support/Aquamacs Emacs/org/info
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
   [-o owner] file1 file2
   install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
   [-o owner] file1 ... fileN directory
   install -d [-v] [-g group] [-m mode] [-o owner] directory ...
make[1]: *** [install] Error 64
make: *** [install-doc] Error 2
bernd.haug@sliver:~/Library/Application Support/Aquamacs Emacs/org-mode$



Problem seems to be, as before, that without proper quoting in the
right places *in the shell commands* paths with spaces fall apart into
separate arguments.

My (tiny and trivial) patch from back in Mar addressed only that and
the installation went off without a hitch with it.

Of course you're entirely right that the makefiles themselves do not
care, and the elisp doesn't have problems with it either.

Sorry for the delay and thank you for your consideration,
  Bernd

Re: [O] Using Eric Schulte's starter kit with org mode from source

[Alan Schmitt]

Eric Schulte writes:

 Adding a line to init.el will allow you to specify the Org-mode instill
 to use.  Something like the following should work.

 (add-hook 'after-init-hook
  `(lambda ()
 ;; remember this directory
 (setq starter-kit-dir
   ,(file-name-directory (or load-file-name (buffer-file-name
 ;; load up the starter kit
 (add-to-list 'load-path ~/path/to/org-mode/lisp/)
 (require 'org)
 (org-babel-load-file (expand-file-name starter-kit.org 
 starter-kit-dir

Thanks a lot, it works great!

Alan

Re: [O] converting people to Emacs and org-mode

[Eric S Fraga]

Torsten Wagner torsten.wag...@gmail.com writes:

 Hi,
 If I show org-mode to someone and if he/she points out the ugly graphic I
 stop at that point.

As I use a light text on dark background, I stop when they ask if there
is something wrong with my monitor because the background is
black...  sigh.

And I've not only given up trying to convert anybody to Emacs, I have
also given up trying to explain why a dark background with light text is
much better on the eyes.  Too much inertia and bad practices out there
unfortunately.

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0-pre-473-gf20de0

Re: [O] converting people to Emacs and org-mode

[Loyall, David]

I might have converted someone this weekend.

I had been babbling about Emacs, lisp, and the early 1980s to him for some 
time. 

I told him that Emacs was a 37 year old tree, that it had carefully tended for 
all that time by a community of folks that really cared about doing things the 
right way, and the result was that it already knows how to do just about all 
the small tasks that you can imagine asking it to do.

I started to demonstrate org sparse tree functionality[1], and he joked: Yeah, 
yeah, but can it tell me what time sunset will be today?

So I fired up the info browser and started searching and in less than sixty 
seconds, we'd invoked M-x sunrise-sunset .[2]

We didn't know our own longitude and latitude offhand, but it didn't matter: he 
was already impressed.  After I assured him that this was a built in function, 
and that I'd really never heard of it until just now, he said that he would 
look into Emacs.

:)

--Dave

[1] I should really make sure that I've memorized key bindings (well enough 
that enjoying a couple beers doesn't make me forget them) before trying this 
again.
[2] On my work PC, this says Cannot open load file: solar.  Thank goodness it 
happened to work on my home laptop!  (I won't fix this; no worries.)

Re: [O] Tracking flexitime

[Achim Gratz]

Thomas Koch writes:
 I wouldn't like to rely only on the sum of the time spent on tasks since 
 there 
 is always work time that can hardly be assigned to a specific task.

I have a heading that I clock stuff like all-hands meetings under that
shouldn't get booked to one of the projects I'm assigned to (which live
under their own headings).  That gives me the grand total for the time
sheet and also the sub-totals for each project at whatever granularity
the clocktable is set (I need weekly and two monthly reports at
different dates, so I have many clocktables by now, all stashed away in
drawers).  I'm only clocking full quarters of an hour.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

[O] Saving within a source code block... a bug?

[Julian M. Burgos]

Hello fellow org-moders:

I just switch to org-mode 8.0.1 and noticed a regression to a
missbehaviour (a bug?) that happened at some point in a previous version and
was later fixed.  This is the issue: I am working in an org-mode file
with R code blocks, and I do C-c' to edit one of them.  I do some
changes, and press C-s to save the changes.  At this point, I get a
request to choose a file to save the changes into (this should not
happen, the changes should just be saved into my org file).  Then I
choose a file name, press RET, and the filename is not created, but
instead the changes are saved into my org mode file.  Then, if I do more
changes and do C-s save again, now org-mode behaves the way it should: I
do not get asked for a filename and the changes are saved in my org mode
file.
Hopefully this is clear.  Let me know if you have questions.
Thanks!!

Julian

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnunin/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: jul...@hafro.is

Re: [O] Paths including spaces fail the installation: Patch

[Achim Gratz]

Bernd Haug writes:
 Finally got to it; pulled up to current (cf shell output below),
 appended your snippet to local.mk and did a clean install:

You don't need to add this anymore (unless you copied the old definition
from default.mk), it is already in mainline Org.  But you do need to
quote the definition for prefix (most likely).  Show the output of make
config.


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

Waldorf MIDI Implementation  additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] Bug: Append new heading when :END: exists

[Jeff Kowalczyk]

Sometime after 37f94d2 , a bug appeared which seems close to the thread 
subject:

When in the body of a heading, and pressing meta-enter, message prints: 'not 
in item'.

Reverting to 37f94d2 fixes.

Thanks,
Jeff

Re: [O] Saving within a source code block... a bug?

[John Hendy]

On Mon, Apr 22, 2013 at 10:39 AM, Julian M. Burgos jul...@hafro.is wrote:

 Hello fellow org-moders:

 I just switch to org-mode 8.0.1 and noticed a regression to a
 missbehaviour (a bug?) that happened at some point in a previous version and
 was later fixed.  This is the issue: I am working in an org-mode file
 with R code blocks, and I do C-c' to edit one of them.  I do some
 changes, and press C-s to save the changes.  At this point, I get a
 request to choose a file to save the changes into (this should not
 happen, the changes should just be saved into my org file).  Then I
 choose a file name, press RET, and the filename is not created, but
 instead the changes are saved into my org mode file.  Then, if I do more
 changes and do C-s save again, now org-mode behaves the way it should: I
 do not get asked for a filename and the changes are saved in my org mode
 file.

Do you have any special settings regarding key bindings? I've not used
this, but tried to reproduce with a simple example in a file I was
already working on. Here was my block:

#+begin_src R :session r :results output :exports results

  a - 1 + 2
  a

#+end_src

- Edit with =C-c '= (single quote, not backtick like I first tried as
I edit tables this way!)
- Code is highlighted in original buffer in yellow; new buffer opens
with contents
- Add line =b - 3 + 4=
- C-x C-s to save, minibuffer reports that it's saving/wrote my file
- The additional line above appears in file
- =C-c '= to close minibuffer

I can't reproduce. C-s, for me, is bound to isearch-forward.

Org-mode version 8.0 (release_8.0-2-g77476c)

Thought I'd see if this was release dependent, so I pulled and did
=make clean  make  make doc= just now and I get the same
[successful]  behavior.

Org-mode version 8.0.1 (release_8.0.1-14-g2e6769)


Best regards,
John


 Hopefully this is clear.  Let me know if you have questions.
 Thanks!!

 Julian

 --
 Julian Mariano Burgos, PhD
 Hafrannsóknastofnunin/Marine Research Institute
 Skúlagata 4, 121 Reykjavík, Iceland
 Sími/Telephone : +354-5752037
 Bréfsími/Telefax:  +354-5752001
 Netfang/Email: jul...@hafro.is

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

[Jay Kerns]

Christoph,

On Sun, Apr 21, 2013 at 4:00 PM, Christoph LANGE lan...@web.de wrote:
 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


Thank you for this work!  It's very helpful.  May it have a speedy
Portage review.

Best wishes,

-- 
Jay

Re: [O] New maintainer

[Jay Kerns]

On Mon, Apr 22, 2013 at 6:27 AM, Julian M. Burgos jul...@hafro.is wrote:
 I echo all the thanks that other people already gave.  My digital life
 orbits around org-mode, so thanks to everyone who contributed to this
 project.  Keep it up!!

 Julian


I have been watching these multiple messages go by trying to find a
space to get a word in edgewise, but instead of waiting longer let me
just say now:  I am sorry to see you step down, Bastien, but also, I
am happy about your bright future ahead.  Congratulations! on a job
very well done!

Regards,

-- 
Jay

Re: [O] New maintainer

[Matt Price]

Just echoing what everyone else has said:  Bastien, your tenure at the
helm has just been fabulous.  8.0 is just an amazing release and org
already just amazingly great has become even better.  Carsten, it's so
generous for you to come back to this project to which you have
already devoted so much energy.  No other tool I use has had such a
great pair of lead developers or such an open and helpful community.
thank you both!

Matt

Re: [O] Release 8.0

[Jay Kerns]

On Sun, Apr 21, 2013 at 9:25 AM, Bastien b...@gnu.org wrote:
 Hi Memnon,

 Memnon Anon gegendosenflei...@googlemail.com writes:

[ snip ]

Quick question: is it true, now that Org 8.0 has been released, that
the engine which publishes Worg is now Org 8.0, too?  In other words,
is it now safe to publish to Worg all of that stuff which was written
compatible with the new exporter, without breaking Worg in the
process?

Cheers,

-- 
Jay

[O] Bug [minor]: ~~/blah~ displayed incorrectly [8.0 (8.0-dist @ /usr/local/share/emacs/site-lisp/org/)]

[Aidan Gauland]

I have a path in a list item like

  2. Open ~~/path/to/somewhere~

which is exported as expected (via C-c C-e t U):

  2. Open `~/path/to/somewhere'

So, to the exporter, the tilde in the path isn't closing the opening
verbatim snippet, but it is for org-mode's syntax-highlighting.

Emacs  : GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2013-04-03 on dimension8, modified by Debian
Package: Org-mode version 8.0 (8.0-dist @ /usr/local/share/emacs/site-lisp/org/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-todo-keyword-faces '((READY :foreground blue :weight bold) (FINISHED 
:foreground blue :weight bold))
 org-agenda-include-diary t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-tags-column -40
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((lambda nil (define-key org-mode-map (kbd C-c a) (quote 
org-agenda))) undo-tree-mode
 #[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook org-show-block-all 
append local] 5]
 #[nil \300\301\302\303\304$\207
   [org-add-hook change-major-mode-hook 
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-outline-path-complete-in-steps nil
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point 
org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
org-cycle-hide-inline-tasks
  org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-completion-use-ido t
 org-completion-use-iswitchb t
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

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

[John Hendy]

On Mon, Apr 22, 2013 at 11:48 AM, Jay Kerns gjkerns...@gmail.com wrote:
 Christoph,

 On Sun, Apr 21, 2013 at 4:00 PM, Christoph LANGE lan...@web.de wrote:
 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


 Thank you for this work!  It's very helpful.  May it have a speedy
 Portage review.

As an Arch Linux user who absolutely loves the AUR and have an
appreciation for the massive number of packages available for both
Arch and Gentoo, I caution this sort of thing if not properly
maintained. As a parallel anecdote, I switched from the AUR build of
TexLive for the fact that enough locations and stale files get left
around that upgrading was giving errors and path variables weren't
pointing in the right location. Manually maintaining TexLive has
proved unbelievably easier, primarily due to being able to specify
everything in a local directory in ~/ vs. spread throughout /usr/lib,
/etc, /var, etc.

While Org isn't anywhere close to as messy as a LaTeX installation,
maintaining it properly if one is planning to spread the files around
should not be overlooked. While AUR also has an Org-mode package, I'd
*much* rather just stick to a directory at ~/.elisp/org.git where I
pull, make clean, make, and then simply add those dirs a the top of
the load-path.

Just food for thought. Again, Org might not be difficult to maintain
at all, but I've been burned in the past by some of these. Just
couldn't help making a response!



Best regards,
John


 Best wishes,

 --
 Jay

Re: [O] converting people to Emacs and org-mode

[Bastien]

Eric S Fraga e.fr...@ucl.ac.uk writes:

 And I've not only given up trying to convert anybody to Emacs, I have
 also given up trying to explain why a dark background with light text is
 much better on the eyes.  Too much inertia and bad practices out there
 unfortunately.

On this slightly off-topic subject, an oculist told me the dark
background did not really matter, what matters is the contrast.
Very high and very low are not good, something inbetween (but
he could point to a way to quantify this.)

I use xcalib (http://xcalib.sourceforge.net/) to quickly switch
from light-on-dark (most often) to dark-on-light (from time to
time) and I recommend it.

-- 
 Bastien

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

[Bastien]

Hi Viktor,

Rasmus ras...@gmx.us writes:

 Ask Bastien or perhaps Carsten now for write access (you need to
 provide your public key).  I can look through it when uploaded.

Please send me your public key (in private) and I'll add you to Worg.

Best,

-- 
 Bastien

Re: [O] Release 8.0

[Bastien]

Hi Jay,

Jay Kerns gjkerns...@gmail.com writes:

 On Sun, Apr 21, 2013 at 9:25 AM, Bastien b...@gnu.org wrote:
 Hi Memnon,

 Memnon Anon gegendosenflei...@googlemail.com writes:

 [ snip ]

 Quick question: is it true, now that Org 8.0 has been released, that
 the engine which publishes Worg is now Org 8.0, too?

No, not yet.

 In other words, is it now safe to publish to Worg all of that stuff
 which was written compatible with the new exporter, without breaking
 Worg in the process?

No.  Someone needs to carefully check he can exports his local clone
of worg.git with the new exporter, fix the wrong syntax, then commit
it.  This surely deserves a public branch of Worg, which people can
hack together.

-- 
 Bastien

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

[Achim Gratz]

Christoph LANGE writes:
 Gentoo users may find my ebuild for app-emacs/org-mode-8.0.1 useful.

ELISP_REMOVE=lisp/org-install.el

You'll also want to remove org-loaddefs.el and org-version.el.

   elisp-install ${PN}/contrib contrib/lisp/*org*.el || die

This is wrong if you use ORG_ADD_CONTRIB.  These files are already taken
care of by make install and contrib should not be added to the
load-path (it also shouldn't exist as a subdirectory under ${PN}).


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

[O] Bug: Priority-Down Sort Method Prevents Further Sorting in Daily Agenda

[Nick Daly]

First, Bastien (and everybody), thanks for all the work done on the
8.0 release.  It's wonderful, aside from the occasional bug :)

Second, that occasional bug: Priority-down (and presumably,
priority-up) in the org-agenda-sorting-strategy prevent further
sorting from occurring in the weekly/daily agenda.

For example, when sorting with the following strategies for the
weekly/daily agenda, the agenda's order is a bit screwy:

- habit-down
- time-up
- priority-down
- deadline-down
- scheduled-down
- category-keep

Unfortunately, as shown below, the default sort methods apply:
deadlines occur after the scheduled events, and we're using the
deadline-/scheduled-up sorting method instead of the correct -down
methods:

todo:Sched. 6x:  TODO [#A] Reply to Can't Find Directory Issue
todo:Scheduled:  TODO [#A] Run Search and Fix Utility
todo:Scheduled:  WAIT [#A] Find Entity Relationship Diagrams
todo: 5 d. ago:  TODO [#A] Run Search and Fix Utility
todo:In   2 d.:  WAIT [#A] Find Entity Relationship Diagrams
todo:Sched.42x:  WAIT Unavailable Note List
mail:Sched.21x:  TODO FW: ICE DIAG
calendar:Sched. 4x:  Weekly Team Meeting
todo:Scheduled:  TODO Design Draft


The desired and correct order of the above events, based on selected
sort methods, is:

todo:In   2 d.:  WAIT [#A] Find Entity Relationship Diagrams
todo: 5 d. ago:  TODO [#A] Run Search and Fix Utility
todo:Scheduled:  TODO [#A] Run Search and Fix Utility
todo:Scheduled:  WAIT [#A] Find Entity Relationship Diagrams
todo:Sched. 6x:  TODO [#A] Reply to Can't Find Directory Issue
todo:Scheduled:  TODO Design Draft
calendar:Sched. 4x:  Weekly Team Meeting
mail:Sched.21x:  TODO FW: ICE DIAG
todo:Sched.42x:  WAIT Unavailable Note List

Thanks for your time,
Nick

[O] Worg not publishing

[Achim Gratz]

Worg stopped publishing... it dies on some invalid timestamp:

remote: Generating tree-style sitemap for Sitemap for project worg-pages
remote: Generating tree-style sitemap for Sitemap for project worg-pages
remote: Generating tree-style sitemap for Sitemap for project worg-pages
remote: Invalid time specification
remote: worg publish process 22305 exited at 04/22/13@01:08:26
To git+ssh://w...@orgmode.org/~/worg.git



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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Worg not publishing

[Bastien]

Hi Achim,

Achim Gratz strom...@nexgo.de writes:

 Worg stopped publishing... it dies on some invalid timestamp:

 remote: Generating tree-style sitemap for Sitemap for project worg-pages  
   
 remote: Generating tree-style sitemap for Sitemap for project worg-pages  
   
 remote: Generating tree-style sitemap for Sitemap for project worg-pages  
   
 remote: Invalid time specification
 remote: worg publish process 22305 exited at 04/22/13@01:08:26
 To git+ssh://w...@orgmode.org/~/worg.git

Should be fixed now, thanks.

-- 
 Bastien

Re: [O] Release 8.0

[Carsten Dominik]

On 22.4.2013, at 19:17, Bastien b...@gnu.org wrote:

 Hi Jay,
 
 Jay Kerns gjkerns...@gmail.com writes:
 
 On Sun, Apr 21, 2013 at 9:25 AM, Bastien b...@gnu.org wrote:
 Hi Memnon,
 
 Memnon Anon gegendosenflei...@googlemail.com writes:
 
 [ snip ]
 
 Quick question: is it true, now that Org 8.0 has been released, that
 the engine which publishes Worg is now Org 8.0, too?
 
 No, not yet.
 
 In other words, is it now safe to publish to Worg all of that stuff
 which was written compatible with the new exporter, without breaking
 Worg in the process?
 
 No.  Someone needs to carefully check he can exports his local clone
 of worg.git with the new exporter, fix the wrong syntax, then commit
 it.  This surely deserves a public branch of Worg, which people can
 hack together.


Thanks Bastien, I was about to write about this.

We need a volunteer who is willing to coordinate the conversion
of Worg to the new exporter.  This is an important task.  Dogfooding
Worg to the new exporter will be a good way to find remaining bugs
in the parser/exporter setup.

This task would entail:

1. Creating a public branch of Worg for this work.
2. Creating and maintaining a file that contains a site map of Worg,
   with all files that need publishing
3. Organizing contributors who will look at one page after the other
   and implementing any changes needed to make the page export (not yet
   publish) cleanly with the new exporter.  In this way we need to walk
   through all Worg files, and someone needs to keep the tabs on this.
4. When all this is done, see what changes have to be made to the
   publishing setup to fix the automatic publishing.

Any takers?

Once we are done with this, we also need the orgmode.org website, but
that contains fewer pages, so it should be a lot simpler.

- Carsten  

Re: [O] Bug: Append new heading when :END: exists

[Carsten Dominik]

Hi Jeff,

thanks for the report - this should be fixed now.

- Carsten

On 22.4.2013, at 17:40, Jeff Kowalczyk j...@yahoo.com wrote:

 Sometime after 37f94d2 , a bug appeared which seems close to the thread 
 subject:
 
 When in the body of a heading, and pressing meta-enter, message prints: 'not 
 in item'.
 
 Reverting to 37f94d2 fixes.
 
 Thanks,
 Jeff
 
 

Re: [O] Worg not publishing

[Achim Gratz]

Bastien writes:
 Should be fixed now, thanks.

Thanks.  Now the Makefile examples are nicely fontified… Is there an
easy way to have the names of the source blocks added to the export as a
caption or header?


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

Waldorf MIDI Implementation  additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] Worg not publishing

[Bastien]

Achim Gratz strom...@nexgo.de writes:

 Bastien writes:
 Should be fixed now, thanks.

 Thanks.  Now the Makefile examples are nicely fontified… Is there an
 easy way to have the names of the source blocks added to the export as a
 caption or header?

Mhh.. I don't think so.

If this is not possible, maybe we can add some #+CAPTION
lines in the meantime?

-- 
 Bastien

Re: [O] Bug: Append new heading when :END: exists

[Bastien]

I'm tempted to apply the following patch, as this problem falls under
the category of inserting in an invisible region.  I don't think it
breaks any non-interactive call of org-insert-heading, but this needs
further checking.

Also, note that the problem occurs only when there is no blank line
between the :END: and the following headline, so maybe the real fix
has to be within org-insert-heading...

diff --git a/lisp/org.el b/lisp/org.el
index 8c55bd4..4d16682 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7495,6 +7495,7 @@ and create a new headline with the text in the current line after point
 When INVISIBLE-OK is set, stop at invisible headlines when going back.
 This is important for non-interactive uses of the command.
   (interactive P)
+  (org-check-before-invisible-edit 'insert)
   (cond
((or (= (buffer-size) 0)
 	(and (not (save-excursion

-- 
 Bastien

Re: [O] Worg not publishing

[Achim Gratz]

Bastien writes:
 If this is not possible, maybe we can add some #+CAPTION
 lines in the meantime?

I've replaced #+NAME by #+CAPTION, but nothing changes (not
unexpectedly).  I'll leave it at that for the moment.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

[Viktor Rosenfeld]

Hi Alan,

Alan Schmitt wrote:

 Or you could do a git rebase interactive to merge all the commits
 together.

Wow, this is great! I didn't know that you can modify the commit history
so easily. I have attached four patches to this mail which correspond to
the four points in my earlier email. They have to be applied
consecutively.

  - I think there is an issue with the handling of signatures. I tried
  with an old letter that uses a LCO with a graphical signature in it, but
  it gets overridden upon export. Here is the generated TeX.
  
  #+BEGIN_SRC latex
  \LoadLetterOption{InriaRennesFR}
  \setkomavar{signature}{\usekomavar{fromname}}
  #+END_SRC
  
 
  Have you tried clearing the signature?
 
  #+BEGIN_SRC emacs-lisp
  (setq org-koma-letter-signature nil)
  #+END_SRC
 
 Yes, I changed it globally and I still get the same thing. I also
 tried doing a
 
 #+BEGIN_SRC org
 #+signature: 
 #+END_SRC
 
 and it inserts it in the LaTeX file as such, after my LCO declaration.

I can't reproduce this. I have attached a minimal letter as an example.
If I evaluate the emacs-lisp block and export it I can see a graphic
signature that is defined in `Signed.lco' in my `texmf' directory. What
happens on your end?

Cheers,
Viktor

 
 Alan
 
From 02727b4259b2530d7e878aeaed6b2d235d271f2a Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld hesk@cartman
Date: Sun, 21 Apr 2013 13:40:09 +0200
Subject: [PATCH 1/4] ox-koma-letter: Use same hotkeys as LaTeX export

  * ox-koma-letter.el (koma-letter): Use `L' to export to LaTeX
  buffer, `l' to export to LaTeX file, and `o' to export to PDF
  file and open.

Patch suggested by Rasmus.
---
 contrib/lisp/ox-koma-letter.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1ffb455..d8d32e7 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -123,10 +123,10 @@
 (template . org-koma-letter-template))
   :menu-entry
   '(?k Export with KOMA Scrlttr2
-   ((?K As LaTeX buffer org-koma-letter-export-as-latex)
-   (?k As LaTeX file org-koma-letter-export-to-latex)
+   ((?L As LaTeX buffer org-koma-letter-export-as-latex)
+   (?l As LaTeX file org-koma-letter-export-to-latex)
(?p As PDF file org-koma-letter-export-to-pdf)
-   (?O As PDF file and open
+   (?o As PDF file and open
(lambda (a s v b)
  (if a (org-koma-letter-export-to-pdf t s v b)
(org-open-file (org-koma-letter-export-to-pdf nil s v b
-- 
1.8.2

From 1513beb2ba4aa847eaeb3f5e9c86414e7f8d5cd3 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld hesk@cartman
Date: Sun, 21 Apr 2013 13:41:22 +0200
Subject: [PATCH 2/4] ox-koma-letter.el: Set LCO option before other KOMA
 variables

  * ox-koma-letter.el (org-koma-letter-closing): More
  business-like closing.
  (org-koma-letter-from-address): Do not set default personal
  information.
  (org-koma-letter-opening): Gendered opening.
  (org-koma-letter-phone-number): Do not set default personal
  information.
  (org-koma-letter-sender): Use `#+SENDER:' instead of
  `#+AUTHOR:' because the latter is always set by the LaTeX
  exporter.
  (org-koma-letter-email): Duplicte `#+EMAIL:' in this exporter
  because it is always set by the LaTeX exporter.
  (koma-letter): Add additional `#+SENDER:' and `#+EMAIL:' to
  exporter (see above).
  (org-koma-letter-template): Set LCO before evaluating other
  KOMA variables if they are set; add `#+SENDER:' and `#+EMAIL:'
  to template (see above).

The LCO file is set loaded first and KOMA variables are only set if
their value is not `nil'.

Example:

  #+LCO: Default
  #+SIGNATURE: A friend

will result in the following LaTeX code:

  #+BEGIN_SRC latex
  \LoadLetterOption{Default}% LCO file, with default signature
  \setkomavar{signature}{A friend}  % Overwrite signature
  #+END_SRC

Other KOMA variables defined in the LCO file, e.g., `fromaddress', will
not be overwritten.
---
 contrib/lisp/ox-koma-letter.el | 55 +++---
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index d8d32e7..5397cf0 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,22 +80,22 @@
   :group 'org-export-koma-letter
   :type 'string)
 
-(defcustom org-koma-letter-closing See you soon,
+(defcustom org-koma-letter-closing Sincerely yours,
   Koma-Letter's closing, 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-opening Dear Madam or Sir,
   Letter's opening, as a string.
   :group 'org-export-koma-letter
   :type 

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

[Viktor Rosenfeld]

Hi Rasmus,

Rasmus wrote:

  In a similar spirit to subject is firsthead.  First head is displayed
  by default in scrlttr2 as far as I recall, which is annoying.
 
  Is firsthead something that you change on a letter-by-letter basis? Or
  do you configure it once for your letters and never change it? In the
  latter case the configuration can be moved of to an LCO file. In the
  former case an option would be nice. I had to actually change the
  options I introduced so far for different letters (e.g., I don't want
  foldmarks if I send the letter by email). 
 
 How I use scrlttr2: I rarely use firsthead as I find ugly.  I use
 firstfoot all of the time and I change it regularly.  E.g. for some
 letters I include bank addresse.  Still, I see your point.

So firsthead would be a boolean export option whereas firstfood would be
a variable to set its content? I can see the use.
 
  If we make foldmark an option should it not be a string accepting
  values from Table 4.3.: Combinable values for the configuration of
  folding marks with option foldmarks in the KOMA-Script manual?
 
  Same as above. If I read the scrguide correctly, the foldmark variable
  can be set multiple times, e.g.,
  #+BEGIN_SRC latex
  \KOMAoption{foldmarks}{blmtP}
  \KOMAoption{foldmarks}{true}
  #+END_SRC
 
 This is true.
 
  The first line sets the behavior (and could be moved to an LCO file),
  the second line can be used to switch foldmarks on or off (and could be
  set by the exporter). Haven't tried this though.
 
 Yeah, I guess it's true.  Still, since foldmarks depends on which
 envelopes you have at hand it might make sense to have it accept a
 string.  In lisp-terms a string is still t.  On the other hand the
 current approach is consistent with your approach above so that's a
 merit.

The more I think about it the more I agree that you should be able to
set any value of foldmarks. The only problem I see is that for other
boolean options one can use `t' whereas for foldmarks one would need to
use `true' (because `t' is a valid configuration value for foldmarks).
But as long as that's documented I see no problem. I will post a patch,
once Alan applies my previous patches.

Cheers,
Viktor

[O] Can't export LaTeX source code blocks

[Sebastien Vauban]

Hello,

As shown by the following ECM, I can't export the LaTeX code blocks.

--8---cut here---start-8---
#+TITLE: ECM exports LaTeX code
#+Time-stamp: 2013-04-22 Mon 21:31
#+LANGUAGE:  en

#+PROPERTY: exports both

* Context

My goal is to explain different LaTeX blocks which I use to construct a LaTeX
class. The document should be exportable to both LaTeX and HTML.

* TODO Documentation

Here is the LaTeX code:

#+name: doc-macro-a
#+begin_src latex
\DescribeMacro{\dummyMacro}
This macro does nothing.\index{doing nothing|usage} It is merely an
example.  If this were a real macro, you would put a paragraph here
describing \textbf{what} the macro is supposed to do, what its mandatory and
optional arguments are, and so forth.
#+end_src

followed by the LaTeX output:

#+results: doc-macro-a
#+BEGIN_LaTeX
\DescribeMacro{\dummyMacro}
This macro does nothing.\index{doing nothing|usage} It is merely an
example.  If this were a real macro, you would put a paragraph here
describing \textbf{what} the macro is supposed to do, what its mandatory and
optional arguments are, and so forth.
#+END_LaTeX

* Results

As you can see, the code block is NEVER exported. I don't understand why?

The results block is exported, but then (interpreted and) only visible in the
LaTeX back-end. The HTML document is completely empty...
--8---cut here---end---8---

Am I besides my shoes ;-) ?

Best regards,
  Seb

--
Sebastien Vauban

Re: [O] converting people to Emacs and org-mode

[Sebastien Vauban]

Bastien wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 And I've not only given up trying to convert anybody to Emacs, I have
 also given up trying to explain why a dark background with light text is
 much better on the eyes.  Too much inertia and bad practices out there
 unfortunately.

 On this slightly off-topic subject, an oculist told me the dark
 background did not really matter, what matters is the contrast.
 Very high and very low are not good, something inbetween (but
 he could point to a way to quantify this.)

 I use xcalib (http://xcalib.sourceforge.net/) to quickly switch
 from light-on-dark (most often) to dark-on-light (from time to
 time) and I recommend it.

What I once heard from ergonomical studies is that black on white was better
than white on black. Though, is it based on real grounds?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Worg not publishing

[Sebastien Vauban]

Hello Bastien, Achim,

Bastien wrote:
 Achim Gratz strom...@nexgo.de writes:
 Bastien writes:
 Should be fixed now, thanks.

 Thanks.  Now the Makefile examples are nicely fontified… Is there an
 easy way to have the names of the source blocks added to the export as a
 caption or header?

 Mhh.. I don't think so.

In theory, it is absolutely possible, via the following var:

  ╭
  │ org-babel-exp-code-template is a variable defined in `ob-exp.el'.
  │ Its value is #+BEGIN_SRC %lang%flags
  │ %body
  │ #+END_SRC
  │ 
  │ Documentation:
  │ Template used to export the body of code blocks.
  │ This template may be customized to include additional information
  │ such as the code block name, or the values of particular header
  │ arguments.  The template is filled out using `org-fill-template',
  │ and the following %keys may be used.
  │ 
  │  lang -- the language of the code block
  │  name -- the name of the code block
  │  body -- the body of the code block
  │  flags - the flags passed to the code block
  │ 
  │ In addition to the keys mentioned above, every header argument
  │ defined for the code block may be used as a key and will be
  │ replaced with its value.
  ╰

However, I've never had nice enough results to make use of it. The problem is
that I would like to output the name in a certain face for both HTML and
LaTeX, and that's not currently possible: here, the name is simply outputted
as plain text, in all back-ends.

Maybe we would need a customizable skeleton per back-end?  So that one could
add DIV for HTML, etc.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Release 8.0

[John Hendy]

On Mon, Apr 22, 2013 at 1:32 PM, Carsten Dominik
carsten.domi...@gmail.com wrote:

 On 22.4.2013, at 19:17, Bastien b...@gnu.org wrote:

 Hi Jay,

 Jay Kerns gjkerns...@gmail.com writes:

 On Sun, Apr 21, 2013 at 9:25 AM, Bastien b...@gnu.org wrote:
 Hi Memnon,

 Memnon Anon gegendosenflei...@googlemail.com writes:

 [ snip ]

 Quick question: is it true, now that Org 8.0 has been released, that
 the engine which publishes Worg is now Org 8.0, too?

 No, not yet.

 In other words, is it now safe to publish to Worg all of that stuff
 which was written compatible with the new exporter, without breaking
 Worg in the process?

 No.  Someone needs to carefully check he can exports his local clone
 of worg.git with the new exporter, fix the wrong syntax, then commit
 it.  This surely deserves a public branch of Worg, which people can
 hack together.


 Thanks Bastien, I was about to write about this.

 We need a volunteer who is willing to coordinate the conversion
 of Worg to the new exporter.  This is an important task.  Dogfooding
 Worg to the new exporter will be a good way to find remaining bugs
 in the parser/exporter setup.

 This task would entail:

 1. Creating a public branch of Worg for this work.

Can I just update my clone and push to github? If so, sure. I'd just
use my own github account (unpaid). If there's a better location,
suggest it or someone else can volunteer to host/create the clone if
they have better tools/access for this.

 2. Creating and maintaining a file that contains a site map of Worg,
with all files that need publishing

I could take a stab at this, but it won't be instantaneous. If someone
has the time and energy to do this in the short term ( 1 week),
they'd be better. If a week or so is acceptable, I can take this one
as well, at least the creation part. I'm assuming it will be a big
todo list? From there, it would be much easier if editors updated it
themselves.

 3. Organizing contributors who will look at one page after the other
and implementing any changes needed to make the page export (not yet
publish) cleanly with the new exporter.  In this way we need to walk
through all Worg files, and someone needs to keep the tabs on this.

Not sure we totally need to organize this. I'm wondering about
something like an editor property in the file from #2. Contributors
could self-assign by adding their name to that property in the tracker
file and then push. Perhaps an agenda view or simply column view could
quickly show who is assigned to what file?

 4. When all this is done, see what changes have to be made to the
publishing setup to fix the automatic publishing.

I'd be really bad at this as I've never actually set up publishing. I
can definitely help with some of the #+attr_backend and general syntax
stuff, but I never got heavy into the site publishing features and
have never even looked at Worg's setup for this.

If this is the process... how does the public Worg get updated in the
mean time? I'm pretty new to git and only do basic stuff. Diffs have
always been intimidating (and I've found them to really stink even for
really, really small changes I've had). How will we maintain the
public site and then re-combine with the public one down the road?
Editing on the public one needs to happen in old syntax; public repo
for upgrade hacking needs to be in the new syntax.

Should we freeze Worg for the time being and direct editing to happen
at the other one?


Best regards,
John


 Any takers?

 Once we are done with this, we also need the orgmode.org website, but
 that contains fewer pages, so it should be a lot simpler.

 - Carsten

[O] bug: /italic/ sometimes fails

[Bill White]

 - Org-mode version 8.0.1 (release_8.0.1-15-g0fff0b @ 
/home/billw/Dropbox/org/org-mode/lisp/)
 - GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2013-03-11 on wri

Italicization fails when a doublequote character is adjacent to a slash.

This behavior is visible in an org-mode buffer, and is seen when
exporting the buffer to an HTML file.

These are italicized as expected:

/test/

/a test/

/a test a/

But these are not italicized:

/a test/

/a test/

/test/

/test/

/test/

Cheers -

bw
-- 
Bill White . bi...@wolfram.com
No ma'am, we're musicians.

Re: [O] Bug: Append new heading when :END: exists

[John Hendy]

On Mon, Apr 22, 2013 at 1:48 PM, Carsten Dominik
carsten.domi...@gmail.com wrote:
 Hi Jeff,

 thanks for the report - this should be fixed now.

For general headlines, this is fixed for me. I'm getting bad results
if there's a source code block in the headline, though. See attached
pics (in chronological order) showing what happens with a setup like
this:

* Heading

#+begin_src R

  a - 1 + 2
  a
#+end_src

* Heading2

If I fold * Heading, =C-e= to the end of the line, and then M-RET, it
puts the asterisk at the end of the heading instead of creating a new
one. When I unfold, there's three dots after =#+end_src= and there's
the asterisk.

Also, I just tried this, and if there's no space or empty lines after
Test, when I fold * Heading, the t appears after the folded
heading ...

* Heading

#+begin_src R

  a - 1 + 2
  a
#+end_src

Test

The last two screenshots are of that case.

I'm on Org-mode version 8.0.1 (release_8.0.1-15-g0fff0b).


John


 - Carsten

 On 22.4.2013, at 17:40, Jeff Kowalczyk j...@yahoo.com wrote:

 Sometime after 37f94d2 , a bug appeared which seems close to the thread
 subject:

 When in the body of a heading, and pressing meta-enter, message prints: 'not
 in item'.

 Reverting to 37f94d2 fixes.

 Thanks,
 Jeff




attachment: 2013-04-22_145509.pngattachment: 2013-04-22_145524.pngattachment: 2013-04-22_145532.pngattachment: 2013-04-22_145541.pngattachment: 2013-04-22_150039.pngattachment: 2013-04-22_150045.png

Re: [O] converting people to Emacs and org-mode

[John Hendy]

On Mon, Apr 22, 2013 at 2:35 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
 Bastien wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 And I've not only given up trying to convert anybody to Emacs, I have
 also given up trying to explain why a dark background with light text is
 much better on the eyes.  Too much inertia and bad practices out there
 unfortunately.

 On this slightly off-topic subject, an oculist told me the dark
 background did not really matter, what matters is the contrast.
 Very high and very low are not good, something inbetween (but
 he could point to a way to quantify this.)

 I use xcalib (http://xcalib.sourceforge.net/) to quickly switch
 from light-on-dark (most often) to dark-on-light (from time to
 time) and I recommend it.

 What I once heard from ergonomical studies is that black on white was better
 than white on black. Though, is it based on real grounds?


Others want to know, too. If you find the answer... you'll get a lot of votes :)
- 
http://skeptics.stackexchange.com/questions/6925/are-light-on-dark-colour-schemes-for-computer-screens-better-for-programmers


John


 Best regards,
   Seb

 --
 Sebastien Vauban

Re: [O] Release 8.0

[Carsten Dominik]

On 22.4.2013, at 21:46, John Hendy jw.he...@gmail.com wrote:

 On Mon, Apr 22, 2013 at 1:32 PM, Carsten Dominik
 carsten.domi...@gmail.com wrote:
 
 On 22.4.2013, at 19:17, Bastien b...@gnu.org wrote:
 
 Hi Jay,
 
 Jay Kerns gjkerns...@gmail.com writes:
 
 On Sun, Apr 21, 2013 at 9:25 AM, Bastien b...@gnu.org wrote:
 Hi Memnon,
 
 Memnon Anon gegendosenflei...@googlemail.com writes:
 
 [ snip ]
 
 Quick question: is it true, now that Org 8.0 has been released, that
 the engine which publishes Worg is now Org 8.0, too?
 
 No, not yet.
 
 In other words, is it now safe to publish to Worg all of that stuff
 which was written compatible with the new exporter, without breaking
 Worg in the process?
 
 No.  Someone needs to carefully check he can exports his local clone
 of worg.git with the new exporter, fix the wrong syntax, then commit
 it.  This surely deserves a public branch of Worg, which people can
 hack together.
 
 
 Thanks Bastien, I was about to write about this.
 
 We need a volunteer who is willing to coordinate the conversion
 of Worg to the new exporter.  This is an important task.  Dogfooding
 Worg to the new exporter will be a good way to find remaining bugs
 in the parser/exporter setup.
 
 This task would entail:
 
 1. Creating a public branch of Worg for this work.
 
 Can I just update my clone and push to github? If so, sure. I'd just
 use my own github account (unpaid). If there's a better location,
 suggest it or someone else can volunteer to host/create the clone if
 they have better tools/access for this.


Do you have commit access at the worg repository at orgmode.org?
Then it would be easiest to set it up there.  I could do it, but maybe you want 
to?

Basically:

You create a new branch in your repository:

$ git checkout -b worg-new-exporter

Then you push this new branch to the remote repository:

$ git push -u origin worg-new-exporter

Then you can work in this new branch and just push from this branch
whenever you want:

$ git push

Everybody else can hook onto this branch with

$ git checkout --track -b worg-new-exporter origin/worg-new-exporter

and then work in this branch and push it whenever they want.

 
 2. Creating and maintaining a file that contains a site map of Worg,
   with all files that need publishing
 
 I could take a stab at this, but it won't be instantaneous. If someone
 has the time and energy to do this in the short term ( 1 week),
 they'd be better. If a week or so is acceptable, I can take this one
 as well, at least the creation part. I'm assuming it will be a big
 todo list? From there, it would be much easier if editors updated it
 themselves.

I agree, this would be easiest.  Organizing this would then mean
to announce to precise procedure on the mailing list and hope that people
hack away.

 
 3. Organizing contributors who will look at one page after the other
   and implementing any changes needed to make the page export (not yet
   publish) cleanly with the new exporter.  In this way we need to walk
   through all Worg files, and someone needs to keep the tabs on this.
 
 Not sure we totally need to organize this. I'm wondering about
 something like an editor property in the file from #2. Contributors
 could self-assign by adding their name to that property in the tracker
 file and then push.

Yes this is a good way.  Organizing then means to check for files
that have not been done and do them yourself or encourage other
directly to do it.

 Perhaps an agenda view or simply column view could
 quickly show who is assigned to what file?
 
 4. When all this is done, see what changes have to be made to the
   publishing setup to fix the automatic publishing.
 
 I'd be really bad at this as I've never actually set up publishing. I
 can definitely help with some of the #+attr_backend and general syntax
 stuff, but I never got heavy into the site publishing features and
 have never even looked at Worg's setup for this.

Well, if you get everything working with the new exporter, we
will find a way to fix publishing if necessary.

 
 If this is the process... how does the public Worg get updated in the
 mean time? I'm pretty new to git and only do basic stuff. Diffs have
 always been intimidating (and I've found them to really stink even for
 really, really small changes I've had). How will we maintain the
 public site and then re-combine with the public one down the road?
 Editing on the public one needs to happen in old syntax; public repo
 for upgrade hacking needs to be in the new syntax.

We definitely do NOT stop to edit Worg in the mean time.  The master
branch can be edited in parallel.  This is git, so we can merge both
branches when the time comes.

It would be great if you can take a stab at this, John.

- Carsten

 
 Should we freeze Worg for the time being and direct editing to happen
 at the other one?
 
 
 Best regards,
 John
 
 
 Any takers?
 
 Once we are done with this, we also need the orgmode.org website, but
 that contains fewer 

Re: [O] Release 8.0

[Thorsten Jolitz]

John Hendy jw.he...@gmail.com writes:

 No.  Someone needs to carefully check he can exports his local clone
 of worg.git with the new exporter, fix the wrong syntax, then commit
 it.  This surely deserves a public branch of Worg, which people can
 hack together.

 We need a volunteer who is willing to coordinate the conversion
 of Worg to the new exporter.  This is an important task.  Dogfooding
 Worg to the new exporter will be a good way to find remaining bugs
 in the parser/exporter setup.

 This task would entail:

[...]

 3. Organizing contributors who will look at one page after the other
and implementing any changes needed to make the page export (not yet
publish) cleanly with the new exporter.  In this way we need to walk
through all Worg files, and someone needs to keep the tabs on this.

 Not sure we totally need to organize this. I'm wondering about
 something like an editor property in the file from #2. Contributors
 could self-assign by adding their name to that property in the tracker
 file and then push. Perhaps an agenda view or simply column view could
 quickly show who is assigned to what file?

 Any takers?

I don't know if this would put a huge work load on somebody who
contributed *much* content to Worg, but otherwise I would propose for
this step that all authors of Worg articles/pages take care of their own
pages. In my case that would be e.g. half a dozen of pages, not that
much of a problem.

Once most Worg authors have fixed their own pages, another round of
fixing the (few?) remaining pages by some volunteers could be started.

Just my 2cents

-- 
cheers,
Thorsten

Re: [O] Can't export LaTeX source code blocks

[Nicolas Goaziou]

Hello,

Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 As shown by the following ECM, I can't export the LaTeX code blocks.

 #+TITLE: ECM exports LaTeX code
 #+Time-stamp: 2013-04-22 Mon 21:31
 #+LANGUAGE:  en

 #+PROPERTY: exports both

 * Context

 My goal is to explain different LaTeX blocks which I use to construct a LaTeX
 class. The document should be exportable to both LaTeX and HTML.

 * TODO Documentation

 Here is the LaTeX code:

 #+name: doc-macro-a
 #+begin_src latex
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+end_src

 followed by the LaTeX output:

 #+results: doc-macro-a
 #+BEGIN_LaTeX
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+END_LaTeX

 * Results

 As you can see, the code block is NEVER exported. I don't understand
 why?

I'm not sure either.

This is not a problem from the exporter as
`org-export-execute-babel-code' on your ECM makes the src block
disappear.

 The results block is exported, but then (interpreted and) only visible in the
 LaTeX back-end. The HTML document is completely empty...

I can answer that one: #+begin_BACKEND means export this block when
using export BACKEND, otherwise ignore it. Therefore, html back-end
ignores the results.


Regards,

-- 
Nicolas Goaziou

Re: [O] bug: /italic/ sometimes fails

[Bastien]

Hi Bill,

Bill White bi...@wolfram.com writes:

  - Org-mode version 8.0.1 (release_8.0.1-15-g0fff0b @ 
 /home/billw/Dropbox/org/org-mode/lisp/)
  - GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2013-03-11 on 
 wri

 Italicization fails when a doublequote character is adjacent to a
 slash.

This is intended.

You might want to have a look at the variable
`org-emphasis-regexp-components'.

Do carefully check the docstring of this variable

C-h v org-emphasis-regexp-components RET

it explains how to modify it.

HTH,

-- 
 Bastien

Re: [O] Bug: Append new heading when :END: exists

[Bastien]

Yes, this is the same problem than the one reported by Muchenxuan
Tong; a different problem than the one reported by Jeff, fixed.

(I will take a lot at the problem later on this week.)

I first wasn't able to reproduce those problems because I have
`org-special-ctrl-a/e' set to 'reversed, so C-e does not go after
the folded region -- maybe this should be the default behavior,
it would avoid a lot of these problems.

-- 
 Bastien

Re: [O] bug: /italic/ sometimes fails

[Bill White]

On Mon Apr 22 2013 at 15:29, Bastien b...@gnu.org wrote:

 Hi Bill,

 Bill White bi...@wolfram.com writes:

  - Org-mode version 8.0.1 (release_8.0.1-15-g0fff0b @ 
 /home/billw/Dropbox/org/org-mode/lisp/)
  - GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2013-03-11 on 
 wri

 Italicization fails when a doublequote character is adjacent to a
 slash.

 This is intended.

 You might want to have a look at the variable
 `org-emphasis-regexp-components'.

 Do carefully check the docstring of this variable

 C-h v org-emphasis-regexp-components RET

 it explains how to modify it.

Well heck, that variable is right there in the docs and I missed it:

To fine tune what characters are allowed before and after the markup
characters, you can tweak ORG-EMPHASIS-REGEXP-COMPONENTS.

Thank you!

bw
-- 
Bill White . bi...@wolfram.com
No ma'am, we're musicians.

Re: [O] Can't export LaTeX source code blocks

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
 Sebastien Vauban writes:

 As shown by the following ECM, I can't export the LaTeX code blocks.

 #+TITLE: ECM exports LaTeX code
 #+Time-stamp: 2013-04-22 Mon 21:31
 #+LANGUAGE:  en

 #+PROPERTY: exports both

 * Context

 My goal is to explain different LaTeX blocks which I use to construct a LaTeX
 class. The document should be exportable to both LaTeX and HTML.

 * TODO Documentation

 Here is the LaTeX code:

 #+name: doc-macro-a
 #+begin_src latex
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+end_src

 followed by the LaTeX output:

 #+results: doc-macro-a
 #+BEGIN_LaTeX
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+END_LaTeX

 * Results

 As you can see, the code block is NEVER exported. I don't understand
 why?

 I'm not sure either.

 This is not a problem from the exporter as
 `org-export-execute-babel-code' on your ECM makes the src block
 disappear.

 The results block is exported, but then (interpreted and) only visible in the
 LaTeX back-end. The HTML document is completely empty...

 I can answer that one: #+begin_BACKEND means export this block when
 using export BACKEND, otherwise ignore it. Therefore, html back-end
 ignores the results.

Yes, I agree: that second behavior is logical. I just emphasized it as,
consequently, we can't export anything (not even the results -- though, that
does not make much sense) to HTML, as exposed by the ECM.

The only buggy behavior is the first one: the fact that the code block
disappears, as you say.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] converting people to Emacs and org-mode

[Samuel Wales]

On 4/22/13, Bastien b...@gnu.org wrote:
 I use xcalib (http://xcalib.sourceforge.net/) to quickly switch
 from light-on-dark (most often) to dark-on-light (from time to
 time) and I recommend it.

Interesting.  How did you use it to do that?  I had assumed that
colors could not be inverted automatically without algorithms
specifically designed for the purpose.

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] [bug] list sorting wrong-type-argument error

[Samuel Wales]

It works.  Thanks.

On 4/21/13, Bastien b...@altern.org wrote:
 This is now fixed, thanks.

-- 
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] export to various flavors of (X)HTML

[Rick Frankel]

On Sat, Apr 20, 2013 at 10:59:32AM +0800, Eric Abrahamsen wrote:
 
 The  / style doesn't validate for html4, that's what I was going on.
 It certainly doesn't make my browser explode, but I wanted that little
 green checkmark! If we can live with that, that's fine, or I can try to
 come up with a less hacky way of handling closing tags -- a macro
 maybe.

It should validate. According to the w3c compatibility guidelines
(http://www.w3.org/TR/xhtml1/guidelines.html):

C.2. Empty Elements

Include a space before the trailing / and  of empty elements,
e.g. br /, hr / and img src=karen.jpg alt=Karen /. 
Also, use the minimized tag syntax for empty elements, e.g. br /, 
as the alternative syntax br/br allowed by XML gives uncertain 
results in many existing user agents.

C.3. Element Minimization and Empty Element Content

Given an empty instance of an element whose content model is not EMPTY
(for example, an empty title or paragraph) do not use the minimized 
form (e.g. use p /p and not p /).

 
 The xmns declaration, on the other hand, seems quite meaningless for
 anything that isn't xhtml (even if it doesn't actually break), and it's
 only a couple of lines of code to deal with, I'd rather keep that in
 there...

fair enough.

rick

Re: [O] Bug: Append new heading when :END: exists

[Muchenxuan Tong]

I checked the code of `org-insert-heading'.

One potential factor: when folded, and putting cursor and the end of
heading, the cursor is supposed to be

:END: (here)

and it's not judged as a heading.


On Tue, Apr 23, 2013 at 2:57 AM, Bastien b...@gnu.org wrote:

 I'm tempted to apply the following patch, as this problem falls under
 the category of inserting in an invisible region.  I don't think it
 breaks any non-interactive call of org-insert-heading, but this needs
 further checking.

 Also, note that the problem occurs only when there is no blank line
 between the :END: and the following headline, so maybe the real fix
 has to be within org-insert-heading...



 --
  Bastien

[O] How to use overprint in Beamer export

[Eric Schulte]

Hi,

I'd like to enclose a series of blocks which replace each other in the
Beamer overprint environment.

Here's the LateX I'd like to produce.

% latex
\begin{frame}[fragile]{The Things}
\begin{block}{Things}
  \begin{description}[+-]
  \item[foo] the first thing I want to talk about
  \item[bar] this is the second, follows the first
  \item[baz] third and final
  \end{description}
\end{block}

\begin{overprint}
  \onslide1
  \begin{block}{Foo}
A picture of a ``foo''.
  \end{block}

  \onslide2
  \begin{block}{Bar}
Some text about ``bar''.
  \end{block}

  \onslide3
  \begin{block}{Baz}
Content relevant only to ``baz''.
  \end{block}

\end{overprint}

\end{frame}

I see no way to generate this from Org-mode given the folding behavior
of Org-mode outlines.  Namely the fact that there is no way to *close* a
heading.

Any suggestions appreciated.  Thanks,

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

Re: [O] Can't export LaTeX source code blocks

[Thomas S. Dye]

Aloha Seb,

Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 * TODO Documentation

 Here is the LaTeX code:

 #+name: doc-macro-a
 #+begin_src latex
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+end_src

 followed by the LaTeX output:

 #+results: doc-macro-a
 #+BEGIN_LaTeX
 \DescribeMacro{\dummyMacro}
 This macro does nothing.\index{doing nothing|usage} It is merely an
 example.  If this were a real macro, you would put a paragraph here
 describing \textbf{what} the macro is supposed to do, what its mandatory and
 optional arguments are, and so forth.
 #+END_LaTeX

 * Results

 As you can see, the code block is NEVER exported. I don't understand
 why?

 I'm not sure either.

 This is not a problem from the exporter as
 `org-export-execute-babel-code' on your ECM makes the src block
 disappear.

 The results block is exported, but then (interpreted and) only visible in 
 the
 LaTeX back-end. The HTML document is completely empty...

 I can answer that one: #+begin_BACKEND means export this block when
 using export BACKEND, otherwise ignore it. Therefore, html back-end
 ignores the results.

 Yes, I agree: that second behavior is logical. I just emphasized it as,
 consequently, we can't export anything (not even the results -- though, that
 does not make much sense) to HTML, as exposed by the ECM.

 The only buggy behavior is the first one: the fact that the code block
 disappears, as you say.

I took a quick look at ob-latex.el. The code there sets `:exports
results' and then, IIUC, goes on its way without checking if :exports
has been set in the buffer.

IIRC, the main uses of LaTeX code blocks were for tangling .tex
documents, and for preview snippets. This seems to be supported by the
documentation, which says LaTeX source code blocks can be used to
tangle a LaTeX source file, or to create bitmap images or pdf snippets
of arbitrary LaTeX code.

It looks to me like ob-latex.el would need to be revised to work with
your use case (a document about LaTeX authoring?).

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] are babel python sessions and inlined images incompatible?

[Rodrigo Amestica]

Hello,

if I use this block

#+BEGIN_SRC python :results file
from pylab import *
plot(rand(10))
savefig('images/test.png')
return 'images/test.png'
#+END_SRC 

then the RESULTS block shows me an inlined version of the plot.

If now I switch to this block

#+BEGIN_SRC python :session test :results file
from pylab import *
plot(rand(10))
savefig('images/test.png')
return 'images/test.png'
#+END_SRC 

then the RESULTS block does not show the inlined plot but this

| matplotlib.lines.Line2D | object | at | 0x35c0650 |

Using a session is kind of mandatory for me because I need several blocks to
share variables.

Is there something evidently wrong with my approach?

thanks,
 Rodrigo

Re: [O] [PATCH] export to various flavors of (X)HTML

[Eric Abrahamsen]

Rick Frankel r...@rickster.com writes:

 On Sat, Apr 20, 2013 at 10:59:32AM +0800, Eric Abrahamsen wrote:
 
 The  / style doesn't validate for html4, that's what I was going on.
 It certainly doesn't make my browser explode, but I wanted that little
 green checkmark! If we can live with that, that's fine, or I can try to
 come up with a less hacky way of handling closing tags -- a macro
 maybe.

 It should validate. According to the w3c compatibility guidelines
 (http://www.w3.org/TR/xhtml1/guidelines.html):

 C.2. Empty Elements

 Include a space before the trailing / and  of empty elements,
 e.g. br /, hr / and img src=karen.jpg alt=Karen /. 
 Also, use the minimized tag syntax for empty elements, e.g. br /, 
 as the alternative syntax br/br allowed by XML gives uncertain 
 results in many existing user agents.

 C.3. Element Minimization and Empty Element Content

 Given an empty instance of an element whose content model is not EMPTY
 (for example, an empty title or paragraph) do not use the minimized 
 form (e.g. use p /p and not p /).

Right, but as the note at the top of that page says:

This appendix summarizes design guidelines for authors who wish their
XHTML documents to render on existing HTML user agents.

I read that as just a better statement of what I was trying to say
earlier: self-closing tags will render in HTML4, but they're not
_strictly correct_ HTML4.

Try the validation link at the bottom of this page:

http://ericabrahamsen.net/html4test.html

It's not a disaster.

I'm happy to do whatever needs to be done with the patch, whether that
means dropping the closing-tags fix, re-implementing it, or whatever. It
would be good to hear other HTML-users' opinions on this, if anyone has
one!

E

 The xmns declaration, on the other hand, seems quite meaningless for
 anything that isn't xhtml (even if it doesn't actually break), and it's
 only a couple of lines of code to deal with, I'd rather keep that in
 there...

 fair enough.

 rick

Re: [O] converting people to Emacs and org-mode

[Achim Gratz]

Sebastien Vauban writes:
 What I once heard from ergonomical studies is that black on white
 was better than white on black. Though, is it based on real grounds?

All these studies dependend on which CRT was used (most of which
produced blurry pictures for dark-on-light content) and are mostly moot
with current LCD monitors.  The remaining differences are due to
environmental conditions, but if you follow the lighting recommendations
for office work and adjust the screen brightness (most LCD screens
default much too bright as that looks better in stores) you'll be almost
certainly much better off with a light background and black script, for
the simple reason that your eyes' pupils will be smaller and the depth
of focus larger that way.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada