Re: [O] Problems with capture and lisp code

[Nicolas Goaziou]

Hello,

Thomas Holst  writes:

> for my work flow I would like to set up a capture template based on the
> ideas described in:
>
> http://www.jboecker.de/2010/04/14/general-reference-filing-with-org-mode.html#sec-5
>
> The original is based on remember but I want to use capture. The
> principle is as follows:
>
> In the capture template run some lisp code which appends a function to
> `org-capture-before-finalize-hook' which calls `org-attach-mv' to attach
> a file.
>
> The function run from capture template looks like this:
>
> #+begin_src emacs-lisp
> (defun th:filing-install-attach-mv-hook ()
>   "call this from a capture template to install th:filing-attach-mv-hook"
>   (add-hook 'org-capture-before-finalize-hook 'th:filing-attach-mv-hook)
>   (make-local-variable 'kill-buffer-hook)
>   (add-hook 'kill-buffer-hook 'th:filing-uninstall-attach-mv-hook)
>   (add-hook 'org-capture-mode-hook 'th:filing-uninstall-attach-mv-hook)
>   (message "finalize-hook: %s" org-capture-before-finalize-hook))
> #+end_src
>
> In the messages buffer I can see that at run time of the function
> `th:filing-attach-mv-hook' is in `org-capture-before-finalize-hook'.
>
> Now when I look at `org-capture-before-finalize-hook' in the final
> capture buffer `th:filing-attach-mv-hook' is not there.
>
> The same happens with `kill-buffer-hook'. I also tried
> `org-capture-prepare-finalize-hook'. Same result.
>
> So I am puzzled here :-(. Is there some caching mechanism involved? For
> the author of the article stated above this worked with remember - but
> why does it not work with capture.

Wild guess: capture template is expanded in a temporary buffer, which is
killed once the process is complete. Therefore, the uninstall hook
installed in `kill-hook-buffer' removes your function before it is
actually used.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-resolve-clocks should not iterate over non-agenda org files [8.3.3 (8.3.3-elpaplus @ /home/dfeich/.emacs.d/elpa/org-plus-contrib-20160108/)

[Nicolas Goaziou]

Hello,

Derek Feichtinger  writes:

> The thing which made it hard for me to identify the initial problem was
> that the test CLOCK lines I had in the testing file where placed there
> without a heading. When later in the day I wanted to clock in to my tasks,
>  I then just ended up with a "outline-back-to-heading: before first
> heading" error, but with no indicator which of my ~60 open org files was
> the culprit. Maybe one could insert the file location in that error
> message?

Actually, that is the very point of `org-back-to-heading' but... it
wasn't used. I fixed it. Thank you.

> Since org is so extremely useful, and I almost spend 80% of my day in org
> files (also some of my collaborators are beginning to use it... it is
> viral), I often have >50 files with all kinds of purposes open: agenda,
> various notes, beamer, html-exports, wiki-authoring, project-organization,
> bookkeeping... the thing is just too useful. So, I think clashes between
> the many uses of org files probably are natural.
>
> This being emacs  :-) I just decided to advise org-resolve-clocks.

Exactly. Thanks to Emacs, you can bend any part of Org to your needs.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change \[..\] and $$...$$ into elements

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> What's wrong with equation (potentially coupled with mathtools for
> handling numbering automatically)?  Is it worth breaking old documents
> (irrespective of org-lint) for this inconvenience?

Actually, the idea behind this patch is to mimic the expected LaTeX
behaviour,i.e., treat \[..\] as an equivalent
to \begin{equation*}...\end{equation*}.

This was requested at least once before, so I guess it may make sense to
follow the path of least surprise.

Breaking old-documents is obviously a concern, but is the following
construct really common?

  Text \[math formula\] ...


Regards,

-- 
Nicolas Goaziou

[O] Problems with capture and lisp code

[Thomas Holst]

Hi,

for my work flow I would like to set up a capture template based on the
ideas described in:

http://www.jboecker.de/2010/04/14/general-reference-filing-with-org-mode.html#sec-5

The original is based on remember but I want to use capture. The
principle is as follows:

In the capture template run some lisp code which appends a function to
`org-capture-before-finalize-hook' which calls `org-attach-mv' to attach
a file.

The function run from capture template looks like this:

#+begin_src emacs-lisp
(defun th:filing-install-attach-mv-hook ()
  "call this from a capture template to install th:filing-attach-mv-hook"
  (add-hook 'org-capture-before-finalize-hook 'th:filing-attach-mv-hook)
  (make-local-variable 'kill-buffer-hook)
  (add-hook 'kill-buffer-hook 'th:filing-uninstall-attach-mv-hook)
  (add-hook 'org-capture-mode-hook 'th:filing-uninstall-attach-mv-hook)
  (message "finalize-hook: %s" org-capture-before-finalize-hook))
#+end_src

In the messages buffer I can see that at run time of the function
`th:filing-attach-mv-hook' is in `org-capture-before-finalize-hook'.

Now when I look at `org-capture-before-finalize-hook' in the final
capture buffer `th:filing-attach-mv-hook' is not there.

The same happens with `kill-buffer-hook'. I also tried
`org-capture-prepare-finalize-hook'. Same result.

So I am puzzled here :-(. Is there some caching mechanism involved? For
the author of the article stated above this worked with remember - but
why does it not work with capture.

Any pointers welcome. Thanks for looking into this.

-- 
Mit freundlichen Grüßen / Best regards
  Thomas Holst 

Re: [O] Renaming of +NAME for code blocks to in HTML export, no longer user defined

[Nicolas Goaziou]

Hello,

Adam Aviv  writes:

> Interesting. I don't know if it is a bug, though, as this seems intentional
> and matches my experience. The idea being that if you want to label
> something, you use the :name tag, but this will make it so the second item
> is evaluated, producing a unique identifier. The unique identifier is then
> assigned instead of the :name tag. If it was an, OR, however, then every
> element block would get a label, and that might be suboptimal given that
> not every block is referenced later.

That's correct.

> I would still like to be able to add my own name tags, but understand why
> this might have been changed to avoid to blocks having the same label.

That and the fact that one might introduce forbidden characters in the
name (e.g., ask the user to know about forbidden characters in the
target format). The generic names are pretty safe.

Anyway, what about using special blocks to generate custom ?

  #+attr_html: :property whatever
  #+begin_something
  ...
  #+end_something


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-resolve-clocks should not iterate over non-agenda org files [8.3.3 (8.3.3-elpaplus @ /home/dfeich/.emacs.d/elpa/org-plus-contrib-20160108/)

[Derek Feichtinger]

Hi Nicolas

Ok, that makes sense, then. Probably there are other users who indeed will
rely on clocking in non-agenda files.

The thing which made it hard for me to identify the initial problem was
that the test CLOCK lines I had in the testing file where placed there
without a heading. When later in the day I wanted to clock in to my tasks,
 I then just ended up with a "outline-back-to-heading: before first
heading" error, but with no indicator which of my ~60 open org files was
the culprit. Maybe one could insert the file location in that error message?

Since org is so extremely useful, and I almost spend 80% of my day in org
files (also some of my collaborators are beginning to use it... it is
viral), I often have >50 files with all kinds of purposes open: agenda,
various notes, beamer, html-exports, wiki-authoring, project-organization,
bookkeeping... the thing is just too useful. So, I think clashes between
the many uses of org files probably are natural.

This being emacs  :-) I just decided to advise org-resolve-clocks.

(defun dfeich/org-resolve-clocks (orig-function  only-dangling-p
prompt-fn last-valid)
  (cl-letf (((symbol-function 'org-files-list) 'org-agenda-files))
(apply orig-function only-dangling-p prompt-fn last-valid)))

(advice-add #'org-resolve-clocks :around #'dfeich/org-resolve-clocks)

Thanks for maintaining and developing an environment which made my time in
front of the keyboard so much more efficient.

Derek

On Wed, Jan 20, 2016 at 2:14 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Derek Feichtinger  writes:
>
> > org-resolve-clock loops over all open org buffers for detecting open
> > clocks (using function org-files-list). Is this really intended? I think
> > it should just loop over the org-agenda-files.
> >
> > I was working on an extension for clocking and was recording my testing
> > results
> > into a separate org file. I also had put there examples of
> > various clock lines to test regexps against. The example clock lines
> > effectively prevented me from clocking in to a task from my normal
> > agenda files.
> >
> > Since org has so many usages, I think it should not be assumed that each
> > org buffer is related to the agenda functionality.
>
> Clocking is not just an agenda functionality. Since every Org document
> can contain clocks, it makes sense to use `org-files-list' instead of
> `org-agenda-files'.
>
> You could test your extension in a dedicated Emacs process, with
> `org-agenda-files' being nil and Org documents opened piece-wise.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] quote block interrupts text?

[Nicolas Goaziou]

Hello,

Lawrence Bottorff  writes:

> I've got this
>
> ** The quick red fox
>
>#+BEGIN_QUOTE
>red foxes are great
>#+END_QUOTE
>
>jumped over the lazy brown dog.
>
> But when I export to HTML I see the
>
> 
>
>   1.5
>The quick red fox
> 
> 
>
> Red foxes are great.
>
> jumped over the lazy brown dog.
>
> 
>
> That is, the export is introducing  when the level's text resumes after
> the quote, forcing me to pick through my style.css and change everything
> individually, e.g., font-size.

As their name suggest, quote (or src, etc.) /blocks/ are not inline.
When you start one, you end the currently running paragraph. Once the
block is over, you start another one.

> What I need is for the "jumped over the lazy dog." to not be in
>  under the  but
> outside it, i.e., at the same level as the first block of text.
> Basically, I want a way to insert quotes, code blocks, whatever and
> not have it twist up the HTML.

Now, I do not fully understand your request. "the first block of text"
is the title, right? Everything but the title is located within .

Anyway, it would help to now what you really want to achieve with your
Org document.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-latex-compile timestamp checks

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Since this is a bugfix I guess you should use org-sublist (*shiver*) in
> maint and cl-subseq in master.  We can’t use cl-lib in maint, right
> Nicolas?

Absolutely.

>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>> need a similar trick.
>
> Perhaps there should be an error check in ox-odt as well?  I guess the
> only thing that could happen is that the zip/odt can’t be written, which
> could happen if it’s open in windows, which is extremely picky with locked
> files.  [I have had to use a windows machine at work].

This makes sense, indeed.

Would you want to take care of applying the patches and updating the
various export back-ends accordingly, or should I?


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change \[..\] and $$...$$ into elements

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> What's wrong with equation (potentially coupled with mathtools for
>> handling numbering automatically)?  Is it worth breaking old documents
>> (irrespective of org-lint) for this inconvenience?
>
> Actually, the idea behind this patch is to mimic the expected LaTeX
> behaviour,i.e., treat \[..\] as an equivalent
> to \begin{equation*}...\end{equation*}.
>
> This was requested at least once before, so I guess it may make sense to
> follow the path of least surprise.

And I'm saying that people should just write:

 #+latex_header: \usepackage{mathtools} \mathtoolsset{showonlyrefs}
 aaa
 \begin{equation}
 bbb
 \end{equation}
 ccc

Org isn't LaTeX and there’s no difference in the output from \[⋯\]
and \begin{equation*}⋯\end{equation*} or the above.

Nonetheless, I don't feel strongly about the (non)issue so if this
behavior is better, somehow, go for it.

Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: [O] [PATCH] org-latex-compile timestamp checks

[Rasmus]

Nicolas Goaziou  writes:

>>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>>> need a similar trick.
>>
>> Perhaps there should be an error check in ox-odt as well?  I guess the
>> only thing that could happen is that the zip/odt can’t be written, which
>> could happen if it’s open in windows, which is extremely picky with locked
>> files.  [I have had to use a windows machine at work].
>
> This makes sense, indeed.
>
> Would you want to take care of applying the patches and updating the
> various export back-ends accordingly, or should I?

My life is a bit stressful at the moment (deadlines).  I'm happy to do it,
and maybe I can do it in the weekend, but if you feel like taking doing it
I won’t stand in your way.

Rasmus

-- 
The right to be left alone is a human right

Re: [O] Renaming of +NAME for code blocks to in HTML export, no longer user defined

[Adam Aviv]

On Thu, Jan 21, 2016 at 4:20 AM, Nicolas Goaziou 
wrote:

> That and the fact that one might introduce forbidden characters in the
> name (e.g., ask the user to know about forbidden characters in the
> target format). The generic names are pretty safe.
>
> Anyway, what about using special blocks to generate custom ?
>
>   #+attr_html: :property whatever
>   #+begin_something
>   ...
>   #+end_something
>
>
Thanks for the feedback. All of that makes sense. Is there really a
+begin_somthing tag? Or are you referring to any general tag? Sorry for my
obtuseness.

I'll look into the :property issue: I think that'd properly work for my
needs.


-- 
Adam J. Aviv, PhD
*Asst. Professor*
*Computer Science*
*U.S. Naval Academy*
*(410) 293- 6655*

Re: [O] Problems with capture and lisp code

[Thomas Holst]

Hi Nicolas,

· Nicolas Goaziou  wrote:

> Hello,
>
> Thomas Holst  writes:
>
>> for my work flow I would like to set up a capture template based on the
>> ideas described in:
>>
>> http://www.jboecker.de/2010/04/14/general-reference-filing-with-org-mode.html#sec-5
>>
>> The original is based on remember but I want to use capture. The
>> principle is as follows:
>>
>> In the capture template run some lisp code which appends a function to
>> `org-capture-before-finalize-hook' which calls `org-attach-mv' to attach
>> a file.
>>
>> The function run from capture template looks like this:
>>
>> #+begin_src emacs-lisp
>> (defun th:filing-install-attach-mv-hook ()
>>   "call this from a capture template to install th:filing-attach-mv-hook"
>>   (add-hook 'org-capture-before-finalize-hook 'th:filing-attach-mv-hook)
>>   (make-local-variable 'kill-buffer-hook)
>>   (add-hook 'kill-buffer-hook 'th:filing-uninstall-attach-mv-hook)
>>   (add-hook 'org-capture-mode-hook 'th:filing-uninstall-attach-mv-hook)
>>   (message "finalize-hook: %s" org-capture-before-finalize-hook))
>> #+end_src
>>
>> In the messages buffer I can see that at run time of the function
>> `th:filing-attach-mv-hook' is in `org-capture-before-finalize-hook'.
>>
>> Now when I look at `org-capture-before-finalize-hook' in the final
>> capture buffer `th:filing-attach-mv-hook' is not there.
>>
>> The same happens with `kill-buffer-hook'. I also tried
>> `org-capture-prepare-finalize-hook'. Same result.
>>
>> So I am puzzled here :-(. Is there some caching mechanism involved? For
>> the author of the article stated above this worked with remember - but
>> why does it not work with capture.
>
> Wild guess: capture template is expanded in a temporary buffer, which is
> killed once the process is complete. Therefore, the uninstall hook
> installed in `kill-hook-buffer' removes your function before it is
> actually used.

that's it! your guess is right! Seems that is what is going on!

The function in `kill-buffer-hook' was to remove
`th:filing-attach-mv-hook' when capture buffer was killed with C-c C-k.

Is there another way to execute lisp code when capture buffer is killed
with C-c C-k?

I could alter `kill-buffer-hook' globally, but then if another buffer is
killed while capture buffer still is there the function is also removed.

Hmm ... - I have to think it over maybe I find a solution for that.

Anyway thanks a lot for the pointer!

-- 
Mit freundlichen Grüßen / Best regards 
  Thomas

Re: [O] ob-julia, src block execution undefined function org-babel-get-header

[Kyle Meyer]

Hi Andreas,

Andreas  writes:

> Hi list,
> I was hoping to get some help with this issue
>
> I use:
> Org-mode version 8.3.3 (release_8.3.3-468-gf3f4b2)
> GNU Emacs 25.1.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.16.7) of 2016-01-17
> ess-version: 15.09-2 patched [git: 6d05ba7c89371764c43e30a436d7166417cabd4d]
> julia version 0.4.2
>
> I'm trying to execute julia code src blocks but have come across a problem.
>
> When trying to do C-c C-c in the src block emacs complain about an
> undefined function org-babel-get-header.

org-babel-get-header was removed in 0d000f5 (babel: small change in API,
2015-10-29) and has the following NEWS entry:

*** ~org-babel-get-header~ is removed.
Use ~org-babel--get-vars~ or ~assq~ instead, as applicable.

However, ob-julia, along with several other packages in contrib, still
use org-babel-get-header.

> I think I have tracked down the error to ob-julia where org-babel-get-header
> is used.
> I found a reference to a similar problem for ob-html package here:
> https://github.com/zweifisch/ob-http/issues/12
> I tried to edit the ob-julia file based on that fix but failed to make it
> work.

I think something like the fix at that link should work.  What did you
try and how did it fail?

Also, perhaps it's worth raising the issue here:

https://github.com/gjkerns/ob-julia

--
Kyle

[O] ob-julia, src block execution undefined function org-babel-get-header

[Andreas]

Hi list,
I was hoping to get some help with this issue

I use:
Org-mode version 8.3.3 (release_8.3.3-468-gf3f4b2)
GNU Emacs 25.1.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.16.7) of 2016-01-17
ess-version: 15.09-2 patched [git: 6d05ba7c89371764c43e30a436d7166417cabd4d]
julia version 0.4.2

I'm trying to execute julia code src blocks but have come across a problem.

When trying to do C-c C-c in the src block emacs complain about an
undefined function org-babel-get-header.
I think I have tracked down the error to ob-julia where org-babel-get-header
is used.
I found a reference to a similar problem for ob-html package here:
https://github.com/zweifisch/ob-http/issues/12
I tried to edit the ob-julia file based on that fix but failed to make it
work.

I should also mention that a similar issue was covered in a previous thread
but the info in this thread https://lists.gnu.org
/archive/html/emacs-orgmode/2015-11/msg00426.html
I can't apply to my problem as there is only one ob-julia.

This looks like an issue in ob-julia, unless I overlooked something in my
setup.
I tried running the same setup with a fresh emacs -q -l init.el loading only
org-version:
Org-mode version 8.2.10 (release_8.2.10 @ /usr/share/emacs/25.1.50/lisp/org
/)
which is bundled with my emacs
and the ess package
and I could evaluate julia src blocks with that setup.

Any advice or fixes I could apply would be appreciated, or if this issue
can be fixed elsewhere.

regards
Andreas

[O] Bug: [PATCH] Tiny timezone bug in ox-icalendar [8.3.3 (release_8.3.3-2-g6bc48c @ /home/rwl/src/org-mode/lisp/)]

[Richard Lawrence]

Hi all,

I finally got annoyed enough to debug a problem with the timezone field
in the .ics export of my agenda.

Turns out the problem was simple: org-icalendar--vcalendar was being
called with the wrong argument order in
org-icalendar-export-current-agenda, so the timezone was going into the
description field rather than the timezone field.

Here's a patch that fixes that.  Note that it should be applied to
maint.  I did not generate a commit against master, but I can if need
be.

Best,
Richard

>From 410ba46791e2f4cf470f8727298c3faa5b717e56 Mon Sep 17 00:00:00 2001
From: Richard Lawrence 
Date: Thu, 21 Jan 2016 17:28:58 -0800
Subject: [PATCH] ox-icalendar:  fix timezone export bug

* ox-icalendar.el (org-icalendar-export-current-agenda): Correct
  argument order in call to org-icalendar--vcalendar (timezone should be
  third, description fourth).

TINYCHANGE
---
 lisp/ox-icalendar.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index be2f3e6..a7cb4fb 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -909,8 +909,8 @@ This function assumes major mode for current buffer is
(org-icalendar--vcalendar
 	org-icalendar-combined-name
 	user-full-name
-	org-icalendar-combined-description
 	(or (org-string-nw-p org-icalendar-timezone) (cadr (current-time-zone)))
+	org-icalendar-combined-description
 	contents)))
 (run-hook-with-args 'org-icalendar-after-save-hook file)))
 
-- 
2.1.4