Re: [O] Bug: Bulk reschedule with reschedule logging on fails [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /home/tyria/.emacs.d/elpa/org-plus-contrib-20160229/)]

[Allen Li]

Nicolas Goaziou  writes:
>
> This raises another question, though. What is a reasonable behaviour for
> bulk schedule+log?

I can think of three reasonable options:

1. Prompt for a note, then apply it to all affected items.
2. Prompt for a note, then apply it only to items that are already
   scheduled (and hence rescheduled).
3. Don't attempt to add a note and just add timestamps.

Then there's the unreasonable option:

4. Prompt for a note for each item.

If I had to pick, I'd go with 2, but any of 1-3 is fine.  In this case,
having bulk scheduling work is more important than whether
org-log-reschedule is being faithfully applied, in my opinion.

Allen


signature.asc
Description: PGP signature

[O] Displaying property values in agenda search result

[Markus Heller]

Hello,

how can I display property values in the agenda, more specifically, in 
the results of an agenda search?

Consider the following example:

* Some Project
:PROPERTIES:
:Project:  1234
:END:
** TODO Some Task
:PROPERTIES:
:CATEGORY: foo
:END:
*** NEXT Some subtask

I search using the following in my .emacs as part of a custom agenda 
command:

  ("i" "Text here" tags "CATEGORY=\"foo\""
   ((org-agenda-overriding-header "Header here")))

This search displays Some Task and Some subtask as expected, but how can 
I also display 1234 as value of the property Project for both Some Task 
as well as Some subtask?

Not sure if this is relevant, but my .emacs includes

(setq org-use-property-inheritance (quote ("Project")))

Thanks
Markus

Re: [O] [PATCH] call_*() is not working inside #+DATE

[Nicolas Goaziou]

Hello,

Rafael Laboissiere  writes:

> * Rafael Laboissiere  [2016-03-12 08:57]:
>>
>> [snip]
>>
>> I investigated this issue further and discovered that the constructs
>> call_(args) and src_{code} are not evaluated at all when
>> they appear in a keyword line (starting with "#+:").
>> Org-babel behaves in this way probably on purpose.  At any rate, it
>> would be better if the current behavior is documented somewhere.
>> This may be accomplished with the patch attached below.
>
> I went ahead and committed the patch.

I think this is a bit premature, as we're still discussing how to fix
this issue, so this documentation patch is likely to be removed soon.

Moreover, I don't think the problem doesn't appear on maint branch,
where you applied your patch. So, at the very least, it should be
removed from there.


Regards,

-- 
Nicolas Goaziou

Re: [O] PATCH: programming language indicators in HTML export

[Robert Klein]

Hi Rasmus,

Rasmus  wrote:

> Hi Robert,
> 
> Thanks for the patch.
> 
> Robert Klein  writes:
> 
> > any thoughts about this?
> 
> Remind me, would this only show up when hovering above the block with
> the mouse when using this setup?

Yes.

> 
> The patch would make the default html header a bit longer, which may
> or may not be an issue.  Perhaps more importantly, it also does not
> deal with new languages.  Maybe it would be possible to add a bit of
> JS that would look up the language based on the class of the block in
> question?
> 
> E.g. the block
> 
>  #+BEGIN_SRC rsgrs
> 
>  #+END_SRC
> 
> would have class "src-rsgrs".

This happens already, but the JS would also have to create the
corresponding CSS code (that's what I hardcoded in the patch).

However you'd still need a mapping from src block identifier to
pleasantly readable text, e.g. js -> "Javascript", sql -> "SQL",
emacs-lisp -> "Emacs Lisp", ps -> "PostScript" etc.  When you have all
those it's not that much different from static CSS anymore...

There's no perfect solution, unfortunately, but src blocks have a lot
of limits for each language:
- is there an Emacs mode for editing?
- is there org-babel code for executing?
- is the language supported by the LaTeX listings package?
- or by the pygments library (for the LaTeX minted package)?


Anyway, my patch is basically for those who don't roll their own CSS to
have things mostly working out of the box. 


Best regards
Robert


> 
> Thanks,
> Rasmus
> 

Re: [O] org-collector - propview display problems

[Charles Millar]

Nicolas,

On 03/14/2016 08:36 AM, Nicolas Goaziou wrote:

Hello,

dche  writes:


I have just done the test and I have the following ouptut

#+BEGIN: propview :id "december" :conds ((string= SPENDTYPE "food")) :cols
(ITEM AMOUNT)
| ITEM   | AMOUNT |
|+|
| " Grocery Store [2008-12-01 lun.]" |  56.77 |
| " Restaurant [2008-12-08 lun.]"|  30.67 |
|+|
|||
#+END:

Which is nearly the same as the example provides :

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols
(ITEM amount)
| "ITEM"   | "amount" |
|--+--|
| "Grocery Store [2008-12-01 Mon]" |56.77 |
| "Restaurant [2008-12-08 Mon]"|30.67 |
|--+--|
|  |  |
#+END:


I don't know if it is possible to get rid of the stars for the ITEM
entries.

This is already the case in the development version.

Regards,


Please let me know what I am missing or if I am just plain nuts.

I copied the org-collector example into my scratchorg file. Before 
executing he first propview block, I killed the following entry


 Grocery Store [2008-12-01 Mon]
 :PROPERTIES:
 :amount: 56.77
 :spendtype: food
 :END:

I made sure that spendtype and amount in all other entries and in the 
propview blocks were upper cased.

I made sure that the first propview block had no results so it was just

#+BEGIN: propview :id "december" :conds ((string= SPENDTYPE "food")) 
:cols (ITEM AMOUNT)

#+END:

When executed (C-c C-c) the result still was

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols 
(ITEM amount)
| "ITEM"   | "amount" |
|--+--|
| "Grocery Store [2008-12-01 Mon]" |56.77 | - how possible if there is no 
entry??
| "Restaurant [2008-12-08 Mon]"|30.67 |
|--+--|
|  |  |
#+END:

In the example is :id somehow "hardwired" into the expected results. 
Please note that I also entered, not copied,  the first propview block 
(without the results) character by character into the buffer, executed 
and the Grocery Store still showed up!


If I upper case ID, I get the expected results

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols 
(ITEM amount)
| "ITEM"   | "amount" |
|--+--|
| "Restaurant [2008-12-08 Mon]"|30.67 |
|--+--|
|  |  |
#+END:

Should all options be upper cased as well? Or what should I read as to 
:id properties?


Charlie Millar

Re: [O] [PATCH] call_*() is not working inside #+DATE

[Rafael Laboissiere]

* Rafael Laboissiere  [2016-03-12 08:57]:


[snip]

I investigated this issue further and discovered that the constructs 
call_(args) and src_{code} are not evaluated at all when 
they appear in a keyword line (starting with "#+:"). 
Org-babel behaves in this way probably on purpose.  At any rate, it 
would be better if the current behavior is documented somewhere.  This 
may be accomplished with the patch attached below.


I went ahead and committed the patch.

Rafael Laboissière

Re: [O] PATCH: programming language indicators in HTML export

[Rasmus]

Hi Robert,

Thanks for the patch.

Robert Klein  writes:

> any thoughts about this?

Remind me, would this only show up when hovering above the block with the
mouse when using this setup?

The patch would make the default html header a bit longer, which may or
may not be an issue.  Perhaps more importantly, it also does not deal with
new languages.  Maybe it would be possible to add a bit of JS that would
look up the language based on the class of the block in question?

E.g. the block

 #+BEGIN_SRC rsgrs

 #+END_SRC

would have class "src-rsgrs".

Thanks,
Rasmus

-- 
Nothing's wrong with an email that ends in a minor key

Re: [O] org-collector - propview display problems

[Charles Millar]

Nicolas,

On 03/14/2016 08:36 AM, Nicolas Goaziou wrote:

Hello,

dche  writes:


I have just done the test and I have the following ouptut

#+BEGIN: propview :id "december" :conds ((string= SPENDTYPE "food")) :cols
(ITEM AMOUNT)
| ITEM   | AMOUNT |
|+|
| " Grocery Store [2008-12-01 lun.]" |  56.77 |
| " Restaurant [2008-12-08 lun.]"|  30.67 |
|+|
|||
#+END:

Which is nearly the same as the example provides :

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols
(ITEM amount)
| "ITEM"   | "amount" |
|--+--|
| "Grocery Store [2008-12-01 Mon]" |56.77 |
| "Restaurant [2008-12-08 Mon]"|30.67 |
|--+--|
|  |  |
#+END:


I don't know if it is possible to get rid of the stars for the ITEM
entries.

This is already the case in the development version.

Regards,

Thank you for clarifying this. I just tried the example file again 
(after changing all properties to upper-case) and it now works as 
expected. (BTW I am using Org-mode version 8.3.4 
(release_8.3.4-655-g9fb077 @ 
/usr/local/share/emacs/site-lisp/org-mode/lisp/)


Charlie Millar

[O] PATCH: programming language indicators in HTML export

[Robert Klein]

Hi,

any thoughts about this?

Best regards
Robert


Author: Robert Klein   2016-03-14 14:43:46
Committer: Robert Klein   2016-03-14 14:43:46
Parent: dd9be3a6ea4ff561248b1f6658194fd153b5821c (Fix docstring typo)
Branch: maint
Follows: release_8.3.4
Precedes:

support more programming languages in CSS

The standard CSS for HTML export only supported a couple of
programming languages to have a language name "hover" on src
blocks.  This patch adds all languages supported per Org
manual, those from org.el's org-babel-load-languages-alist,
additional language identifiers in ob-*.el and languages
which have a) an emacs mode and b) are supported by the LaTeX
listings package.  Additional a language "conf" is supported
for generic configuraiton files; an emacs mode exists for
this, but for LaTeX listings a language " " has to be faked.
As this patch is for HTML, this is no impediment.

Thanks for reporting the missing support to Tianxian XIONG.

--- lisp/ox-html.el
--- index de2e5d9..e4a4c38 100644
@@ -314,13 +314,96 @@ for the JavaScript code in this tag.
 border: 1px solid black;
   }
   pre.src:hover:before { display: inline;}
-  pre.src-sh:before{ content: 'sh'; }
-  pre.src-bash:before  { content: 'sh'; }
+  /* Languages per Org manual */
+  pre.src-asymptote:before { content: 'Asymptote'; }
+  pre.src-awk:before { content: 'Awk'; }
+  pre.src-C:before { content: 'C'; }
+  /* pre.src-C++ doesn't work in CSS */
+  pre.src-clojure:before { content: 'Clojure'; }
+  pre.src-css:before { content: 'CSS'; }
+  pre.src-D:before { content: 'D'; }
+  pre.src-ditaa:before { content: 'ditaa'; }
+  pre.src-dot:before { content: 'Graphviz'; }
+  pre.src-calc:before { content: 'Emacs Calc'; }
   pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
-  pre.src-R:before { content: 'R'; }
-  pre.src-perl:before  { content: 'Perl'; }
-  pre.src-java:before  { content: 'Java'; }
-  pre.src-sql:before   { content: 'SQL'; }
+  pre.src-fortran:before { content: 'Fortran'; }
+  pre.src-gnuplot:before { content: 'gnuplot'; }
+  pre.src-haskell:before { content: 'Haskell'; }
+  pre.src-java:before { content: 'Java'; }
+  pre.src-js:before { content: 'Javascript'; }
+  pre.src-latex:before { content: 'LaTeX'; }
+  pre.src-ledger:before { content: 'Ledger'; }
+  pre.src-lisp:before { content: 'Lisp'; }
+  pre.src-lilypond:before { content: 'Lilypond'; }
+  pre.src-matlab:before { content: 'MATLAB'; }
+  pre.src-mscgen:before { content: 'Mscgen'; }
+  pre.src-ocaml:before { content: 'Objective Caml'; }
+  pre.src-octave:before { content: 'Octave'; }
+  pre.src-org:before { content: 'Org mode'; }
+  pre.src-oz:before { content: 'OZ'; }
+  pre.src-plantuml:before { content: 'Plantuml'; }
+  pre.src-processing:before { content: 'Processing.js'; }
+  pre.src-python:before { content: 'Python'; }
+  pre.src-R:before { content: 'R'; }
+  pre.src-ruby:before { content: 'Ruby'; }
+  pre.src-sass:before { content: 'Sass'; }
+  pre.src-scheme:before { content: 'Scheme'; }
+  pre.src-screen:before { content: 'Gnu Screen'; }
+  pre.src-sed:before { content: 'Sed'; }
+  pre.src-sh:before { content: 'shell'; }
+  pre.src-sql:before { content: 'SQL'; }
+  pre.src-sqlite:before { content: 'SQLite'; }
+  /* additional languages in org.el's org-babel-load-languages alist */
+  pre.src-forth:before { content: 'Forth'; }
+  pre.src-io:before { content: 'IO'; }
+  pre.src-J:before { content: 'J'; }
+  pre.src-makefile:before { content: 'Makefile'; }
+  pre.src-maxima:before { content: 'Maxima'; }
+  pre.src-perl:before { content: 'Perl'; }
+  pre.src-picolisp:before { content: 'Pico Lisp'; }
+  pre.src-scala:before { content: 'Scala'; }
+  pre.src-shell:before { content: 'Shell Script'; }
+  pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
+  /* additional language identifiers per \"defun org-babel-execute\"
+   in ob-*.el */
+  pre.src-cpp:before  { content: 'C++'; }
+  pre.src-abc:before  { content: 'ABC'; }
+  pre.src-coq:before  { content: 'Coq'; }
+  pre.src-groovy:before  { content: 'Groovy'; }
+  /* additional language identifiers from org-babel-shell-names in
+ ob-shell.el: ob-shell is the only babel language using a lambda
to put
+ the execution function name together. */
+  pre.src-bash:before  { content: 'bash'; }
+  pre.src-csh:before  { content: 'csh'; }
+  pre.src-ash:before  { content: 'ash'; }
+  pre.src-dash:before  { content: 'dash'; }
+  pre.src-ksh:before  { content: 'ksh'; }
+  pre.src-mksh:before  { content: 'mksh'; }
+  pre.src-posh:before  { content: 'posh'; }
+  /* Additional Emacs modes also supported by the LaTeX listings
package */
+  pre.src-ada:before { content: 'Ada'; }
+  pre.src-asm:before { content: 'Assembler'; }
+  pre.src-caml:before { content: 'Caml'; }
+  pre.src-delphi:before { content: 'Delphi'; }
+  pre.src-html:before { content: 'HTML'; }
+  pre.src-idl:before { content: 'IDL'; }
+  pre.src-mer

Re: [O] org-collector - propview display problems

[Nicolas Goaziou]

Hello,

dche  writes:

> I have just done the test and I have the following ouptut 
>
> #+BEGIN: propview :id "december" :conds ((string= SPENDTYPE "food")) :cols 
> (ITEM AMOUNT)
> | ITEM   | AMOUNT |
> |+|
> | " Grocery Store [2008-12-01 lun.]" |  56.77 |
> | " Restaurant [2008-12-08 lun.]"|  30.67 |
> |+|
> |||
> #+END:
>
> Which is nearly the same as the example provides :
>
> #+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols
> (ITEM amount)
> | "ITEM"   | "amount" |
> |--+--|
> | "Grocery Store [2008-12-01 Mon]" |56.77 |
> | "Restaurant [2008-12-08 Mon]"|30.67 |
> |--+--|
> |  |  |
> #+END:
>
>
> I don't know if it is possible to get rid of the stars for the ITEM 
> entries.

This is already the case in the development version.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: incorrect export for LaTeX [8.2.10 (release_8.2.10 @ c:/emacs25-91/share/emacs/25.0.91/lisp/org/)]

[9661031]

I'm sorry that I respond so late.

My idea is that as org-mode exports a plain text,org-mode assigns the
number to items having eight or more *s,
and the title starts from the number of the 8th depth.

So,I expect the exported .tex file is like that:
...
\section{one}
\label{sec-1}
\subsection{two}
\label{sec-1-1}
\subsubsection{three}
\label{sec-1-1-1}
\begin{enumerate}
\item four
\label{sec-1-1-1-1}
\begin{enumerate}
\item five
\label{sec-1-1-1-1-1}
\begin{enumerate}
\item six
\label{sec-1-1-1-1-1-1}
\begin{enumerate}
\item seven
\label{sec-1-1-1-1-1-1-1}

1. eight
  \label{sec-1-1-1-1-1-1-1-1}

  1.1 nine
  \label{sec-1-1-1-1-1-1-1-1-1}


\end{enumerate}
\end{enumerate}
\end{enumerate}
\end{enumerate}
...
Also,org-mode should export tex command to indent.

Sincerely,

2016-03-01 6:16 GMT+09:00 Nicolas Goaziou :
> Hello,
>
> 9661031 <9661...@gmail.com> writes:
>
>> When you use a headline which is more than 7th level,the exported LaTeX file
>> raises an error in typesetting. Here is an example (org file):
>>
>> ===
>> * one
>> ** two
>> *** three
>>  four
>> * five
>> ** six
>> *** seven
>>  eight
>> ===
>>
>> This happens because nesting of enumerate environment in LaTeX is limited.
>> I think the program should export an LaTeX file that successfully makes
>> a PDF file even though the solution is dirty.
>
> Fair enough. Do you have a proposal for deeply nested headlines (or
> items)?
>
> Regards,
>
> --
> Nicolas Goaziou



-- 
Candlejackああ、あれは昔のアニメに出てくる・・・
おっと、宅配便かな、誰かが来たようだ

[O] SOLVED (was: temporary org-capture-templates)

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer  writes:

   > Hi

   > I would like to one entry for the org-capture-templates
   > which will prompt for the file I want to save the capture.

   > So I tried 

   > (setq org-capture-templates
   > '(
   > ("G" "Generic" table-line (file+headline (read-string "Name of file: " 
"Generic")
   > "|%f| %U|%A|" :prepend t

My bad forgot )

So this works nicely
 (setq org-capture-templates
 '(
("G" "Generic" table-line (file+headline (expand-file-name (read-string "Name 
of file: ")) "Generic")
 "|%f| %U|%A|" :prepend t))

[O] temporary org-capture-templates

[Uwe Brauer]

Hi

I would like to one entry for the org-capture-templates
which will prompt for the file I want to save the capture.

So I tried 

(setq org-capture-templates
'(
("G" "Generic" table-line (file+headline (read-string "Name of file: " 
"Generic")
"|%f| %U|%A|" :prepend t

But it does not work.

Any suggestions?

Thanks

Uwe Brauer 

Re: [O] using vref in latex export, and normal links in html export

[Alan Schmitt]

On 2016-03-12 22:36, John Kitchin  writes:

> I guess these are defined in backends, e.g. org-latex-link.

Ah, yes, thanks a lot. Unfortunately this approach does not work because
org-add-link-type uses a function whose argument do not contain enough
information to call the backend functions (for instance the first
argument is a string in org-add-link-type, and it's an org link in the
backend functions).

I went back to the macro approach, and with the addition of
org-latex-prefer-user-labels it works great.

Thanks again,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂ (2016-02, Mauna Loa Obs.): 404.02


signature.asc
Description: PGP signature

Re: [O] using vref in latex export, and normal links in html export

[Alan Schmitt]

On 2016-03-12 09:44, Stefan Nobis  writes:

> Alan Schmitt  writes:
>
>> I'm converting a latex document into org-mode to easily export it both
>> to latex and html. I've just encountered something that I don't know how
>> to do: export a \vref reference. I would like to have something that
>> exports to \vref in latex, and to a normal link in html.
>
> I solve this with the help of an export filter:
>
> (defun sn/ox-latex-filter-varioref (text backend info)
>   (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "ref{" "vref{" text)))
> 
> (eval-after-load "ox-latex"
>   '(progn
>  (add-to-list 'org-export-filter-link-functions 
> 'sn/ox-latex-filter-varioref)))

Thank you for the suggestion, but this would convert every link in a
vref link. What I want to do is to be able to handle some links as vref.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂ (2016-02, Mauna Loa Obs.): 404.02


signature.asc
Description: PGP signature

Re: [O] org-collector - propview display problems

[dche]

Thank you.

I have just done the test and I have the following ouptut 


#+BEGIN: propview :id "december" :conds ((string= SPENDTYPE "food")) :cols 
(ITEM AMOUNT)
| ITEM   | AMOUNT |
|+|
| " Grocery Store [2008-12-01 lun.]" |  56.77 |
| " Restaurant [2008-12-08 lun.]"|  30.67 |
|+|
|||
#+END:


Which is nearly the same as the example provides :

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols
(ITEM amount)
| "ITEM"   | "amount" |
|--+--|
| "Grocery Store [2008-12-01 Mon]" |56.77 |
| "Restaurant [2008-12-08 Mon]"|30.67 |
|--+--|
|  |  |
#+END:


I don't know if it is possible to get rid of the stars for the ITEM 
entries. 
Thank you again. I will use org-collector again.

Regards

Re: [O] set default width for figure floats?

[Rainer M Krug]

John Kitchin  writes:

> Rainer M Krug writes:
>
>> John Kitchin  writes:
>>
>>> Maybe you want org-image-actual-width
>>>
>>> This sets teh width in org, if you have a working imagemagick.
>>
>> No - I don't want any scaling. They are graphs I have created in R and I
>> want to conserve the font sizes in the paper.
> This is only scaling in the org buffer. I find high resolution (high
> dpi) are often too large in my emacs, so I set this to be something like
> 300 to 600 to keep the figures reasonably sized in the buffer. It has no
> effect on the LaTeX export.

OK - I'll keep it in ind when I view the images in org.

Thanks,

Rainer
>
>>
>>>
>>> org-latex-image-default-width contains the default latex scaling.
>>> Probably you can set this to nil to avoid scaling.
>>
>> Setting it to "" works perfectly. I have now set:
>>
>> --8<---cut here---start->8---
>> #+BIND: org-latex-image-default-width ""
>> --8<---cut here---end--->8---
>>
>> as well as
>>
>> --8<---cut here---start->8---
>> # Local Variables:
>> # eval: (visual-line-mode 1)
>> # org-latex-image-default-width: ""
>> # End:
>> --8<---cut here---end--->8---
>>
>> I don't know if one is sufficient - I just leave them in and might try
>> later.
>>
>> Thanks a lot,
>>
>> Rainer
>>
>>>
>>>
>>> Rainer M Krug writes:
>>>
 I think this has been asked before, but I can't find it:

 Is there a way of setting the default width for images included as

 [[file:map-All.png]]

 in org documents? It seems that the default is

 \includegraphics[width=.9\linewidth]{map-All.png}

 and I don't want the images to be scaled, but to let them keep their own
 size.

 Is this possible (I'd like to avoid having to use #+ATTR_LATEX :width
 before each - and even then I would have no idea to unset the value)

 Thanks,

 Rainer
>>>
>>>
>>> --
>>> Professor John Kitchin
>>> Doherty Hall A207F
>>> Department of Chemical Engineering
>>> Carnegie Mellon University
>>> Pittsburgh, PA 15213
>>> 412-268-7803
>>> @johnkitchin
>>> http://kitchingroup.cheme.cmu.edu
>
>
> --
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature