Re: [O] HTML table export options essentially undocumented

[Vladimir Lomov]

Hello,
** James Harkins [2014-03-18 13:52:10 +0800]:

> The documentation here seems rather un-detailed.

> http://orgmode.org/manual/Tables-in-HTML-export.html#Tables-in-HTML-export

> What I wanted to do was to have vertical rules between all columns, but not
> horizontal rules. Neither this section of the documentation, nor the
> docstring for org-html-table-default-attributes, provide any details on how
> to do this.

> It's a rather busy day and I'm not in the mood to scour through the elisp
> sources, so, could someone please enlighten (and fix the docs)?

AFAIU, in current state table decoration is hard coded into exporter.
But that doesn't mean you cannot change they style. Take a look on this
small example:
-- 8< --
#+TITLE: Table with borders
#+AUTHOR: Vladimir Lomov
#+HTML_HEAD_EXTRA: 

* Small table

| Name | Address|
|--+|
| Clifford, A. | Kensington Av. |
| Euler, G | Krechet Str.   |

* CSS Style:noexport:

#+BEGIN_SRC css :tangle tbl.css
  table {
border: solid 1px;
  }
  td {
border: solid 1px;
  }
#+END_SRC
-- 8< --

How to try: tangle the SRC block and then export the document into HTML.
Open it in any web-browser that supports CSS.

> hjh

---
WBR, Vladimir Lomov

-- 
Some people have a way about them that seems to say: "If I have
only one life to live, let me live it as a jerk."

[O] Header ':comments noweb' mangles lines in tangled code

[Vladimir Lomov]

Hello,
consider the following example Org document:

-- 8< -- 
#+TITLE: Example
#+AUTHOR: Vladimir Lomov

* How ~comments~ interferes with ~noweb~

#+NAME: code1
#+BEGIN_SRC sh
  var1
#+END_SRC

#+NAME: code2
#+BEGIN_SRC sh
  [[ -t ${SHELL} ]]
#+END_SRC

#+BEGIN_SRC sh :noweb yes :tangle ex-sh.sh
  <> = <>

  <> && {
echo "HELLO..."
  }
#+END_SRC

** Now ~comments~ is on

At first, ~comments~ is ~link~

#+BEGIN_SRC sh :noweb yes :tangle ex-c:link.sh :comments link
  <> = <>

  <> && {
echo "HELLO..."
  }
#+END_SRC

Then ~comments~ is ~org~

#+BEGIN_SRC sh :noweb yes :tangle ex-c:org.sh :comments org
  <> = <>

  <> && {
echo "HELLO..."
  }
#+END_SRC

Now ~comments~ is ~both~

#+BEGIN_SRC sh :noweb yes :tangle ex-c:both.sh :comments both
  <> = <>

  <> && {
echo "HELLO..."
  }
#+END_SRC

And finally, ~comments~ is ~noweb~

#+BEGIN_SRC sh :noweb yes :tangle ex-c:noweb.sh :comments noweb
  <> = <>

  <> && {
echo "HELLO..."
  }
#+END_SRC
-- 8< -- 

All combinations except ':comments noweb' give expected results, while
the last one produces a file with mangled lines,
- 8< ex-c:noweb.sh 8< -- 
# [[file:ex.org::*Now%20~comments~%20is%20on][Now\ ~comments~\ is\ on:4]]
# [[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code1]]
var1
# code1 ends here = # 
[[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code1]]
<> = var1
<> = # code1 ends here

# [[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code2]]
[[ -t ${SHELL} ]]
# code2 ends here && {
  echo "HELLO..."
}
# Now\ ~comments~\ is\ on:4 ends here
-- 8< -- 
Is it expected behaviour meaning a limitation of ':comments noweb' or a
bug?

I'm using Org mode:
Org-mode version 8.2.5h (release_8.2.5h-777-g5d8cc3 
@/usr/share/emacs/site-lisp/org/)

---
WBR, Vladimir Lomov

-- 
My mother was a test tube; my father was a knife.
-- Friday

[O] HTML table export options essentially undocumented

[James Harkins]

The documentation here seems rather un-detailed.

http://orgmode.org/manual/Tables-in-HTML-export.html#Tables-in-HTML-export

What I wanted to do was to have vertical rules between all columns, but not 
horizontal rules. Neither this section of the documentation, nor the 
docstring for org-html-table-default-attributes, provide any details on how 
to do this.


It's a rather busy day and I'm not in the mood to scour through the elisp 
sources, so, could someone please enlighten (and fix the docs)?


hjh

Re: [O] [patch][ox-html] Support for level based containers

[Rasmus]

Rick Frankel  writes:

> On Mon, Mar 17, 2014 at 11:26:28PM +0100, Rasmus wrote:
>> Rick Frankel  writes:
>>
>
>> > On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
>> >> Hi Rasmus and Nicolas,
>> >>
>> >
>> >> Nicolas Goaziou  writes:
>> >>
>> >> >> Let me know if you find you'd be willing to merge something like this
>> >> >
>> >> > I don't know enough HTML to have an opinion here.
>> >>
>> >
>> > I don't think it's a bad change, but i have a couple of concerns:
>> >
>> > 1. It's a breaking change.
>> > 2. The default should mimic the current functionality:
>> >='((div . div))=
>> > 3. The customization should be more structured, not just a
>> >string (see e.g., =org-html-text-markup-alist=.)
>> >
>> > Attached is a modification of the patch which fixes 2 & 3. #1 is a
>> > question more for Nicolas & Bastien...
>>
>> It seems you modified v1 rather than v2 that I send last night¹?  I'm
>> not sure if point 1 holds in the second revision as it explicitly
>> allows for a string as now. I think I disagree with your point 2 as it
>> only shows up when you use HTML5-fancy.  On point 3,
>
> But not everyone using html5-fancy would agree with your choice of
> hierarchy, and it should be up to indvidual users to add additional
> semantic structure to the output.

It's a variable that you can set in your project or in your Org file
or in your init file.  I don't see why div × 3 is better than section
article div or something else conditional on two variables being
explicitly set to get fancy HTML5. . .  In any case, I don't have
strong—if any—preferences on this.

>> org-html-text-markup-alist is nice.  What do you want to see in
>> addition to the current structure (in patch v2)?
>
> Somehow I never saw the original thread, only the email cc'ing me
> directly. I went to gmane to find the patch, and obviously grabbed the
> wrong one.
>
> Could you please send me the (new) patch so that i can review it?

Here's the Gmane link.  I believe it's different than what you
reviewed before, but perhaps I'm wrong. . .

>> Footnotes: 
>> ¹   http://permalink.gmane.org/gmane.emacs.orgmode/83635

—Rasmus

-- 
ツ

Re: [O] babel completion notification

[Nick Dokos]

Eric Schulte  writes:

> Nick Dokos  writes:
>
>> (popup.py is my homemade notifier)
>
> Try adding `(lambda () (shell-command-to-string "popup.py babel done"))'
> to your `org-babel-after-execute-hook'.
>
>> 
>> I get the popup immediately and the results after 10 seconds.  The
>> org-babel-after-execute-hook method worked fine.
>>

Yes, as I said, the hook worked fine :-), although the function would
have to be munged so that the notification doesn't pop up
indiscriminately after every evaluation.

>
> That is probably because the elisp form in the :post value is executed
> at header-argument parse time before the code block is executed.  If
> instead your use a code block name as your post header argument it will
> only be evaluated after the code block finishes.
>

Thanks - that's good to know: the fact that it can be applied
selectively to certain code blocks does make it a much better solution
than the hook.

However, there is a problem:

--8<---cut here---start->8---
#+name: notify
#+BEGIN_SRC emacs-lisp :results none
(shell-command "popup.py DONE")
#+END_SRC

#+name: long-running
#+BEGIN_SRC shell :results output :post notify
sleep 5
echo DONE
#+END_SRC

#+RESULTS: long-running
: nil
--8<---cut here---end--->8---

The result seems to be the result of the notify block, not the
long-running one.

-- 
Nick

[O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}

[Luke Crook]

I'm looking for a quick and dirty way to use the org-mode variables within 
Latex.

I thought the following might work;

#+TITLE: A nice title

#+LATEX_HEADER: \newcommand{\orgtitle}TITLE

And then in the .tex file;

\orgtitle{}


Suggestions?
Thanks

Re: [O] babel completion notification

[Eric Schulte]

Nick Dokos  writes:

> Ken Mankoff  writes:
>
>> Hi Eric,
>>
>> On 2014-03-17 at 17:05, Eric Schulte wrote:
>>> Ken Mankoff  writes:
>>>
 Until asynchronous babel exists, it would be nice to at least be
 notified when long-running tasks complete. Does anyone have advice
 how to set up a hook on babel completion so that growl or some
 other system notification alerts, perhaps only if the execution
 took more than x seconds?
>>>
>>> You can use the org-babel-after-execute-hook to run any action after a
>>> code block finishes executing.
>>
>> Yes, and your reply makes me recall that :post works too, so I can
>> call a shell command "notifier" (or Growl) like this:
>>  
>> #+BEGIN_SRC python -n :results output :post (shell-command-to-string 
>> "notifier 'babel done'")
>> print "hello, world"
>> #+END_SRC
>> #+RESULTS:
>>
>
> The :post method does not seem to work for me. With:
>
> --8<---cut here---start->8---
> #+BEGIN_SRC sh :results output  :post (shell-command-to-string "popup.py 
> babel done")
> sleep 10
> echo DONE
> #+END_SRC
> --8<---cut here---end--->8---
>
> (popup.py is my homemade notifier)

Try adding `(lambda () (shell-command-to-string "popup.py babel done"))'
to your `org-babel-after-execute-hook'.

> 
> I get the popup immediately and the results after 10 seconds.  The
> org-babel-after-execute-hook method worked fine.
>

That is probably because the elisp form in the :post value is executed
at header-argument parse time before the code block is executed.  If
instead your use a code block name as your post header argument it will
only be evaluated after the code block finishes.

Best,

>
> Nick
>
>
>
>
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [patch][ox-html] Stylistic changes

[Rick Frankel]

On Mon, Mar 17, 2014 at 11:19:27PM +0100, Rasmus wrote:
> Hi Rick,
> 
> Rick Frankel  writes:
> 
> > On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote:
> >> Hello,
> >>
> >> Nicolas Goaziou  writes:
> >>
> >> > So if the change is only stylistic, I see no reason to break
> >> > compatibility with "ox-freemind.el".
> >
> >> I would favor a solution where the HTML backend uses what's
> >> readable (— and friends) and where the Freemind backend
> >> deals with this.
> >>
> >> Maybe `org-html-special-string-regexps' could be a variable
> >> and Freemind could temporarily set it up to what it needs?
> >
> > The use of numeric vs. named entities is not just stylistic.
> > XHMTL[45] only support the 5 basic named entities interally:
> >
> >   - & - the ampersand &
> >   - " - the double quote "
> >   - ' single quote '
> >   - < - less-than <
> >   - > - greater-than >
> >
> > So including any others will generate non-conforming output.
> > Since the change is cosmetic, I don't see the purpose in adding a lot
> > of conditional code to the exporter to output different entities for
> > html[45] vs xhtml[45].
> 
> AFAIK, we have a lot more entities in org-entities with &PRETTY-NAME;.
> When I've entities I've used a pretty name over a numeric value when I
> found one.  What's you'r opinion on that?  Should we go for readable
> or aim towards replacing them with these numeric values?

We should use only those named entities (above) which are valid in
xhtml(5). So, yes, we should change to using numeric entites for any
other than the above.

rick

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On Mon, Mar 17, 2014 at 11:26:28PM +0100, Rasmus wrote:
> Rick Frankel  writes:
>
> > On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
> >> Hi Rasmus and Nicolas,
> >>
> >
> >> Nicolas Goaziou  writes:
> >>
> >> >> Let me know if you find you'd be willing to merge something like this
> >> >
> >> > I don't know enough HTML to have an opinion here.
> >>
> >
> > I don't think it's a bad change, but i have a couple of concerns:
> >
> > 1. It's a breaking change.
> > 2. The default should mimic the current functionality:
> >='((div . div))=
> > 3. The customization should be more structured, not just a
> >string (see e.g., =org-html-text-markup-alist=.)
> >
> > Attached is a modification of the patch which fixes 2 & 3. #1 is a
> > question more for Nicolas & Bastien...
>
> It seems you modified v1 rather than v2 that I send last night¹?  I'm
> not sure if point 1 holds in the second revision as it explicitly
> allows for a string as now. I think I disagree with your point 2 as it
> only shows up when you use HTML5-fancy.  On point 3,

But not everyone using html5-fancy would agree with your choice of
hierarchy, and it should be up to indvidual users to add additional
semantic structure to the output.

> org-html-text-markup-alist is nice.  What do you want to see in
> addition to the current structure (in patch v2)?

Somehow I never saw the original thread, only the email cc'ing me
directly. I went to gmane to find the patch, and obviously grabbed the
wrong one.

Could you please send me the (new) patch so that i can review it?

thanx,
rick

[O] Org Agenda and BBDB File

[Aric Gregson]

Hello,

I am wondering if it is possible to get org-mode to stop asking to read
the bbdb file when creating the new agenda. It is a bit annoying because
GNUS in another instance of emacs generally has the file. 

I have seemingly removed any calls to bbdb in my org set-up (initially
used it for anniversaries, but now doesn't appear to work in bbbd v3). I
now have no dates that need to be looked at for agenda creation in org
mode.

If I have  '(org-agenda-files (quote ("~/org"))) and the bbdb file is in
this directory, it is then used by org mode to create the agenda? My
impression was that only files ending in '.org' in the directory were
used. 

Thanks, Aric

Re: [O] bug#16832: Emacs goes crazy when deleting lines

[Stefan]

> So, it only covers a single command (C-k).

Sorry, forget my question: I had forgotten to turn my brain on, somehow
(seems to happen too often lately).
These numbers aren't call counts, they're just numbers of samples, so
there's no evidence that flyspell-post-command-hook was run very many times.


Stefan

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Bastien]

Ilya Shlyakhter  writes:

> When I open emacs with this file, move to the emacs-lisp block, and
> evaluate it, I get "aaa".

I can reproduce your problem now, I'm on it, and the problem is real,
but I need to make sure all tests pass fine before fixing this.

Thanks,

-- 
 Bastien

[O] [PATCH] Only set org-hide foreground if one is available

[Nikolai Weibull]

* org.el (org-mode): Add guard around set-face-foreground.
(org-mode): When loading Org buffers through desktop, there will not be
a foreground set for org-hide.  Therefore, simply do not set the
foreground of org-hide unless there is one to set.
---
 lisp/org.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5a02c66..b991692 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5509,7 +5509,9 @@ The following commands are available:
  (unless org-inhibit-startup-visibility-stuff
(org-set-startup-visibility
   ;; Try to set org-hide correctly
-  (set-face-foreground 'org-hide (org-find-invisible-foreground)))
+  (let ((foreground (org-find-invisible-foreground)))
+(if foreground
+(set-face-foreground 'org-hide foreground
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
-- 
1.8.5.4

Re: [O] [patch][ox-html] Stylistic changes

[Rasmus]

Hi Rick,

Rick Frankel  writes:

> On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote:
>> Hello,
>>
>> Nicolas Goaziou  writes:
>>
>> > So if the change is only stylistic, I see no reason to break
>> > compatibility with "ox-freemind.el".
>
>> I would favor a solution where the HTML backend uses what's
>> readable (— and friends) and where the Freemind backend
>> deals with this.
>>
>> Maybe `org-html-special-string-regexps' could be a variable
>> and Freemind could temporarily set it up to what it needs?
>
> The use of numeric vs. named entities is not just stylistic.
> XHMTL[45] only support the 5 basic named entities interally:
>
>   - & - the ampersand &
>   - " - the double quote "
>   - ' single quote '
>   - < - less-than <
>   - > - greater-than >
>
> So including any others will generate non-conforming output.
> Since the change is cosmetic, I don't see the purpose in adding a lot
> of conditional code to the exporter to output different entities for
> html[45] vs xhtml[45].

AFAIK, we have a lot more entities in org-entities with &PRETTY-NAME;.
When I've entities I've used a pretty name over a numeric value when I
found one.  What's you'r opinion on that?  Should we go for readable
or aim towards replacing them with these numeric values?

—Rasmus

-- 
With monopolies the cake is a lie!

Re: [O] [patch][ox-html] Support for level based containers

[Rasmus]

Rick Frankel  writes:

> On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
>> Hi Rasmus and Nicolas,
>>
>
>> Nicolas Goaziou  writes:
>>
>> >> Let me know if you find you'd be willing to merge something like this
>> >
>> > I don't know enough HTML to have an opinion here.
>>
>
> I don't think it's a bad change, but i have a couple of concerns:
>
> 1. It's a breaking change.
> 2. The default should mimic the current functionality:
>='((div . div))=
> 3. The customization should be more structured, not just a
>string (see e.g., =org-html-text-markup-alist=.)
>
> Attached is a modification of the patch which fixes 2 & 3. #1 is a
> question more for Nicolas & Bastien...

It seems you modified v1 rather than v2 that I send last night¹?  I'm
not sure if point 1 holds in the second revision as it explicitly
allows for a string as now. I think I disagree with your point 2 as it
only shows up when you use HTML5-fancy.  On point 3,
org-html-text-markup-alist is nice.  What do you want to see in
addition to the current structure (in patch v2)?

—Rasmus

Footnotes: 
¹   http://permalink.gmane.org/gmane.emacs.orgmode/83635

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Ilya Shlyakhter]

On 3/17/14 5:43 PM, Achim Gratz wrote:

The test case doesn't work as posted.  A working test case produces the


Try http://ilya.cc/testcase.org

When I open emacs with this file, move to the emacs-lisp block, and 
evaluate it, I get "aaa".


I could easily be wrong re: the logic of the code, but can you help me 
see where I'm wrong in the explanation of the patch?


Thanks,

ilya

Re: [O] babel completion notification

[Nick Dokos]

Ken Mankoff  writes:

> Hi Eric,
>
> On 2014-03-17 at 17:05, Eric Schulte wrote:
>> Ken Mankoff  writes:
>>
>>> Until asynchronous babel exists, it would be nice to at least be
>>> notified when long-running tasks complete. Does anyone have advice
>>> how to set up a hook on babel completion so that growl or some
>>> other system notification alerts, perhaps only if the execution
>>> took more than x seconds?
>>
>> You can use the org-babel-after-execute-hook to run any action after a
>> code block finishes executing.
>
> Yes, and your reply makes me recall that :post works too, so I can
> call a shell command "notifier" (or Growl) like this:
>  
> #+BEGIN_SRC python -n :results output :post (shell-command-to-string 
> "notifier 'babel done'")
> print "hello, world"
> #+END_SRC
> #+RESULTS:
>

The :post method does not seem to work for me. With:

--8<---cut here---start->8---
#+BEGIN_SRC sh :results output  :post (shell-command-to-string "popup.py babel 
done")
sleep 10
echo DONE
#+END_SRC
--8<---cut here---end--->8---

(popup.py is my homemade notifier) I get the popup immediately and the
results after 10 seconds.  The org-babel-after-execute-hook method
worked fine.

Nick

Re: [O] Incorrect hexification in URLs in LaTeX Export

[Andreas Leha]

Hi Bastien,

Bastien  writes:

> "R. Michael Weylandt "
>  writes:
>
>> I've tried this with Org 7.9.3 and 8.2.5h to the same result:
>>
>> <-->
>> #+TITLE: Test
>> * One
>> Here is a [[http://google.com/search?q=orgmode][link]]
>> <-->
>>
>> Exporting to HTML doesn't transform the link but exporting to LaTeX
>> results in the (non-working) http://google.com/search?%3Dorgmode
>
> I think this is now fixed in master.  Can anyone confirm this?


Thanks for looking into this.  It seems the proposed fix is working at
most partly.  Or maybe I get something wrong?


Following is the test file from above in an extended version.

The first link is exported correctly (I do not know whether it has been
before).

I opened the link in firefox, copied the address from firefox and
inserted into the Org file via 'C-c C-l', which gives me the second
link.

The second link is not clickable in the resulting pdf.


--8<---cut here---start->8---
#+TITLE: Test
* One
Here is a [[http://google.com/search?q=orgmode][link]]

This one is the same, but inserted via C-c C-l and the system clipboard.
[[https://encrypted.google.com/search?q%3Dorgmode][link]]

#+LaTeX_header: \usepackage{hyperref}
--8<---cut here---end--->8---


Regards,
Andreas

Re: [O] bug#16832: Emacs goes crazy when deleting lines

[Fabrice Niessen]

Stefan wrote:
>> I thought at using the profiler of Emacs 24, and it gives meaningful
>> results. Good news #2.
>> Here they are:
>> --8<---cut here---start->8---
>> - flyspell-post-command-hook 3271  98%
>
> Does this report only cover a single command that took a "very long
> time" until it gave you back control (in which case I'm wondering why
> flyspell-post-command-hook should be called so many times), or does it
> cover a longer part of your editing session?

I launched M-x profiler-start just before killing (C-k) the line which
I know shows the problem.

I launched M-x profiler-report as soon as I got control back.

So, it only covers a single command (C-k).

Fabrice Niessen

-- 
Fabrice Niessen
Leuven, Belgium
http://www.pirilampo.org/

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Ilya Shlyakhter]

In the current master branch, doing the example from the patch
(reproduced below again) gives "aaa", because the line
  (let (org-file-properties org-global-properties
org-global-properties-fixed)
has been removed from org-entry-get-with-inheritance .
I agree that patching a function as core as this should be done with
care; however, I'm pretty positive that there was a bug, as explained
in the patch message.
org-entry-get-with-inheritance calls org-entry-get for each entry
going up the tree, to read the property at that entry _without_
inheritance; however, unless
the let line above is included, this reading actually happens _with_
inheritance -- of global properties.  So a property can appear to be
set at a node during
up-the-tree traversal, when in fact it is only set as a global
property.   If org-entry-get-with-inheritance see a property set at a
node during up-the-tree traversal,
it stops the traversal right there, ignoring any settings of this
property further up the tree -- which should override any global
settings of the same property.

Here is the test case again:

#+PROPERTY: myprop aaa
* headline A
  :PROPERTIES:
  :myprop: bbb
  :END:
*** headline B
:PROPERTIES:
:otherprop:   ccc
:END:

#+BEGIN_SRC emacs-lisp
(message (org-entry-get-with-inheritance "myprop"))
#}

#+RESULTS:
: aaa



On Mon, Mar 17, 2014 at 4:35 PM, Bastien  wrote:
> Achim Gratz  writes:
>
>>> I meant: can you tell me how the tests fail?
>>
>> They don't produce the result they are supposed to produce.
>
> Thanks for this explanation.
>
>>> I'm interested in the answer.
>>
>> make BTEST_RE='\\(header-arg-defaults\\|property-accumulation\\)'
>> test-dirty
>
> Thanks!
>
> If the patch is good and the tests are outdated, I'd rather
> fix the tests than revert the patch to re-revert it again.

 No, the patch is bad, otherwise it wouldn't break the tests.
>>>
>>> Sorry, I don't buy this.
>>
>> I'm not selling anything.
>
> What I meant is this: broken tests are not a sufficient reason to
> revert a commit.  You need to show the commit is wrong and the tests
> are not outdated.
>
> In this case, I made the error of reproduce Ilya's solution,
> not Ilya's problem, so I wrong assumed his patch was the problem
> to his problem.
>
> Ilya: from the maint and master branch, I get "bbb" as a result
> for the example you placed in your commit message.  Do you have
> "aaa" as a result with Org from maint or master?  If so, can you
> provide a recipe?
>
> Thanks,
>
> --
>  Bastien

Re: [O] org-element checks make flyspell prohibitively slow

[Nicolas Goaziou]

Hello,

Matt Lundin  writes:

> The rewrite of org-mode-flyspell-verify in commit
> 4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating
> org-mode files with large chunks of text very slow.

[...]

> => Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @
> /home/matt/org-mode/lisp/)

Could you update and try again? Parser's cache was inadvertently
disabled. I re-enabled it.

> I open a test.org file containing the following.
>
> * A headline * Arch packages * Another headline
>
> After opening a line under "Arch Packages" I call...
>
> C-u M-! pacman -Ss [RET]
>
> (Of course, this only works with archlinux.) This inserts a long list of
> packages that look like this:
>
> core/acl 2.2.52-2 [installed]
> Access control list utilities, libraries and headers
> core/archlinux-keyring 20140220-1 [installed]
> Arch Linux PGP keyring
> core/attr 2.4.47-1 [installed]
> Extended attribute support library for ACL support
> core/autoconf 2.69-1 (base-devel) [installed]
> A GNU tool for automatically configuring source code
> core/automake 1.14.1-1 (base-devel) [installed]
> A GNU tool for automatically creating Makefiles
>  
> All in all, it's 12680 lines 

Note that it is a contrived example: the whole buffer is a single
paragraph containing around 150 objects. The current algorithm for
`org-element-context' is clearly not on par with such a density of
objects per paragraph.

Also, cache cannot help here, because each time you edit a paragraph,
all objects within are removed from the cache (because, AFAIK, there is
no way to know if the edition altered a previously parsed object or not,
so, as a security measure, all of them are wiped out) and you have to
parse them again.

Therefore, navigation should be fast but editing (with flyspell-mode
enabled) is going to be slow.

> But this works (more or less) with other very large chunks of text.
> E.g.,
>
> C-u M-! w3m -dump 
> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html

This one should be reasonably fast in both cases.

> Is it possible to speed up org-element-context here?

Certainly. `org-element-context' is the less optimized part of the
parser code. There is room for improvements.

> For something called as often as org-mode-flyspell-verify, do we need
> all the overhead of the org-element parser?

Of course.

> Or would a hack optimized for speed (which is what the older version
> of org-mode-flyspell-verify represented) be enough?

IMO, the old version of this function was annoying as soon as you
switched to a non-english language. YMMV.

> I recall (though my memory may be faulty) discussions on the list
> quite some time back in which we decided to prioritize
> speed/efficiency over thoroughness/completeness in the checks run by
> org-mode-flyspell-verify.

Why prioritize when we can have both?

I agree that `org-mode-flyspell-verify' is not fast enough at the time
being, but it is quite usable anyway. Also, as a very demanding
function, it is a good benchmark for the parser.

In order to improve the current state, reports (like those in your
message) help a lot. You can also help improving the algorithms.

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Achim Gratz]

Ilya Shlyakhter writes:
> Here is the test case again:

The test case doesn't work as posted.  A working test case produces the
result shown below (with and without your patch reverted) on current
master (tested again via make vanilla just to be sure).

--8<---cut here---start->8---
#+PROPERTY: myprop aaa
* headline A
  :PROPERTIES:
  :myprop: bbb
  :END:
*** headline B
:PROPERTIES:
:otherprop:   ccc
:END:

#+BEGIN_SRC emacs-lisp
(message (org-entry-get-with-inheritance "myprop"))
#+END_SRC

#+RESULTS:
: bbb
--8<---cut here---end--->8---

So what problem is your patch supposed to fix?


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] babel completion notification

[Ken Mankoff]

Hi Eric,

On 2014-03-17 at 17:05, Eric Schulte wrote:
> Ken Mankoff  writes:
>
>> Until asynchronous babel exists, it would be nice to at least be
>> notified when long-running tasks complete. Does anyone have advice
>> how to set up a hook on babel completion so that growl or some
>> other system notification alerts, perhaps only if the execution
>> took more than x seconds?
>
> You can use the org-babel-after-execute-hook to run any action after a
> code block finishes executing.

Yes, and your reply makes me recall that :post works too, so I can
call a shell command "notifier" (or Growl) like this:
 
#+BEGIN_SRC python -n :results output :post (shell-command-to-string "notifier 
'babel done'")
print "hello, world"
#+END_SRC
#+RESULTS:

Thanks,

  -k.

Re: [O] Babel should not work in the subtree marked as not exported

[Andreas Leha]

Hi Nicolas and Eric,

Eric Schulte  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Eric Schulte  writes:
>>
>>> This sounds like a good compromise to me.  As you say, this should
>>> easily and visually support both use cases and is intuitive.  I've not
>>> touched the export machinery myself, so I'll leave the implementation to
>>> Nicolas but I definitely support this approach.
>>
>> Here are the patches, with tests. I leave to someone else the
>> documentation part in the manual.
>>
>
> Applied with documentation.  Thanks,
>

Thank you very much!

- Andreas

Re: [O] babel completion notification

[Eric Schulte]

Hi Ken,

Ken Mankoff  writes:

> I see from old emails to this list that asynchronous babel does not
> exist and is non-trivial to implement.

Yes, at least my initial attempts to implement this did not succeed (see
line 100 of ob-comint.el), and I haven't had the time to revisit the
issue.  In actuality it may not be that much work to provide for
asynchronous evaluation (at least in most cases).

> Until asynchronous babel exists, it would be nice to at least be
> notified when long-running tasks complete. Does anyone have advice how
> to set up a hook on babel completion so that growl or some other
> system notification alerts, perhaps only if the execution took more
> than x seconds?
>

You can use the org-babel-after-execute-hook to run any action after a
code block finishes executing.

Best,

>
> Thanks,
>
>   -k.
>



-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Bastien]

Achim Gratz  writes:

> Bastien writes:
>> What I meant is this: broken tests are not a sufficient reason to
>> revert a commit.  You need to show the commit is wrong and the tests
>> are not outdated.
>
> No code breaking a test should have been committed in the first place,
> then we wouldn't need to have this discussion.  If the "tests are
> outdated" (in this case they ensure that the documentation and
> implementation are matching up which is difficult to ascertain by just
> playing with a single example, so that shouldn't ever happen), the onus
> is on the committer to explain why and change the tests and
> documentation accordingly (either as a preparation for that commit or in
> the same commit).

My assumption is that every committer does its best and that we
collectively try to help each other.

That's another way not to have this discussion.

I'm fine fixing bugs and tests introduced by someone else.

After all, I've answered hundreds of emails by people who are
confused by the new way of setting Org's version (which I will
revisit soon.)

-- 
 Bastien

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Achim Gratz]

Bastien writes:
> What I meant is this: broken tests are not a sufficient reason to
> revert a commit.  You need to show the commit is wrong and the tests
> are not outdated.

No code breaking a test should have been committed in the first place,
then we wouldn't need to have this discussion.  If the "tests are
outdated" (in this case they ensure that the documentation and
implementation are matching up which is difficult to ascertain by just
playing with a single example, so that shouldn't ever happen), the onus
is on the committer to explain why and change the tests and
documentation accordingly (either as a preparation for that commit or in
the same commit).


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] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Bastien]

Achim Gratz  writes:

>> I meant: can you tell me how the tests fail?
>
> They don't produce the result they are supposed to produce.

Thanks for this explanation.

>> I'm interested in the answer.
>
> make BTEST_RE='\\(header-arg-defaults\\|property-accumulation\\)'
> test-dirty

Thanks!

 If the patch is good and the tests are outdated, I'd rather
 fix the tests than revert the patch to re-revert it again.
>>>
>>> No, the patch is bad, otherwise it wouldn't break the tests.
>>
>> Sorry, I don't buy this.
>
> I'm not selling anything.

What I meant is this: broken tests are not a sufficient reason to
revert a commit.  You need to show the commit is wrong and the tests
are not outdated.

In this case, I made the error of reproduce Ilya's solution,
not Ilya's problem, so I wrong assumed his patch was the problem
to his problem.

Ilya: from the maint and master branch, I get "bbb" as a result
for the example you placed in your commit message.  Do you have
"aaa" as a result with Org from maint or master?  If so, can you
provide a recipe?

Thanks,

-- 
 Bastien

[O] babel completion notification

[Ken Mankoff]

I see from old emails to this list that asynchronous babel does not
exist and is non-trivial to implement. Until asynchronous babel
exists, it would be nice to at least be notified when long-running
tasks complete. Does anyone have advice how to set up a hook on babel
completion so that growl or some other system notification alerts,
perhaps only if the execution took more than x seconds?

Thanks,

  -k.

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Achim Gratz]

Bastien writes:
> Achim Gratz  writes:
>
>>> Can you tell a bit more about what's wrong with the test?
>>
>> There is nothing wrong with those tests.
>
> I meant: can you tell me how the tests fail?

They don't produce the result they are supposed to produce.

> I'm interested in the answer.

make BTEST_RE='\\(header-arg-defaults\\|property-accumulation\\)' test-dirty

>>> If the patch is good and the tests are outdated, I'd rather
>>> fix the tests than revert the patch to re-revert it again.
>>
>> No, the patch is bad, otherwise it wouldn't break the tests.
>
> Sorry, I don't buy this.

I'm not selling anything.

> Or maybe explain me why the patch is wrong.

It breaks property inheritance and accumulation.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Can I use an already defined agenda view in another agenda command?

[Matt Lundin]

M  writes:

> Salut Bastien,
>
> thanks a lot - that helps a little, however this will only work temporarily
> and already for the next "r" refresh, the combined agendas are not there any
> more, just one, if I am not mistaken.
>
> My question was more targeting in the direction if it could be possible to
> define one basic setup once and then create some different "flavors" of it
> without duplicating the configuration code to have a consistent setup...
>
> Example: 
> I'm having a block agenda which I use during my daily work and which shows
> me the deadlines of today, the appointments of today and the tasks scheduled
> today (and those overdue).
>
> That's fine for the day, but for my daily planning I do once in the morning
> it would be nice to use that same setup, but also see deadlines which are e.
> g. 10 days in the future and the scheduled tasks which will come up the next
> day(s).
>
> So my idea was: i can define the basic setup once, and then "cite" it and
> extend it for other agenda setups.

Here's an example of how something like this could be done:

--8<---cut here---start->8---
(defmacro my-agenda (days)
  `(list 'agenda ""
 (list (list 'org-deadline-warning-days ,days

(setq my-next-actions
  '("n" "All next actions" todo "TODO|NOW|NEXT"
((org-agenda-todo-ignore-scheduled 'future)
 (org-agenda-todo-ignore-deadlines 'far)
 (org-agenda-dim-blocked-tasks t

(setq my-projects
  '("q" "Projects" todo "PROJECT"
((org-agenda-todo-ignore-deadlines t)
 (org-agenda-prefix-format " %i %-12:c%l"

(setq org-agenda-custom-commands
  `(,my-next-actions
,my-projects
("k" "Combined"
 (,(cddr my-next-actions)
  ,(cddr my-projects)))
("d" "Short deadlines"
 (,(my-agenda 1)))
("D" "Long deadlines"
 (,(my-agenda 21)
--8<---cut here---end--->8---

Matt

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Bastien]

Achim Gratz  writes:

>> Can you tell a bit more about what's wrong with the test?
>
> There is nothing wrong with those tests.

I meant: can you tell me how the tests fail?

I'm interested in the answer.

>> If the patch is good and the tests are outdated, I'd rather
>> fix the tests than revert the patch to re-revert it again.
>
> No, the patch is bad, otherwise it wouldn't break the tests.

Sorry, I don't buy this.

Or maybe explain me why the patch is wrong.

Thanks,

-- 
 Bastien

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Achim Gratz]

Bastien writes:
> Can you tell a bit more about what's wrong with the test?

There is nothing wrong with those tests.

> If the patch is good and the tests are outdated, I'd rather
> fix the tests than revert the patch to re-revert it again.

No, the patch is bad, otherwise it wouldn't break the tests.  It may
well be that there'd be more tests needed to catch that bug the patch
supposedly fixes.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Bastien]

Achim Gratz  writes:

> Bastien writes:
>> Applied, thanks!
>
> That badly breaks the following tests:
>
>FAILED  test-ob-header-arg-defaults/tree/accumulate/call
>FAILED  test-ob-header-arg-defaults/tree/accumulate/noweb
>FAILED  test-ob-header-arg-defaults/tree/complex/call
>FAILED  test-ob-header-arg-defaults/tree/complex/noweb
>FAILED  test-org-property-accumulation-append-use
>FAILED  test-org-property-accumulation-append-val

Can you tell a bit more about what's wrong with the test?

If the patch is good and the tests are outdated, I'd rather
fix the tests than revert the patch to re-revert it again.

Thanks,

-- 
 Bastien

Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance

[Achim Gratz]

Bastien writes:
> Applied, thanks!

That badly breaks the following tests:

   FAILED  test-ob-header-arg-defaults/tree/accumulate/call
   FAILED  test-ob-header-arg-defaults/tree/accumulate/noweb
   FAILED  test-ob-header-arg-defaults/tree/complex/call
   FAILED  test-ob-header-arg-defaults/tree/complex/noweb
   FAILED  test-org-property-accumulation-append-use
   FAILED  test-org-property-accumulation-append-val

Please revert.


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] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

John Hendy  writes:

> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte  wrote:
>> John Hendy  writes:
>>
>>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug  wrote:



 On 02/07/14, 17:47 , Eric Schulte wrote:
 > Rainer M Krug  writes:
 >
 >> On 02/07/14, 07:18 , John Hendy wrote:
 >>> Greetings,
 >>>
 >>>
 >>> I don't usually tangle, but am creating a code file to go along with a
 >>> presentation I'm giving this weekend so that attendees can try things
 >>> out afterward by cloning my github repo where all the data and
 >>> necessary files are stored.
 >>>
 >>> In my presentation (Beamer), I create plots via the R pdf() device,
 >>> and noticed that all of the tangled code where plots are generated
 >>> contains the following:
 >>>
 >>> pdf(file="file.pdf"); tryCatch({
 >>>
 >>>   code block contents here
 >>>
 >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
 >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
 >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
 >>>
 >>> Is there a way to omit this?
 >>
 >> This is a bug which must have been introduced some time ago - in the
 >> stock version of emacs (Org-mode version 7.9.3f
 >> (release_7.9.3f-17-g7524ef @
 >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
 >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
 >> don't have an older version at hand to go further back).
 >>
 >
 > I believe this was introduced by your commit eaa3a761d.  Reversion of
 > which with the following should provide a temporary workaround.

>>
>> I take this back, the behavior is unrelated to Rainer's commit adding
>> try/catch blocks to R graphics creation logic.
>>
>> In fact I don't believe this is a bug, rather the default behavior is to
>> expand code block bodies on tangling.  This behavior may be changed by
>> using the :no-expand header argument which will inhibit code block body
>> expansion during tangling.
>>
>
> Got it, and thanks for the new variable tip!
>
> Out of curiosity, is there a consensus that this is the preferred
> behavior for tangling by default?

There may have been a consensus in a single thread motivated by a single
use case, which should not necessarily be a global consensus.

> I'm guessing at some point it was decided that the need was preferred
> to have these bits inserted before/after code blocks, but just trying
> to confirm this. It seems odd to me, at least given R's behavior, that
> someone would prefer these bits to show up in the tangled file since
> they appeared to serve the purpose of having Org not fail during
> export vs. benefitting the code in any way (if I wasn't running code
> through R, I'd just get the errors directly).
>

I'd be happy to add :no-expand to the default R header arguments.  Or
even to change this behavior globally, if the current behavior is
universally surprising.

Best,

>
>
> John
>
>> Best,
>>
>> --
>> Eric Schulte
>> https://cs.unm.edu/~eschulte
>> PGP: 0x614CA05D

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
> Hi Rasmus and Nicolas,
>
> Nicolas Goaziou  writes:
>
> >> Let me know if you find you'd be willing to merge something like this
> >
> > I don't know enough HTML to have an opinion here.
>

I don't think it's a bad change, but i have a couple of concerns:

1. It's a breaking change.
2. The default should mimic the current functionality:
   ='((div . div))=
3. The customization should be more structured, not just a
   string (see e.g., =org-html-text-markup-alist=.)

Attached is a modification of the patch which fixes 2 & 3. #1 is a
question more for Nicolas & Bastien...

rick
>From 21aed5d34613f9f922c2d1c8f5f67caac918c9cf Mon Sep 17 00:00:00 2001
From: Rick Frankel 
Date: Mon, 17 Mar 2014 13:27:12 -0400
Subject: [PATCH] Support for heading level based containers in ox-html.

* ox-html.el (org-html-container-element): Change to list of cons
cells for heading level containers.
(org-html--container): Use heading level entries from
org-html-container-element.
---
 lisp/ox-html.el | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index cb95161..b51a746 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -938,17 +938,23 @@ versions 8 and below."
   :package-version '(Org . "8.0")
   :type 'boolean)
 
-(defcustom org-html-container-element "div"
-  "HTML element to use for wrapping top level sections.
+(defcustom org-html-container-element '(("div" . "div"))
+
+  "HTML elements to use for wrapping sections.
 Can be set with the in-buffer HTML_CONTAINER property or for
 publishing, with :html-container.
 
-Note that changing the default will prevent you from using
-org-info.js for your website."
+Should be a list of cons cells with positions corresponding to
+heading levels.  If `org-html-html5-fancy' is t the cdr is used
+otherwise the car.
+
+Note that changing the default will prevent you from
+using org-info.js for your website."
   :group 'org-export-html
   :version "24.4"
   :package-version '(Org . "8.0")
-  :type 'string)
+  :type '(alist :key-type (string :tag "HTML4")
+   :value-type (string :tag "HTML5")))
 
 (defcustom org-html-divs
   '((preamble  "div" "preamble")
@@ -2410,9 +2416,14 @@ holding contextual information."
 
 (defun org-html--container (headline info)
   (or (org-element-property :HTML_CONTAINER headline)
-  (if (= 1 (org-export-get-relative-level headline info))
- (plist-get info :html-container)
-   "div")))
+  (let* ((hc (plist-get info :html-container))
+(n (org-export-get-relative-level headline info)))
+   (cond ((listp hc)
+  (or (funcall (if org-html-html5-fancy 'cdr-safe 'car-safe)
+   (nth (1- (min n (length hc))) hc)) "div"))
+ ((and (stringp hc) (= 1 n))
+  (plist-get info :html-container))
+ (t "div")
 
  Horizontal Rule
 
-- 
1.8.5.2 (Apple Git-48)

Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[John Hendy]

On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte  wrote:
> John Hendy  writes:
>
>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug  wrote:
>>>
>>>
>>>
>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>> > Rainer M Krug  writes:
>>> >
>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>> >>> Greetings,
>>> >>>
>>> >>>
>>> >>> I don't usually tangle, but am creating a code file to go along with a
>>> >>> presentation I'm giving this weekend so that attendees can try things
>>> >>> out afterward by cloning my github repo where all the data and
>>> >>> necessary files are stored.
>>> >>>
>>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>>> >>> and noticed that all of the tangled code where plots are generated
>>> >>> contains the following:
>>> >>>
>>> >>> pdf(file="file.pdf"); tryCatch({
>>> >>>
>>> >>>   code block contents here
>>> >>>
>>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>> >>>
>>> >>> Is there a way to omit this?
>>> >>
>>> >> This is a bug which must have been introduced some time ago - in the
>>> >> stock version of emacs (Org-mode version 7.9.3f
>>> >> (release_7.9.3f-17-g7524ef @
>>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>>> >> don't have an older version at hand to go further back).
>>> >>
>>> >
>>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>>> > which with the following should provide a temporary workaround.
>>>
>
> I take this back, the behavior is unrelated to Rainer's commit adding
> try/catch blocks to R graphics creation logic.
>
> In fact I don't believe this is a bug, rather the default behavior is to
> expand code block bodies on tangling.  This behavior may be changed by
> using the :no-expand header argument which will inhibit code block body
> expansion during tangling.
>

Got it, and thanks for the new variable tip!

Out of curiosity, is there a consensus that this is the preferred
behavior for tangling by default? I'm guessing at some point it was
decided that the need was preferred to have these bits inserted
before/after code blocks, but just trying to confirm this. It seems
odd to me, at least given R's behavior, that someone would prefer
these bits to show up in the tangled file since they appeared to serve
the purpose of having Org not fail during export vs. benefitting the
code in any way (if I wasn't running code through R, I'd just get the
errors directly).


John

> Best,
>
> --
> Eric Schulte
> https://cs.unm.edu/~eschulte
> PGP: 0x614CA05D

Re: [O] [patch][ox-html] Stylistic changes

[Rick Frankel]

On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote:
> Hello,
>
> Nicolas Goaziou  writes:
>
> > So if the change is only stylistic, I see no reason to break
> > compatibility with "ox-freemind.el".

> I would favor a solution where the HTML backend uses what's
> readable (— and friends) and where the Freemind backend
> deals with this.
>
> Maybe `org-html-special-string-regexps' could be a variable
> and Freemind could temporarily set it up to what it needs?

The use of numeric vs. named entities is not just stylistic.
XHMTL[45] only support the 5 basic named entities interally:

  - & - the ampersand &
  - " - the double quote "
  - ' single quote '
  - < - less-than <
  - > - greater-than >

So including any others will generate non-conforming output.
Since the change is cosmetic, I don't see the purpose in adding a lot
of conditional code to the exporter to output different entities for
html[45] vs xhtml[45].

rick

Re: [O] [patch] capture property table-line-pos can be a function

[Thomas Holst]

Hi,
> Hi Bastien,
>
> · Bastien  wrote:
>> Thomas Holst  writes:
>>
>>> Given a table with several sections and a capture template for entries
>>> in this table. The sections are dynamic, so a static value for
>>> table-line-pos does not help. With this patch table-line-pos can be:
>>>
>>> - a string like "II-2"
>>> - a varialbe containing a string
>>> - or a function
>>>   The function has to return a string which qualifies for table-line-pos
>>>
>>> This serves me well and I am using it for more than one year now.
>>
>> This sounds useful.  Could you also provide a patch for the
>> documentation?
>>
>> Thanks in advance!

ok here is the patch for documentation.

-- 
Bis neulich ...
  Thomas
>From 436e5adb0a9d0bc9ac37352bd90018c973dfdabf Mon Sep 17 00:00:00 2001
From: Thomas Holst 
Date: Mon, 17 Mar 2014 09:01:40 +0100
Subject: [PATCH] docu change for table-line-pos new feature

* org.texi: document new features of `table-line-pos' in capture
templates
---
 doc/org.texi |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index b53b668..2bebae4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7095,9 +7095,10 @@ narrow it so that you only see the new material.
 
 @item :table-line-pos
 Specification of the location in the table where the new line should be
-inserted.  It should be a string like @code{"II-3"} meaning that the new
-line should become the third line before the second horizontal separator
-line.
+inserted. It can be a string, a variable holding a string or a function
+returning a string. The string should look like @code{"II-3"} meaning that
+the new line should become the third line before the second horizontal
+separator line.
 
 @item :kill-buffer
 If the target file was not yet visited when capture was invoked, kill the
-- 
1.7.9

Re: [O] Extending the Org syntax by a custom exporter - how to do it?

[Marcin Borkowski]

Dnia 2014-03-16, o godz. 11:16:03
Nicolas Goaziou  napisał(a):

> Another, more advanced option, is to use a parse tree filter to create
> pseudo-types, i.e., element or object types that don't exist in
> regular Org syntax. See `math-block' type in "ox-latex.el", in
> particular `org-latex-math-block-tree-filter'.

I started to wonder and came to the conclusion that this might be
interesting for my "cloze" idea (with syntax as in one of my previous
messages).  However, I can't really understand what is going on here.
It seems to me that the key function is
org-latex--wrap-latex-math-block; it is, however, a bit long and I'm a
bit afraid of studying it (and don't have enough time today for that
anyway).  What would you suggest for grokking the idea of
"pseudo-objects"?  In particular:

- How do they get parsed?  What portions of the source should I read
  to understand that?

- Would it be a good idea to instrument one (or more) functions for
  edebug to get the idea of what's going on there?

- How risky is it to use Org from master in day-to-day usage?  Do
  people (other than the devs) do this on a regular basis?  Is coming
  back to maint as simple as checking out another branch from the git
  repo?

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] mobile-org http links not recognized on iPhone

[Sean Escriva]

Chris Henderson  writes:

> http links on mobile-org on iPhone is not click-able and I need to select
> all, copy and paste the link on safari instead of just clicking and opening
> it directly. Is this normal behavior?

No links should be clickable, they are for me. For example, with the
following link in my one of my org agenda files:

  - [[http://queue.acm.org/detail.cfm?id%3D2413037][Thinking Methodically about 
Performance]]

In MobilOrg I can view the node in the doc, using the right arrow, and
then choose View as Document. The links are clickable in this view, as
other views assume editing.

-- 
-sean

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> path is always a string. Description is always parsed (and transcoded
> already). In the most simple cases, they are equals.

I found out I have to parse the path because "hello \alpha" would not
be exported correctly otherwise.  (But I agree this is a corner case.)

> 5174495 adds contents to radio links (and, because of this, introduces
> an infloop in `org-element-context' on master, but that's another
> story). Your change parses link's contents on the fly. So this is mostly
> equivalent, albeit more verbose in all exporters.

Yes, I parsed the link's contents on the fly just for the purpose of
this small patch, but a general solution is better.

> So the question is : should we consider a radio-link as a link with
> a description, which would basically be its parsed path?

I think so.

> I think it is
> useful because its contents can differ from its relative radio-target,
> due to case-insensitivity.

Indeed.

Can you make the change (ie. radio-link is a link with a description,
the description being its parsed path)?  If so, do you want me to make
the change in the backends or do you want to take care of this too?

Thanks,

-- 
 Bastien

Re: [O] Extending the Org syntax by a custom exporter - how to do it?

[Marcin Borkowski]

Dnia 2014-03-16, o godz. 15:12:46
Nicolas Goaziou  napisał(a):

> Marcin Borkowski  writes:
> 
> > So basically I can attach #+ATTR_WHATEVER attributes also to lists,
> > paragraphs and other elements?  Even list items?  (This would mean
> > that I could mark the "correct" answer using that syntax - but I
> > think this would be too verbose.  I can't see any harm in abusing
> > checkboxes for that, though I [[http://xkcd.com/292/][might be
> > mistaken]];))
> 
> You can attach attributes (which is a subset of "affiliated keywords"
> category) to any element excepted clock, headline, inlinetask, item,
> planning, node-property, section and table-row types.

I see.

> So, plain lists can have attributes, but not items. There are
> workarounds, though. For example, you can use an export snippet at the
> beginning of the item to mark the correct answer. Hence, assuming
> "qcm" is the name of your backend, you could use:
> 
>   #+attr_qcm: :type mct
>   - answer a
>   - @@qcm:correct@@ answer b
>   - answer c
> 
> "ox-beamer.el" uses it to specify action overlays item wise. See
> `org-beamer-item' for an example.

Interesting, though I think I'll stick with checkboxes - esepcially
that it is easy for the user/author to mark them on and off.

> Regards,

Thanks again!

-- 
Marcin Borkowski
room B3-46, phone no +48 61 829 5375
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] Contribution: ob-groovy.el

[Bastien]

Hi Miro,

Miro Bezjak  writes:

> it took a while, but my FSF papers finally pulled through. I guess
> that means ob-groovy.el can now move from `contrib' and into `lisp'.

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=4d32b9eb

yes, I received the FSF confirmation and moved ob-groovy.el
a few days ago.

Thanks!

-- 
 Bastien

Re: [O] export ICal without evaluate code block

[Simon Thum]

Well, I was kind of shocked because the mails sounded to imply I need to 
switch evaluation off and, supposedly, extra-off-for-ical, too.


In fact that is the default, or so the source code comment reads but I 
have no idea how that works out.


Cheers,

Simon

On 03/13/2014 04:42 PM, Bastien wrote:

Hi Simon,

Simon Thum  writes:


Greppig org confirms icalendar is likely the only exception. While i
find this surprising I guess there is a good reason, right?


The "good" reason is that it's very unlikely for a user to need Babel
evaluation in an org-mode buffer before exporting this buffer to a
.ics file.

But we may as well be wrong, of course.

Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

John Hendy  writes:

> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug  wrote:
>>
>>
>>
>> On 02/07/14, 17:47 , Eric Schulte wrote:
>> > Rainer M Krug  writes:
>> >
>> >> On 02/07/14, 07:18 , John Hendy wrote:
>> >>> Greetings,
>> >>>
>> >>>
>> >>> I don't usually tangle, but am creating a code file to go along with a
>> >>> presentation I'm giving this weekend so that attendees can try things
>> >>> out afterward by cloning my github repo where all the data and
>> >>> necessary files are stored.
>> >>>
>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>> >>> and noticed that all of the tangled code where plots are generated
>> >>> contains the following:
>> >>>
>> >>> pdf(file="file.pdf"); tryCatch({
>> >>>
>> >>>   code block contents here
>> >>>
>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>> >>>
>> >>> Is there a way to omit this?
>> >>
>> >> This is a bug which must have been introduced some time ago - in the
>> >> stock version of emacs (Org-mode version 7.9.3f
>> >> (release_7.9.3f-17-g7524ef @
>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>> >> don't have an older version at hand to go further back).
>> >>
>> >
>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>> > which with the following should provide a temporary workaround.
>>

I take this back, the behavior is unrelated to Rainer's commit adding
try/catch blocks to R graphics creation logic.

In fact I don't believe this is a bug, rather the default behavior is to
expand code block bodies on tangling.  This behavior may be changed by
using the :no-expand header argument which will inhibit code block body
expansion during tangling.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[O] place mark at entry for org-agenda-diary-entry

[Tory S. Anderson]

In Agenda view, 'i' executes org-agenda-diary-entry. However, the entry is just 
appears somewhere in the list, and if I want to further refine it, I need to 
search for it. How can I have my mark automatically moved to the newly created 
item? 

Re: [O] bug#16832: Emacs goes crazy when deleting lines

[Stefan]

> I thought at using the profiler of Emacs 24, and it gives meaningful
> results. Good news #2.
> Here they are:
> --8<---cut here---start->8---
> - flyspell-post-command-hook 3271  98%

Does this report only cover a single command that took a "very long
time" until it gave you back control (in which case I'm wondering why
flyspell-post-command-hook should be called so many times), or does it
cover a longer part of your editing session?


Stefan

Re: [O] org-cook

[Erik Hetzner]

At Mon, 17 Mar 2014 10:34:55 -0400,
Ken Mankoff wrote:
> 
> Hi,
> 
> This isn't directly related to Org, but I'll mention it anyway since
> people are discussing quantities and "scale" for their
> recipes. Various programming languages have "physical units" packages
> that can make working with units quite fun. I use the python
> "Quantities" package
> http://pythonhosted.org/quantities/user/tutorial.html . It lets you
> define custom quantities such as how many grams of butter are in a
> stick, etc. A wrapper to this would let you convert Org recipe
> shopping lists from units of "g" and "teaspoon" to units of "sticks"
> and "fluid oz".

Hi Ken,

emacs calc also handles units. For org-cook [1] I extended the
definitions as follows (calc already has definitions for fluid oz):

  (setq math-additional-units
'((pinch "tsp / 8" "Pinch")
  (drop "tsp / 76" "Drop")
  (dash "drop * 6" "Dash")
  (jigger "floz * 1.5" "Jigger")
  (gill "floz * 4" "Gill")))

best, Erik

1. https://gitorious.org/org-cook/org-cook/

-- 
Sent from my free software system .

Re: [O] org-cook

[Ken Mankoff]

Hi,

This isn't directly related to Org, but I'll mention it anyway since
people are discussing quantities and "scale" for their
recipes. Various programming languages have "physical units" packages
that can make working with units quite fun. I use the python
"Quantities" package
http://pythonhosted.org/quantities/user/tutorial.html . It lets you
define custom quantities such as how many grams of butter are in a
stick, etc. A wrapper to this would let you convert Org recipe
shopping lists from units of "g" and "teaspoon" to units of "sticks"
and "fluid oz".

  -k. 


On 2014-03-17 at 10:26, Xebar Saram wrote:
> thank you all for the great answers
>
> Fletcher, your idea sounds great, but why not use  org tables as people
> suggested for ingredients. ive started using it yesterday and im very
> pleased, in example:
>
> *** COOK Pancakes:American:
>
>
> :PROPERTIES:
> :Source: TV
> :Serves:
> :Time:
> :Rating:
> :Fav:
> :END:
>
> | Quantity | scale | Ingredient| Instructions |
> |--+---+---+--|
> |8 |   | eggs  |  |
> |1 | liter | milk  |  |
> |  350 | g | butter| melted   |
> |  730 | g | flour |  |
> |   90 | g | powderd sugar |  |
> |   60 | g | baking powder |  |
> |   10 | g | salt  |  |
>
> _*Directions*:_
>
>
> best
>
> Z
>
>
> On Mon, Mar 17, 2014 at 4:22 PM, Fletcher Charest <
> fletcher.char...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> Since we are on this subject, are you aware of any package that would make
>> an 'automatic' shopping list based on recipes? My idea was to record
>> recipes in this format:
>>
>> * Name of the recipe  :tag:
>>
>> 1) Step one.
>> 2) Step two.
>> 3) Step three.
>>
>> :PROPERTIES:
>> :ingredient_1: quantity
>> :ingredient_2: quantity
>> :ingredient_3: quantity
>> :END:
>>
>> Tags could be anything, be mainly things like 'breakfast', 'main course'
>> or 'dessert'. Then, with the point on the headline, (in the file buffer or
>> in the agenda buffer), you could call a function that would add the
>> ingredient to a list, or increment its quantity if the ingredient is
>> already there. Maybe a function to add a random number of recipes (through
>> a filter or not) to the shopping list would be nice too, if you don't know
>> what to cook in a particular week.
>>
>> I'm planning to do this but my Elisp-fu is not great... Any tips of how
>> implementing this? Are lists a good data structure for stocking the
>> shopping list, before dumping it in a buffer?
>>
>> FC
>>
>>
>> On Sun, Mar 16, 2014 at 1:40 AM, Robert Horn  wrote:
>>
>>> I also use tables, and have one big recipe.org file.  I considered
>>> ingredient properties, etc., but ended up just text and find recipes by
>>> using simple searches.  They look like this:
>>>
>>> * Texas Skillet Corn Bread
>>>
>>> | Ingredient | Quantity | Instructions|
>>> |+--+-|
>>> | Bacon drippings or oil | 1/4 cup  | |
>>> | Yellow CornMeal| 1 cup| |
>>> | All Purpose Flour  | 1 cup| |
>>> | Salt   | 1/2 tsp  | |
>>> | Baking Power   | 1 tsp| |
>>> | Baking Soda| 1 tsp| |
>>> | Sugar  | 1 tbs| optional|
>>> | Buttermilk | 1 cup| |
>>> | Eggs   | 2| slightly beaten |
>>> |+--+-|
>>>
>>>   1. Heat drippings in iron skillet
>>>
>>>   2. In large mixing bowl, mix cornmeal, flour, salt, baking x, and sugar.
>>>
>>>   3. Add buttermilk and stir rapidly.
>>>
>>>   4. Add eggs and mix
>>>
>>>   5. Add drippings
>>>
>>>   6. Pour into skillet, cover, and cook on low heat until lightly
>>>  browned and almost cooked through.
>>>
>>>
>>>
>>

[O] org-element checks make flyspell prohibitively slow

[Matt Lundin]

The rewrite of org-mode-flyspell-verify in commit
4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating
org-mode files with large chunks of text very slow.

For instance, I started up a minimal emacs:

/usr/bin/emacs -Q -l ~/config/minimal.el

...where minimal.el is...



minimal.el
Description: application/emacs-lisp

and (insert "\n\n=> " (emacs-version))

=> GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.7)
 of 2014-01-28 on var-lib-archbuild-extra-x86_64-juergen

and (insert "\n\n=> " (org-version nil t))

=> Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @ 
/home/matt/org-mode/lisp/)

I open a test.org file containing the following.

--8<---cut here---start->8---
* A headline
* Arch packages
* Another headline
--8<---cut here---end--->8---

After opening a line under "Arch Packages" I call...

C-u M-! pacman -Ss [RET]

(Of course, this only works with archlinux.) This inserts a long list of
packages that look like this:

--8<---cut here---start->8---
core/acl 2.2.52-2 [installed]
Access control list utilities, libraries and headers
core/archlinux-keyring 20140220-1 [installed]
Arch Linux PGP keyring
core/attr 2.4.47-1 [installed]
Extended attribute support library for ACL support
core/autoconf 2.69-1 (base-devel) [installed]
A GNU tool for automatically configuring source code
core/automake 1.14.1-1 (base-devel) [installed]
A GNU tool for automatically creating Makefiles
--8<---cut here---end--->8---
 
All in all, it's 12680 lines 

I navigate to the bottom of the file. I type... 

M-x elp-instrument-package [RET] org [RET]
M-x elp-instrument-package [RET] flyspell [RET]
M-x elp-instrument-function [RET] scroll-down-command [RET] 

Then I hit M-v three times. This takes a while.

Here are the top elp offenders:

--8<---cut here---start->8---
flyspell-post-command-hook  6   10.753828775  
1.7923047959
flyspell-word   6   10.752069764  
1.7920116273
org-mode-flyspell-verify5   8.973166134   
1.7946332267
org-element-context 5   8.364142505   
1.6728285010
org-element--get-next-object-candidates 699 8.307898326   
0.0118854053
org-element-latex-or-entity-successor   5   3.7592736849  
0.7518547369
org-element-link-successor  40  1.1079495280  
0.0276987382
org-element-sub/superscript-successor   659 1.0986591029  
0.0016671610
org-element-line-break-successor5   0.9729438699  
0.194588774
org-element-at-point5   0.607910786   
0.1215821572
org-element--parse-to   5   0.606992172   
0.1213984344
org-element--current-element10  0.4201667370  
0.0420166737
org-element-paragraph-parser10  0.416739094   
0.0416739094
org-element-inline-src-block-successor  5   0.3740871620  
0.0748174324
org-element-text-markup-successor   10  0.309006309   
0.0309006308
org-element-timestamp-successor 5   0.087275674   
0.0174551348
org-element-statistics-cookie-successor 5   0.086838821   
0.0173677642
org-element-footnote-reference-successor5   0.0866179840  
0.0173235968
org-element-target-successor5   0.086057234   
0.0172114468
org-element-radio-target-successor  5   0.083322691   
0.0166645382
org-element-export-snippet-successor5   0.083078665   
0.016615733
org-element-macro-successor 5   0.0828692849  
0.0165738569
scroll-down-command 3   0.059660938   
0.0198869793
--8<---cut here---end--->8---

Interestingly, after calling elp-results, just trying to navigate to the
org buffer with other-window takes some time. Here's the top of the new
elp list:

--8<---cut here---start->8---
flyspell-post-command-hook  1   1.780324266   
1.780324266
flyspell-word   1   1.780091208   
1.780091208
org-mode-flyspell-verify1   1.779600437   
1.779600437
org-element-context 1   1.6563819400  
1.6563819400
org-element--get-next-object-candidates 137 1.6448783359  
0.0120064112
org-element-latex-or-entity-successor   1   0.753972365   
0.753972365
org-element-link-successor  

Re: [O] Contribution: ob-groovy.el

[Miro Bezjak]

Hi all,

it took a while, but my FSF papers finally pulled through. I guess that
means ob-groovy.el can now move from `contrib' and into `lisp'.

Kind Regards,
Miro



On Mon, Dec 30, 2013 at 3:53 AM, Eric Schulte wrote:

> Miro Bezjak  writes:
>
> > Sure - attached.
> >
>
> Applied, Thanks!
>
> --
> Eric Schulte
> https://cs.unm.edu/~eschulte
> PGP: 0x614CA05D
>

Re: [O] org-cook

[Fletcher Charest]

That would be better yes, but it looked easier (to me and my limited
skills) to access properties through Emacs Lisp than accessing tables. Org
experts might have some useful tips.

FC


On Mon, Mar 17, 2014 at 3:26 PM, Xebar Saram  wrote:

> thank you all for the great answers
>
> Fletcher, your idea sounds great, but why not use  org tables as people
> suggested for ingredients. ive started using it yesterday and im very
> pleased, in example:
>
> *** COOK Pancakes:American:
>
>
> :PROPERTIES:
> :Source: TV
> :Serves:
> :Time:
> :Rating:
> :Fav:
> :END:
>
> | Quantity | scale | Ingredient| Instructions |
> |--+---+---+--|
> |8 |   | eggs  |  |
> |1 | liter | milk  |  |
> |  350 | g | butter| melted   |
> |  730 | g | flour |  |
> |   90 | g | powderd sugar |  |
> |   60 | g | baking powder |  |
> |   10 | g | salt  |  |
>
> _*Directions*:_
>
>
> best
>
> Z
>
>
> On Mon, Mar 17, 2014 at 4:22 PM, Fletcher Charest <
> fletcher.char...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> Since we are on this subject, are you aware of any package that would
>> make an 'automatic' shopping list based on recipes? My idea was to record
>> recipes in this format:
>>
>> * Name of the recipe  :tag:
>>
>> 1) Step one.
>> 2) Step two.
>> 3) Step three.
>>
>> :PROPERTIES:
>> :ingredient_1: quantity
>> :ingredient_2: quantity
>> :ingredient_3: quantity
>> :END:
>>
>> Tags could be anything, be mainly things like 'breakfast', 'main course'
>> or 'dessert'. Then, with the point on the headline, (in the file buffer or
>> in the agenda buffer), you could call a function that would add the
>> ingredient to a list, or increment its quantity if the ingredient is
>> already there. Maybe a function to add a random number of recipes (through
>> a filter or not) to the shopping list would be nice too, if you don't know
>> what to cook in a particular week.
>>
>> I'm planning to do this but my Elisp-fu is not great... Any tips of how
>> implementing this? Are lists a good data structure for stocking the
>> shopping list, before dumping it in a buffer?
>>
>> FC
>>
>>
>> On Sun, Mar 16, 2014 at 1:40 AM, Robert Horn  wrote:
>>
>>> I also use tables, and have one big recipe.org file.  I considered
>>> ingredient properties, etc., but ended up just text and find recipes by
>>> using simple searches.  They look like this:
>>>
>>> * Texas Skillet Corn Bread
>>>
>>> | Ingredient | Quantity | Instructions|
>>> |+--+-|
>>> | Bacon drippings or oil | 1/4 cup  | |
>>> | Yellow CornMeal| 1 cup| |
>>> | All Purpose Flour  | 1 cup| |
>>> | Salt   | 1/2 tsp  | |
>>> | Baking Power   | 1 tsp| |
>>> | Baking Soda| 1 tsp| |
>>> | Sugar  | 1 tbs| optional|
>>> | Buttermilk | 1 cup| |
>>> | Eggs   | 2| slightly beaten |
>>> |+--+-|
>>>
>>>   1. Heat drippings in iron skillet
>>>
>>>   2. In large mixing bowl, mix cornmeal, flour, salt, baking x, and
>>> sugar.
>>>
>>>   3. Add buttermilk and stir rapidly.
>>>
>>>   4. Add eggs and mix
>>>
>>>   5. Add drippings
>>>
>>>   6. Pour into skillet, cover, and cook on low heat until lightly
>>>  browned and almost cooked through.
>>>
>>>
>>>
>>
>

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Nicolas Goaziou]

Bastien  writes:

> Bastien  writes:
>
>> If we do this, I don't see the need to enforce case sensitivity.
>
> I attach a patch that illustrates the fix I propose on top on my
> previous commit.

I somehow missed this message.

> With this,
>
> 
> <<>>
>
> Let's say hello \alpha world to test.
> 
>
> gets converted into
>
> 
> 
> Hello α world
> 
>
> 
> Let's say hello α world to test.
> 
> 
>
> which I think is what the OP expected.  We preserve case sensitivity
> of the target, and we preserve the link description.

Indeed, downcasing value is not necessary in this case.

> (I think the confusion comes from calling "path" what is really the
> description when path and description are the same, like in a link
> to a radio target.)

path is always a string. Description is always parsed (and transcoded
already). In the most simple cases, they are equals.

> Let me know what you think,

It could work if we revert 5174495 and b4ffae0 and propagate the changes
to "ox-latex.el", "ox-beamer.el" and "ox-ascii.el". Though, there is
still a problem to consider. See below.

> diff --git a/lisp/ox-html.el b/lisp/ox-html.el
> index 4d6180d..0cacd57 100644
> --- a/lisp/ox-html.el
> +++ b/lisp/ox-html.el
> @@ -2775,9 +2775,13 @@ INFO is a plist holding contextual information.  See
>(let ((destination (org-export-resolve-radio-link link info)))
>   (when destination
> (format "%s"
> -   (org-export-data (org-element-contents destination) info)
> +   (org-export-solidify-link-text
> +(org-export-data (org-element-contents destination) info))

It should be

  (org-export-solidify-link-text (org-element-property :value destination))

See `org-html-radio-target'.

> -   (org-export-solidify-link-text path)
> +   (org-export-data
> +(org-element-parse-secondary-string
> + path
> + (org-element-restriction 'paragraph)) info)

It should be:

  (org-element-restriction 'radio-target)

Anyway, this raises a question.

5174495 adds contents to radio links (and, because of this, introduces
an infloop in `org-element-context' on master, but that's another
story). Your change parses link's contents on the fly. So this is mostly
equivalent, albeit more verbose in all exporters.

So the question is : should we consider a radio-link as a link with
a description, which would basically be its parsed path? I think it is
useful because its contents can differ from its relative radio-target,
due to case-insensitivity.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-cook

[Xebar Saram]

thank you all for the great answers

Fletcher, your idea sounds great, but why not use  org tables as people
suggested for ingredients. ive started using it yesterday and im very
pleased, in example:

*** COOK Pancakes:American:


:PROPERTIES:
:Source: TV
:Serves:
:Time:
:Rating:
:Fav:
:END:

| Quantity | scale | Ingredient| Instructions |
|--+---+---+--|
|8 |   | eggs  |  |
|1 | liter | milk  |  |
|  350 | g | butter| melted   |
|  730 | g | flour |  |
|   90 | g | powderd sugar |  |
|   60 | g | baking powder |  |
|   10 | g | salt  |  |

_*Directions*:_


best

Z


On Mon, Mar 17, 2014 at 4:22 PM, Fletcher Charest <
fletcher.char...@gmail.com> wrote:

> Hello everyone,
>
> Since we are on this subject, are you aware of any package that would make
> an 'automatic' shopping list based on recipes? My idea was to record
> recipes in this format:
>
> * Name of the recipe  :tag:
>
> 1) Step one.
> 2) Step two.
> 3) Step three.
>
> :PROPERTIES:
> :ingredient_1: quantity
> :ingredient_2: quantity
> :ingredient_3: quantity
> :END:
>
> Tags could be anything, be mainly things like 'breakfast', 'main course'
> or 'dessert'. Then, with the point on the headline, (in the file buffer or
> in the agenda buffer), you could call a function that would add the
> ingredient to a list, or increment its quantity if the ingredient is
> already there. Maybe a function to add a random number of recipes (through
> a filter or not) to the shopping list would be nice too, if you don't know
> what to cook in a particular week.
>
> I'm planning to do this but my Elisp-fu is not great... Any tips of how
> implementing this? Are lists a good data structure for stocking the
> shopping list, before dumping it in a buffer?
>
> FC
>
>
> On Sun, Mar 16, 2014 at 1:40 AM, Robert Horn  wrote:
>
>> I also use tables, and have one big recipe.org file.  I considered
>> ingredient properties, etc., but ended up just text and find recipes by
>> using simple searches.  They look like this:
>>
>> * Texas Skillet Corn Bread
>>
>> | Ingredient | Quantity | Instructions|
>> |+--+-|
>> | Bacon drippings or oil | 1/4 cup  | |
>> | Yellow CornMeal| 1 cup| |
>> | All Purpose Flour  | 1 cup| |
>> | Salt   | 1/2 tsp  | |
>> | Baking Power   | 1 tsp| |
>> | Baking Soda| 1 tsp| |
>> | Sugar  | 1 tbs| optional|
>> | Buttermilk | 1 cup| |
>> | Eggs   | 2| slightly beaten |
>> |+--+-|
>>
>>   1. Heat drippings in iron skillet
>>
>>   2. In large mixing bowl, mix cornmeal, flour, salt, baking x, and sugar.
>>
>>   3. Add buttermilk and stir rapidly.
>>
>>   4. Add eggs and mix
>>
>>   5. Add drippings
>>
>>   6. Pour into skillet, cover, and cook on low heat until lightly
>>  browned and almost cooked through.
>>
>>
>>
>

Re: [O] org-cook

[Fletcher Charest]

Hello everyone,

Since we are on this subject, are you aware of any package that would make
an 'automatic' shopping list based on recipes? My idea was to record
recipes in this format:

* Name of the recipe  :tag:

1) Step one.
2) Step two.
3) Step three.

:PROPERTIES:
:ingredient_1: quantity
:ingredient_2: quantity
:ingredient_3: quantity
:END:

Tags could be anything, be mainly things like 'breakfast', 'main course' or
'dessert'. Then, with the point on the headline, (in the file buffer or in
the agenda buffer), you could call a function that would add the ingredient
to a list, or increment its quantity if the ingredient is already there.
Maybe a function to add a random number of recipes (through a filter or
not) to the shopping list would be nice too, if you don't know what to cook
in a particular week.

I'm planning to do this but my Elisp-fu is not great... Any tips of how
implementing this? Are lists a good data structure for stocking the
shopping list, before dumping it in a buffer?

FC


On Sun, Mar 16, 2014 at 1:40 AM, Robert Horn  wrote:

> I also use tables, and have one big recipe.org file.  I considered
> ingredient properties, etc., but ended up just text and find recipes by
> using simple searches.  They look like this:
>
> * Texas Skillet Corn Bread
>
> | Ingredient | Quantity | Instructions|
> |+--+-|
> | Bacon drippings or oil | 1/4 cup  | |
> | Yellow CornMeal| 1 cup| |
> | All Purpose Flour  | 1 cup| |
> | Salt   | 1/2 tsp  | |
> | Baking Power   | 1 tsp| |
> | Baking Soda| 1 tsp| |
> | Sugar  | 1 tbs| optional|
> | Buttermilk | 1 cup| |
> | Eggs   | 2| slightly beaten |
> |+--+-|
>
>   1. Heat drippings in iron skillet
>
>   2. In large mixing bowl, mix cornmeal, flour, salt, baking x, and sugar.
>
>   3. Add buttermilk and stir rapidly.
>
>   4. Add eggs and mix
>
>   5. Add drippings
>
>   6. Pour into skillet, cover, and cook on low heat until lightly
>  browned and almost cooked through.
>
>
>

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Bastien]

Nicolas Goaziou  writes:

> I see the capitalization problem, but I still don't understand why you
> think target and description are inverted.

Well, they are.

Okay, again:


<<>>

hello world


The target of the second "hello world" is "Hello World" (capitalized).

The description of the second hello world is "hello world" (lower case.)

With the latest maint, the second "hello world" is translated as

Hello World

whereas it should be

hello world
  ^ ^  ^ ^
[target]   [description]

>yyy
>
> targets
>
>zzz
>
> In the current state (ignoring the description part), you have:
>
>   ...
>
> and
>
>   ...
>
> What do you think is wrong here?

If the radio link is "Hello World", the target should be #Hello-World.

We can decide to lower case all targets, but it is not necessary with
the fix I propose.

-- 
 Bastien

Re: [O] Is there an environment for Org syntax?

[Fletcher Charest]

Hello Phil,

When I use the edit buffer (by pressing C-c '), my Org syntax is indented
properly (in accordance with org-indent-mode, which is set to t). The code
block itself looks like this after editing:

#+BEGIN_SRC org :exports code
  ,* Top level headline
  ,** Second level
  ,*** Third level
  some text
  ,*** Third level
  more text
#+END_SRC

As you can see, the text ('some text' and 'more text') is not indented.
This is a little bit annoying, but not too much - I can add the spaces
myself.

The problem is with the HTML export: I can't see the HTML output as I would
see it in my Emacs buffer, that is to say, without the leading stars. In my
output (see attached), leading stars are visible, although not colored. I
would like them to be completely invisible.

Do you observe the same thing? My org-version is 8.2.5h-30-gdd810b-elpaplus
under GNU Emacs 24.3.1.

Thanks,

FC


On Sat, Mar 15, 2014 at 12:34 AM, Phil Regier  wrote:

> I'm not sure whether I follow you here, because I'm accustomed to seeing
> indents passed through.  If I export the following:
>
> #+begin_src org :exports code
>   ,#+begin_src org :exports code
>   indented text
>   ,#+end_src
> #+end_src
>
> ...then my HTML export adds as many spaces as there are in the block edit
> buffer.  Is that not what you see, or are you looking for something more
> sophisticated?
>
> Phil
>
> - Original Message -
> From: "Fletcher Charest" 
> To: emacs-orgmode@gnu.org
> Sent: Friday, March 14, 2014 6:21:35 PM
> Subject: Re: [O] Is there an environment for Org syntax?
>
> Thank you, this sounds interesting; I'm not very good either, but I will
> have a look at this. And I actually have a related question (I hope it's
> not in the manual this time): is it possible to indent the Org syntax in
> the HTML export as it is indented in an Emacs buffer when
> org-indent-modeis activated? The indentation in the HTML file looks
> like the one you get
> in Org by default, even if my org-indent-mode variable is set to t in my
> Org buffer.
>
> Thank you,
>
> FC
>
<>

Re: [O] Bug: Setting system command org-file-apps does not allow other settings to refer to it [8.2.5h (release_8.2.5h-620-g7fd183 @ /home/rrt/.emacs.d/el-get/package/elpa/org-20140210/)]

[Reuben Thomas]

On 17 March 2014 12:37, Bastien  wrote:

> Reuben Thomas  writes:
>
> > I don't know, because I don't know whether it's the behavior or
> > documentation that is wrong.
>
> If the behavior is wrong, what is wrong?
>
> If the documentation is wrong, what is wrong?
>

I shall assume it's a bug in the code.

0. The docstring for org-file-apps for the "system" command says:

  This command is specified by the entry whose car is
`system'.
  Most likely, the system-specific version of this variable
  does define this command, but you can overrule/replace it
  here.

1. I customize org-file-apps's system command to be "xdg-open %s", then
customize the default command to be the system command.

2. Now I try opening a file type which uses the default command.

Expected result: xdg-open should be used.

Actual result: the file is opened in Emacs (it's a PDF file, xdg-open would
open it in evince).

If I explicitly customize the default command also to be "xdg-open", then I
get the expected result.

-- 
http://rrt.sc3d.org

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> 
>> Hello World
>> 
>>
>> 
>> Let’s say Hello World to test.
>>
>> It looks good to me.
>
> The target is the radio link: "Hello World".
>
> The link description in the second paragraph is "hello world".
>
> So the output is not good:
>
> 1) Hello World should be
>Hello World
>   ^ ^
>
> 2) Hello World should be
>hello world
>  ^ ^  ^ ^
>
> See the difference with the result you get after applying
> the patch I just sent on top of d2e7b1b5.

I see the capitalization problem, but I still don't understand why you
think target and description are inverted.

   yyy

targets

   zzz

In the current state (ignoring the description part), you have:

  ...

and

  ...

What do you think is wrong here?


Regards,

-- 
Nicolas Goaziou

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Bastien]

Nicolas Goaziou  writes:

> 
> Hello World
> 
>
> 
> Let’s say Hello World to test.
>
> It looks good to me.

The target is the radio link: "Hello World".

The link description in the second paragraph is "hello world".

So the output is not good:

1) Hello World should be
   Hello World
  ^ ^

2) Hello World should be
   hello world
 ^ ^  ^ ^

See the difference with the result you get after applying
the patch I just sent on top of d2e7b1b5.

-- 
 Bastien

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Nicolas Goaziou]

Bastien  writes:

> I don't get the logic: the output text has two parts: the target of
> the link, the description of the link.  It the example above, the
> Target is "Hello World", and should be rewritten "Hello-World" to
> escape spaces.  The description is "hello world" and should not be
> rewritten, it must appears the same way to the user.

Actually, the target is "hello-world". On latest "maint", with your
example, I get:

--8<---cut here---start->8---

Hello World



Let’s say Hello World to test.
--8<---cut here---end--->8---

It looks good to me.

>> Anyway, I think the solution is to slightly change the parser to enforce
>> case-insensitivity.
>
> I thought about this, but it does not solve the problem of displaying
> the target instead of the link description.

I cannot reproduce this problem.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Setting system command org-file-apps does not allow other settings to refer to it [8.2.5h (release_8.2.5h-620-g7fd183 @ /home/rrt/.emacs.d/el-get/package/elpa/org-20140210/)]

[Bastien]

Reuben Thomas  writes:

> I don't know, because I don't know whether it's the behavior or
> documentation that is wrong.

If the behavior is wrong, what is wrong?

If the documentation is wrong, what is wrong?

Sorry to be plain, but you need to help me :)

-- 
 Bastien

Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)

[Simon Thum]

Hehe ;) No, I was merely suggesting that maybe someone tried too hard to 
fix non-working urls becauase of other use cases.


Luckily it seems fixed now.


On 03/06/2014 10:17 AM, Andreas Leha wrote:

"R. Michael Weylandt"  writes:


On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum  wrote:

This seems to be a question of objective. Do you want to encode, i.e.
maintain some reversible original in an url no matter what, or do you want
to fix url's which wouldn't otherwise be legal? In the latter case, the
question mark should probably be retained.



I am not sure, that I understand what you say here.  But in case you
want to convince me, that exporting non-working links when the user
supplies working links is a feature and not a bug, you will have a hard
time ;-)

- Andreas



I believe the former. If the user types in a working link, the
exporter shouldn't break it.

This could be fixed by sprinkling org-url-decode through various
backends, but that suggests to me that the problem may be "upstream."

Michael

Re: [O] Bug: Setting system command org-file-apps does not allow other settings to refer to it [8.2.5h (release_8.2.5h-620-g7fd183 @ /home/rrt/.emacs.d/el-get/package/elpa/org-20140210/)]

[Reuben Thomas]

On 17 March 2014 02:11, Bastien  wrote:

> Hi Reuben,
>
> I'm confused and can't get what's the problem: is it a bug?
> Is it a documentation bug?


I don't know, because I don't know whether it's the behavior or
documentation that is wrong.

-- 
http://rrt.sc3d.org

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Bastien]

Bastien  writes:

> If we do this, I don't see the need to enforce case sensitivity.

I attach a patch that illustrates the fix I propose on top on my
previous commit.

With this,


<<>>

Let's say hello \alpha world to test.


gets converted into



Hello α world



Let's say hello α world to test.



which I think is what the OP expected.  We preserve case sensitivity
of the target, and we preserve the link description.

(I think the confusion comes from calling "path" what is really the
description when path and description are the same, like in a link
to a radio target.)

Let me know what you think,

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 4d6180d..0cacd57 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2775,9 +2775,13 @@ INFO is a plist holding contextual information.  See
   (let ((destination (org-export-resolve-radio-link link info)))
 	(when destination
 	  (format "%s"
-		  (org-export-data (org-element-contents destination) info)
+		  (org-export-solidify-link-text
+		   (org-export-data (org-element-contents destination) info))
 		  attributes
-		  (org-export-solidify-link-text path)
+		  (org-export-data
+		   (org-element-parse-secondary-string
+		path
+		(org-element-restriction 'paragraph)) info)
  ;; Links pointing to a headline: Find destination and build
  ;; appropriate referencing command.
  ((member type '("custom-id" "fuzzy" "id"))

-- 
 Bastien

[O] non-beamer :ignoreheading: does not work for html (org 8.2.5h)

[Miguel Ruiz]

Hi

The Suvayu edited answer of Jul 26 '13 at 11:42

http://stackoverflow.com/questions/10295177/is-there-an-equivalent-of-org-modes-b-ignoreheading-for-non-beamer-documents

#+begin_src elisp

(require 'ox)

(defun sa-ignore-headline (contents backend info)
  "Ignore headlines with tag `ignoreheading'."
  (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
  (string-match "\\`.*ignoreheading.*\n"
(downcase contents)))
(replace-match "" nil nil contents)))

(add-to-list 'org-export-filter-headline-functions 'sa-ignore-headline)

#+end_src elisp

for me, works for latex and ascii backends but not for html.

Can anyone reproduce it?  Any hints?

TIA

Emacs 24.3, orgmode 8.2.5h-61-g39cfc3


FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Bastien]

Hi Nicolas,

thanks for looking into this.

Nicolas Goaziou  writes:

> Actually, even though it works if you test it on cases like:
>
>   <<>> foo
>
> it isn't right on more complex cases:
>
>   <<>>  with \alpha

True.

It is not right on simpler example too, with just spaces:


<<>>

Let's say hello world to test.


It produces



Hello World



Let's say hello-world to test.



> As you can see, the logic is right in ox-latex.el, ox-html.el and
> ox-beamer.el.

I don't get the logic: the output text has two parts: the target of
the link, the description of the link.  It the example above, the
Target is "Hello World", and should be rewritten "Hello-World" to
escape spaces.  The description is "hello world" and should not be
rewritten, it must appears the same way to the user.

> Anyway, I think the solution is to slightly change the parser to enforce
> case-insensitivity.

I thought about this, but it does not solve the problem of displaying
the target instead of the link description.

> Some additional properties need to be added in order
> to preserve original contents of both radio links and radio targets.
>
> I pushed such a change. Is it working as expected?

Not for me: when "a word" is linked to a radio target, I expect to see
"a word" in the output, linked to a #a-word id.  When "another word"
is linked to "Another Word", I expect to see "another word" in the
output, linking to an anchor #Another-Word.

If we do this, I don't see the need to enforce case sensitivity.

-- 
 Bastien

Re: [O] Radio targets with mixed capitalisation do not work in HTML export

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Nicolas, I modified the logic for radio link export in ox-html.el,
> ox-latex.el and ox-beamer.el.  I also modified the use of the target
> instead of the path in ox-ascii.el.  Can you review this change
> (http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=d2e7b1b) and
> confirm it does the right thing?

Actually, even though it works if you test it on cases like:

  <<>> foo

it isn't right on more complex cases:

  <<>>  with \alpha

As you can see, the logic is right in ox-latex.el, ox-html.el and
ox-beamer.el.

Anyway, I think the solution is to slightly change the parser to enforce
case-insensitivity. Some additional properties need to be added in order
to preserve original contents of both radio links and radio targets.

I pushed such a change. Is it working as expected?


Regards,

-- 
Nicolas Goaziou

Re: [O] calendar day face incorrect when Monday first day?

[David Belohrad]

Ok, I then send a copy of this email to emacs guys


Bastien  writes:

> Hi David,
>
> David Belohrad  writes:
>
>> Is the hard-wired face for weekend days intentional? I would propose to
>> declare those days in an external variable so user could actually choose
>> what he considers as weekend...
>
> I don't know if it is intentional but I observe the same.
>
>> any comments on this? eventually proposals to who to send this email to
>> propose this functionality?
>
> Your best chance is to send an Emacs bug report with
>
> M-x report-emacs-bug RET
>
> Best,
>
> -- 
>  Bastien

Re: [O] calendar day face incorrect when Monday first day?

[Bastien]

Hi David,

David Belohrad  writes:

> Is the hard-wired face for weekend days intentional? I would propose to
> declare those days in an external variable so user could actually choose
> what he considers as weekend...

I don't know if it is intentional but I observe the same.

> any comments on this? eventually proposals to who to send this email to
> propose this functionality?

Your best chance is to send an Emacs bug report with

M-x report-emacs-bug RET

Best,

-- 
 Bastien

Re: [O] [OT] document scanner with ADF

[Andreas Hirczy]

Hi!

Samuel Wales  writes:

> We had a great discussion about scanners and ADFs here a while back.
> The Fujitsu ScanSnap 1500 seemed to be a favorite.

We have got Fujitsu ScanSnap S1500M and FI-6130Z - both work near
perfect with Linux and SANE.

If you use SANE, it is necessary to set the driver to ADF first and set
the other parameters (eg. page size) later. This is different from the
epson driver for example - and not done by all frontends.

> We also talked about what resolutions to scan at.

I usually scan at 600 dpi and convert to 300 dpi afterwards.

> What's the current status of document scanners for Linux?  How good
> are the ADFs physically?

I also have an older Epson Perfection 1640SU scanner with ADF - the
driver support on Linux is ok, but mechanically the Fujitsu is much
faster and more robust. We also have a "Canon imageRunner ADVANCE 5235"
which works great as an ADF scanner, but is in a somewhat different
range :)


My script for a quick scan:
---
#!/bin/sh

# where to store scanned images
TEMPDIR=$(mktemp -d /tmp/scanadf.X)

SOURCE="ADF Front"  # possible options: ADF Front|ADF Back|ADF Duplex [ADF 
Front]
SCANMODE=Gray   # possible options: Lineart|Halftone|Gray|Color [Lineart]
RESOLUTION=600  # possible options: 50..600dpi
SOURCE="ADF Duplex"

TITLE="$(date -I)_$1"

echo "Scanner input source : $SOURCE"
echo "Chosen title for document: $TITLE"

scanadf --verbose --source "$SOURCE" --mode $SCANMODE  --page-height=297 -l 0 
-t 0 -x 210 -y 297 \
--resolution $RESOLUTION --no-overwrite --output-file 
${TEMPDIR}/image-%04d.pnm 

for file in ${TEMPDIR}/image-*.pnm; do 
convert ${file} -resize 50% -depth 4 -normalize "${file%.pnm}.png"
#  -linear-stretch 2x2%
done

didjvu bundle --clean --lossy --output "$TITLE.djvu" $TEMPDIR/*.png
ocrodjvu --in-place --engine tesseract "$TITLE.djvu"
djview4 "$TITLE.djvu" &

rm -rf $TEMPDIR
---

Best regards
Andreas
-- 
Andreas Hirczyhttp://itp.tugraz.at/~ahi/
Graz University of Technologyphone: +43/316/873-   8190
Institute of Theoretical and Computational Physics fax: +43/316/873-10 8190
Petersgasse 16, A-8010 Graz mobile: +43/664/859 23 57

Re: [O] org-agenda-do-date-late and emacs freeze

[Igor Sosa Mayor]

Am Mon, Mar 17, 2014 at 03:07:08AM +0100, Bastien schrieb:
> Yes -- and I recently removed the fix I sent to Michael about S-RET
> not aligning properly in table because of this ping pong.  I'll
> revisit this thoroughly and hopefully come up with a stable solution,
> but the problems here are closely tangled together.

thnaks!

-- 
:: Igor Sosa Mayor :: joseleopoldo1...@gmail.com ::
:: GnuPG: 0x1C1E2890   :: http://www.gnupg.org/  ::
:: jabberid: rogorido  ::::

[O] calendar day face incorrect when Monday first day?

[David Belohrad]

Dear All,
this might be out for this group, but maybe there will be some help, as
calendar is used extensively in org mode.

In Czech Rep, the week starts always by monday, so I do

(setq calendar-week-start-day 1)

This perfectly sets the monday in the calendar view (so M-x calendar) as
first day of the week. Trouble is, that in the header it still uses face
'as if it was a weekend day'. So I've been browsing through the code to
see how to repair it, and to my surprise I did not find any way how to
do it. So I dug into the code more and I've found this piece of code in
calendar.el (emacs 24git):

(dotimes (i 7)
 (insert
  (truncate-string-to-width
   (propertize (calendar-day-name (mod (+ calendar-week-start-day i) 7)
  'header t)
   'font-lock-face (if (memq i '(0 6))
   'calendar-weekend-header
 'calendar-weekday-header))
   calendar-day-header-width nil ?\s)
  (make-string (- calendar-column-width calendar-day-header-width)
 ?\s)))


hidden in calendar-generate-month. Now it seems, that font-lock-face is
assigned to weekend header *only* for first and last day of week, which
for Czech Rep. is not really correct, as correct should be (imho)
saturday/sunday, which would mean, that the (memq... should be:

(memq i '(5 6))

Is the hard-wired face for weekend days intentional? I would propose to
declare those days in an external variable so user could actually choose
what he considers as weekend...


any comments on this? eventually proposals to who to send this email to
propose this functionality?

NB: I've checked with (memq i '(5 6)) and it works correctly.


Cheers

.d.

Re: [O] [patch] capture property table-line-pos can be a function

[Thomas Holst]

Hi Bastien,

· Bastien  wrote:
> Thomas Holst  writes:
>
>> Given a table with several sections and a capture template for entries
>> in this table. The sections are dynamic, so a static value for
>> table-line-pos does not help. With this patch table-line-pos can be:
>>
>> - a string like "II-2"
>> - a varialbe containing a string
>> - or a function
>>   The function has to return a string which qualifies for table-line-pos
>>
>> This serves me well and I am using it for more than one year now.
>
> This sounds useful.  Could you also provide a patch for the
> documentation?
>
> Thanks in advance!

thanks for looking into this. I will try to provide a patch for the
documentation in the next days.

-- 
Bis neulich ...
  Thomas

Re: [O] [patch] file links from sunrise commander

[Thomas Holst]

Hi Bastien,
· Bastien  wrote:
> Thomas Holst  writes:
>
>> Here is a path with implements this feature.
>
> I used a slightly different technique to avoid the reference to
> `sr-mode'.
>
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=5f2dce
>
> Thanks for the idea,

thanks for implementing this feature. Your way of implementing it is
more general. I am constantly learning lisp reading this list and trying
to contribute.

-- 
Bis neulich ...
  Thomas