Re: [O] Using link abbrevations for EXPORT_FILE_NAME ?

[Stelian Iancu]

On 08/11/15 20:11, Nicolas Goaziou wrote:

Hello,

AW  writes:


on orgmode 8.3.2 I've got a large org-file. Offen, I need to export a subtree
like this:

-
* Subtree to be exported
:PROPERTIES:
:EXPORT_FILE_NAME: /PATH/TO/FOLDER/filename
:EXPORT_TITLE:
:END:

foo

-

I'd like to save the exported file in a project folder, as you can see in
EXPORT_FILE_NAME .

It would be very helpful to use link abbrevations in EXPORT_FILE_NAME :

(setq org-link-abbrev-alist
'(("anglisky" . "~/Path/whereever/%s")))

in .emacs and write:

-
* Subtree to be exported
:PROPERTIES:
:EXPORT_FILE_NAME: anglisky:filename
:EXPORT_TITLE:
:END:

foo

-

Possible? Feature Request?


Not possible. Also, link syntax sounds awkward because most links
wouldn't make sense there.

What about introducing a new property:

   :EXPORT_FILE_DIRECTORY:

When set, e.g. to "dir", assuming EXPORT_FILE_NAME is set to "foo/file",
export file name becomes "dir/file".

Since you can set it per subtree or document, I think it would help in
your situation.

WDYT?


Regards,



Hi,

+1 on this. I wanted this as well a while back and didn't know how to do 
it (or whether it's possible or not) so I gave up.


S.

[O] #+SETUPFILE with #+TODO

[Michael Brand]

Hi all

With today's release_8.3.2-308-g6c1f63b when I open the attached
org_todo_test.org when it is writable then the customized todo keyword
CNCL is recognized, when the file is read only then not. I expect CNCL
to be recognized as a todo keyword in both cases.

Michael


org_todo_setup.org
Description: Binary data


org_todo_test.org
Description: Binary data

Re: [O] Emacs+org-mode in a Docker?

[John Kitchin]

This sounds a lot like what I have in mind. Have you tried doing this yet?

Grant Rettke writes:

> On Wed, Nov 4, 2015 at 7:07 PM, John Kitchin  wrote:
>> Thanks for all the notes! It looks like a not too trivial exercise that
>> might have to be a summer project for me.
>
> For the past year, I've been curious about how to make my Emacs
> environment available to me and anyone else, easily. Goal is to make
> working on a Linux, Windows, or OSX GUI a one-click setup. For me,
> Vagrant is the obvious solution here. Vagrant and Packer,
> specifically.
>
> The benefit of using Packer to build a Vagrant image is that the user
> doesn't have to wait for the download and installation of big stuff
> like TeXLive. That get's me curious if we (all Emacs/Org users) might
> want to build a base-image that includes all the stuff out there.
> Might make it easy for users to try out lots of different configs
> without having to deal with all of the software requirements. While
> that isn't a "big deal", it is just easier for them so they can focus
> on doing stuff with Org.

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

Re: [O] Testers / Feedback wanted: Gantt charts via org-gantt.el

[Karl Voit]

* Bernhard Schmitz  wrote:
>
> Hi Karl, hi Eric,
>
> I know it has been a while.

I was off-mailinglist for a couple of months. Sorry.

> Karl:
>
>> Oh, I was too lazy to write a working example.
>> 
>> ,[ working example ]
>> | ** DONE My pretty task
>> | CLOSED: [2015-04-30 Thu 07:50] SCHEDULED: <2015-04-30 Thu>
>> | :PROPERTIES:
>> | :CREATED:  [2015-04-17 Fri 15:36]
>> | :ID:   2015-04-17-Dach-zu
>> | :TRIGGER:  foo1(NEXT) bar1(WAITING)
>> | :BLOCKER:  previousXY prevZ
>> | :END:
>> `
>> 
>> So when this task got marked as DONE, the headings with the ID
>> propertes "previousXY" and "prevZ" must not have been in an open
>> state. Further more, the headings with ID "foo1" got the new states
>> NEXT and "bar1" WAITING accordingly.
>
> Your example clarified the effects of org-depend on the actual org
> file, but I'm not sure how this should translate to the gantt
> chart.  The :BLOCKER: property says that when this gets marked as
> done, the blockers must not be open. 

I'm using :BLOCKER: such:

** Throw away old stuff
SCHEDULED: [...]
:PROPERTIES:
:ID: throw-away
:END:

** Paint room
SCHEDULED: [...]
:PROPERTIES:
:BLOCKER: throw-away
:END:

This way, I don't see "Paint room" on my agenda as long as I did not
finish throwing away the old stuff.

So IMHO the BLOCKER line marks the earliest time of beginning of
"Paint room".

> So actually, the :BLOCKER:
> property has no effect on either the start time, nor on the end
> time of a headline. It only clarifies the earliest possible end
> time - which cannot be expressed in a gantt chart.  

I don't know GANTT charts that well. I thought that with GANTT, the
"Paint room" just gets "connected" to the "end" of the "Throw
away"-bar. Additionally, if the "Throw away" bar is moved, the
"Paint room" is moved accordingly.

> Similarly, the :TRIGGER: property does not define a start or an
> end time of the triggered property either. The only case in which
> it does is if it triggers a (DONE), which would mean that an
> unrelated task suddenly becomes done simply by another task being
> done, and I don't think that happens all too often.

True. I added it for being complete about the features of org-depent
which I am using.

> I now know that I can implement whatever you suggest with
> relatively little effort, but first I need to know what actually
> should happen.

I hope that cleared things a bit. 

Sorry again for being away for so long.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] Changes to contrib

[Rasmus]

Hi,

Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:

> Rasmus  writes:
>> Serge Kosyrev <_deepf...@feelingofgreen.ru> writes:
>>> I'm not sure how wise it would be to raise barriers for contribution,
>>> given the current state of the thing..
>>
>> I don't know what state you refer to.
>
> Well, I couldn't use it, without significant tweaking.
>
> It feels as if the thing doesn't have a maintainer and slowly decomposes.

The question is whether there's any desire down the road to move this
backend to core?  Given that I don’t know that paper status of two former
contributors, and nobody chimed in, it’s likely that that race is already
done.

> The question is.. the only documentation for ox-taskjuggler that exists
> in Worg, seems to only cover the surface aspects of export -- none of
> the existing documentation touches on the multitude of details that the
> existing code does involve itself with.

OK.  There should be docstring and potentially comments, if necessary.
Worg is a separate issue.

 I think you add some more taskjuggle keywords/properties for
 example.
>
> I do, indeed -- and they are undocumented in a matter that is similar to
> the 80% of pre-existing properties.

OK.  It would be better to have some sort of documentation there, but
that’s a separate bug.

>> You use string-join, which is in subr-x.  I think subr-x was not a
>> dependency before.
>
> Oh, indeed -- missed that!
>
> What should I do about it?

I’d just use mapconcat TBH, since it’s just one place as I recall.

(equal (string-join '("a" "b") " ")
   (mapconcat 'identity '("a" "b") " "))

> Understood, will rename, then.

Thanks.  And thanks for working on this!

Rasmus

-- 
This message is brought to you by the department of redundant departments

Re: [O] Changes to contrib

[Serge Kosyrev]

Rasmus  writes:
> Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
[..]
>> I don't know what is the proper way to submit patches for the contrib/
>> directory, so I made a branch on github:
>>
>>   https://github.com/deepfire/org-mode/commits/ox-taskjuggler-fixes
>>
>> Please, do tell how you would like to proceed from there.
>
> Please see
>
>http://orgmode.org/worg/org-contribute.html
>
> TL;DR: git format-patch.
>
> Do you have signed FSF papers?

No, didn't.

> I don't know if there's any desire to move ox-taskjuggler.el to core,
> nor whether it would be possible (since I don’t know if "tj" and
> Baptiste have signed FSF papers).

I'm not sure how wise it would be to raise barriers for contribution,
given the current state of the thing..

> Some quick comments from skimming your code (note, I have no idea what a
> taskjuggler is):
>
> I don’t know what you refer to explicitly.  But that should be fixed, I
> guess.

I'm sorry, what should be?

> I think you add some more taskjuggle keywords/properties for
> example.

[...]

> Also, you introduce a dependency on subr-x, which may or may not be an
> issue since it’s in contrib.

I'm sorry, I'm not sure what do you mean?  I looked at subr-x.el, and
I didn't find any reference to any of those functions..

> org-export-map-special-nodes and org-element-multivalued-property are not
> proper names, as they will supposedly only be used in ox-taskjuggler.

Well, the functions themselves are supposed to be generic.

There are two ways to name a function, in my mind:

  - by intended application
  - by what it does

..it's just that I chose the second.. in the futile hope that someone,
sometime will move/use them. : -)

If you deem it not to be an appropriate course of thought, I will
change the name, sure.

-- 
с уважениeм / respectfully,
Косырев Сергей

Re: [O] Changes to contrib

[Kosyrev Serge]

Rasmus  writes:
> Serge Kosyrev <_deepf...@feelingofgreen.ru> writes:
>> I'm not sure how wise it would be to raise barriers for contribution,
>> given the current state of the thing..
>
> I don't know what state you refer to.

Well, I couldn't use it, without significant tweaking.

It feels as if the thing doesn't have a maintainer and slowly decomposes.

>>> Some quick comments from skimming your code (note, I have no idea what a
>>> taskjuggler is):
>>>
>>> I don’t know what you refer to explicitly.  But that should be fixed, I
>>> guess.
>>
>> I'm sorry, what should be?
>
> Sorry, I was referring to this quote by you, which seems to have
> disappeared:
>
 (One immediate nitpick, of course, is that none of the additions
  are documented..)

That is true, yes.

The question is.. the only documentation for ox-taskjuggler that exists
in Worg, seems to only cover the surface aspects of export -- none of
the existing documentation touches on the multitude of details that the
existing code does involve itself with.

The point I'm trying to make, is that producing some documentation that
would cover the details (that one actually expects to be covered, coming
from the TaskJuggler background) seems like a separate task.

That is, not in scope of my little "tweak it to work for myself" series..

>>> I think you add some more taskjuggle keywords/properties for
>>> example.

I do, indeed -- and they are undocumented in a matter that is similar to
the 80% of pre-existing properties.

>> [...]
>>> Also, you introduce a dependency on subr-x, which may or may not be an
>>> issue since it’s in contrib.
>>
>> I'm sorry, I'm not sure what do you mean?  I looked at subr-x.el, and
>> I didn't find any reference to any of those functions..
>
> You use string-join, which is in subr-x.  I think subr-x was not a
> dependency before.

Oh, indeed -- missed that!

What should I do about it?

>>> org-export-map-special-nodes and org-element-multivalued-property are not
>>> proper names, as they will supposedly only be used in ox-taskjuggler.
>>
>> Well, the functions themselves are supposed to be generic.
>>
>> There are two ways to name a function, in my mind:
>>
>>   - by intended application
>>   - by what it does
>>
>> ..it's just that I chose the second.. in the futile hope that someone,
>> sometime will move/use them. : -)
>
> Then they are in the wrong library.
>
>> If you deem it not to be an appropriate course of thought, I will
>> change the name, sure.
>
> At this point, they lack appropriate names.

Understood, will rename, then.

-- 
с уважениeм / respectfully,
Косырев Сергей

Re: [O] Using link abbrevations for EXPORT_FILE_NAME ?

[AW]

Am Sonntag, 8. November 2015, 20:11:23 schrieb Nicolas Goaziou:
> Hello,
> 
> AW  writes:
> > on orgmode 8.3.2 I've got a large org-file. Offen, I need to export a
> > subtree like this:
> > 
> > -
> > * Subtree to be exported
> > 
> > :PROPERTIES:
> > :EXPORT_FILE_NAME: /PATH/TO/FOLDER/filename
> > :EXPORT_TITLE:
> > 
> > :END:
> > foo
> > 
> > -
> > 
> > I'd like to save the exported file in a project folder, as you can see in
> > EXPORT_FILE_NAME .
> > 
> > It would be very helpful to use link abbrevations in EXPORT_FILE_NAME :
> > 
> > (setq org-link-abbrev-alist
> > 
> >'(("anglisky" . "~/Path/whereever/%s")))
> > 
> > in .emacs and write:
> > 
> > -
> > * Subtree to be exported
> > 
> > :PROPERTIES:
> > :EXPORT_FILE_NAME: anglisky:filename
> > :EXPORT_TITLE:
> > 
> > :END:
> > foo
> > 
> > -
> > 
> > Possible? Feature Request?
> 
> Not possible. Also, link syntax sounds awkward because most links
> wouldn't make sense there.
> 
> What about introducing a new property:
>   :EXPORT_FILE_DIRECTORY:
> When set, e.g. to "dir", assuming EXPORT_FILE_NAME is set to "foo/file",
> export file name becomes "dir/file".
> 
> Since you can set it per subtree or document, I think it would help in
> your situation.

Background: I'm using orgmode on different platforms, Windows and Linux. So I 
(being very proud of that!) wrote an if-clause:

(setq org-link-abbrev-alist
   (if (eq system-type 'windows-nt)
  '(("foopath" . "//Sbs2011/ra2000/Bilder/2010/271-2011/%s")
)
  '(("foopath" . "/home/AW/some/path/2011-271-project/%s")))



So on Windows foopath becomes the first path, and on Linux the second and all 
my links in the orgmode files work on both platforms.

A cheap solution for EXPORT_FILE_NAME: just have two lines and comment out the 
wrong one!

-
* Subtree to be exported
:PROPERTIES:
# :EXPORT_FILE_NAME: //Sbs2011/ra2000/Bilder/2010/271-2011/filename
:EXPORT_FILE_NAME: /home/AW/some/path/2011-271-project/filename
:EXPORT_TITLE:
:END:

foo

-

But comment seems not to work inside properties.

However, :EXPORT_FILE_DIRECTORY: would only improve _my_ situation, if I could 
make it dependend on a condition. 

Thank you very for your help!

Kind regards,

-- 

Alexander

Re: [O] generating org headings from a source block

[Nick Dokos]

Matt Price  writes:

> I would like to be able to insert into an org-buffer the text extracted from 
> a pdf file. PDF-Tools (
> https://github.com/politza/pdf-tools/) provides some excellent tools for 
> doing this.  I've written
> (well, msotly stolen) a defun that finds all my highlights and returns them 
> in the form of an org
> heading:
>
> (defun pdf-annot-export-as-org-heading (pdfpath)
>   ...)
> -
>
> I'm sure it is very clumsy, but it sort of works.  I would like to be able to 
> call this function from a
> source block:
>
> #+BEGIN_SRC elisp
> (pdf-annot-export-as-org-heading 
> "/home/matt/HackingHistory/readings/latour-pandoras-hope.pdf")
> (pdf-annot-export-as-org-heading 
> "/home/matt/HackingHistory/readings/historical-authority-hampton.pdf")
> #+END_SRC
>
> The results are close to, but not precisely, what I want:
>
> #+RESULTS:
> #+begin_example
> ** historical-authority-hampton
>
>  
> ([[file:///home/matt/HackingHistory/readings/historical-authority-hampton.pdf]
> [historical-authority-hampton]], 1)
>
> In the Tudor palace at Hampton Court, there is a
> ...
> #+end_example
>
> (a) I only get the last command, because I guess :results value only reports 
> the final returned value.
> But :results output gets me nothing.  What should I be doing?

Have two source blocks? Or use :results output and output the string with 
(princ string)?

> (b) the whole output is wrapped in an example block, which I don't want.  Can 
> I do something to fix
> this?

Maybe :results value raw  or :results value verbatim - untested. I can
never remember the right combo off the top of my head.

> also, (c): I'd rather set the level of the org heading based on context. Can 
> I do that when I call from
> a source block? Should I maybe be doing this some other way (e.g., jsut write 
> an interactive function
> and call it with M-x? But I like being able to assemble all the readings at 
> one go, if possible. 
>

Pass the level as a parameter?

--
Nick

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Cook, Malcolm]

> [...]
 > > > >
 > > > [...]
 > > > >
 > > > > I've wondered if there is not a better way for Babel to share an
 > > > > interactive session with the user.  For instance, if we wanted to
 > > > > support a new form of results processing on addition to value and
 > > > > output Namely, "transcript", wherein the results of evaluating a
 > > > > source block would be a transcript of the season with statements
 > > > > interwoven with their respective outputs I suspect that this would
 > > > > not be easy extension of the current approach since it would require
 > > > > parsing the source into statements that get evaluated sequentially with
 > > > > visible results echoed into the transcript.
 > > >
 > > > You can do stuff like this using babel and some R code.
 > > >
 > > > Here is a start:
 > > >
 > 
 > [snip]
 > 
 > > Sourcing a textConnection on a :noweb interpolated block will not
 > > handle embedded quotes in the source block correctly.  Adding an
 > > assignment of a string to a variable in my-block reveals this
 > > (i.e. `b<-"asdf"`)
 > 
 > I know. That is why I said it is a 'start'. You can work around this
 > with more Babel if that is the only issue. Write a src block `good-fmt'
 > that will render the body of another block as you want it and then use
 > <> to insert it.
 > 
 > 
 > > Nor does it extend to my underspecified conception of what
 > > :transcript output would be.  I intended that :transcript would
 > > generate a colorized source blocks separated by results for
 > > statements which generated visible results.  You implementation makes
 > > the source and results undifferentiated.  My mistake for
 > > underspecifying my intention.  I think I might be able to cobble what
 > > I want using the 'evaluate' package
 > > (https://cran.rstudio.com/web/packages/evaluate/evaluate.pdf) with an
 > > output handler to format source as an R code block and results as R
 > > results block.
 > 
 > See Aaron Ecay's patches from around 08/2014. And discussions on this
 > list from about that time.  He had some of this working, but there
 > were some issues about handling remote calls, IIRC.
 > 
 > > Probably not worth the effort.  Or rather, probably
 > > already done within the knitr/rmarkdown.
 > 
 > By default knitr interlaces the code and output in a frame with
 > the output lines prefixed by '##'. The code is highlighted by default.
 > 
 > In *.Rnw this leads to a single block with a background color and
 > colorized code.
 > 
 > In *.Rhtml you get source code blocks colored per 
 > and results blocks uncolored per .
 > 
 > Using *.org via ox-ravel --> *.Rhtml via knitr --> *.html will get you
 > that far.
 > 

Indeed it does.  I have previously used ox-ravel to superb effect allowing me 
to compose R lessons as *.org and distribute as *.Rmd for use within RStudio 
server.  I must remember to remember this option!

 > Maybe customizing the classes to your taste will finish it.
 > 
 > Best,
 > 
 > Chuck
 > 
 > p.s. If you go with ox-ravel, I recommend the ravel-lang branch:
 > https://github.com/chasberry/orgmode-accessories/tree/ravel-lang 

Re: [O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Marcin Borkowski]

On 2015-11-09, at 21:49, Nick Dokos  wrote:

> Marcin Borkowski  writes:
>
>> On 2015-11-09, at 19:54, Martin Steffen  wrote:
>>
>>> Hi,
>>>
>>> Perhaps it's not really a "fault" of org (nor of auctex), but both
>>> things interact unfortunate. 
>>>
>>> The reason is: when I export org to LaTeX, and I visit the latex file
>>> afterwards, I want that auctex/emacs is instructed about some facts. Thus I
>>> like to have some lines such as
>>>
>>> %%% Local Variables: 
>>> %%% mode: latex
>>> %%% TeX-master: t
>>> %%% End: 
>>>
>>> at the end of the latex file. Org allows that, in that I add the
>>> "LATEX-only" export at the end of the org-file
>>>
>>> #+BEGIN_LATEX
>>> %
>>> %%% Local Variables: 
>>> %%% mode: latex
>>> %%% TeX-master: t
>>> %%% End: 
>>> #+END_LATEX
>>>
>>>
>>> Doing that produces the desired lines at the end of the generated latex, and
>>> if I visit the latex file, emacs/auctex is instructed according to my 
>>> wishes.
>>>
>>>
>>> Now the problem: If I refresh the /org/ file, emacs/org thinks that actually
>>> the file is a latex file (due to the line "mode: latex") and switches from
>>> org-mode to latex-mode.
>>>
>>>
>>> It's a minor thing, obviously, but I just wonder if there's an easy 
>>> workaround.
>>
>> Note: this is a terrible hack, so use it your own risk, only if there's
>> no sane alternative etc.
>>
>> #+BEGIN_COMMENT
>> %
>> %%% Local Variables: 
>> %%% mode: org
>> %%% End: 
>> #+END_COMMENT
>> #+BEGIN_LATEX
>> %
>> %%% Local Variables: 
>> %%% mode: latex
>> %%% TeX-master: t
>> %%% End: 
>> #+END_LATEX
>>
>
> Is there some rule about what happens when emacs sees two local variable
> blocks in a file? It seems that the first one is enforced and the second
> ignored: the above works in the given order of the two blocks, but not
> if the order is reversed.

I guess this is just implementation detail: the last 3000 characters of
the last page are scanned, and if a file local variables list is found,
it is applied, no matter what happens /after/ it.

> In any case, another solution along the same lines is as follows:
> local variables are only recognized in the last "page" of the file so
> just add a Control-L at the end of the org file:
>
> --8<---cut here---start->8---
> ...
> #+BEGIN_COMMENT
> Insert a control-L here to prevent emacs from interpreting the local
> variables block above - local variables blocks are recognized only on
> the last "page" of the file.
> 
> #+END_COMMENT
> --8<---cut here---end--->8---

Still not pretty, but /much/ better than mine!

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Allowing loose ordering in Org files

[Stelian Iancu]

On 09/11/15 21:04, Achim Gratz wrote:

John Wiegley writes:

You will find that the argument really wasn't about performance, but
complexity.


I can accept a complexity argument,


I meant O() complexity, not implementation complexity.


if my request were really "a separate
code-path". I'm not sure it is. For example, my needs could be satisfied by
something as simple as:

 (defun parse-org-entry (...)
 (let ((props (funcall 'parse-org-properties-function ...)))
...))

`parse-org-properties-function' would point to a function that does what Org
8.3 does now. This gives me the option of porting over the 8.2 version and
keeping the old behavior. All that needs to be done is to allow this hook, no?


If it's not about providing the alternative behaviour within Org, then
what does this allow you to do that advising parse-org-entry can't?  A
hook still has the cost of simply being there even when I don't use it.



John, if you end up writing an advice for this function, please share it 
with the list, as I would like the 8.2 behavior as well (I unfortunately 
don't know enough elisp and org internals to do such a thing).


Thanks!

S.

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Stelian Iancu  writes:

> John, if you end up writing an advice for this function, please share it
> with the list, as I would like the 8.2 behavior as well (I unfortunately
> don't know enough elisp and org internals to do such a thing).

To Achim I would say that these are the reasons to have a hook: Because then
it gets documented as an option; it's supported within Org (rather than being
a separate thing people have to find in my .emacs on GitHub); and it shows up
when you M-x customize-group RET org RET.

John

Re: [O] Changes to contrib

[Kosyrev Serge]

Hi,

Rasmus  writes:
> Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
>> The question is.. the only documentation for ox-taskjuggler that exists
>> in Worg, seems to only cover the surface aspects of export -- none of
>> the existing documentation touches on the multitude of details that the
>> existing code does involve itself with.
>
> OK.  There should be docstring and potentially comments, if necessary.
> Worg is a separate issue.

OK, will do.

>>> You use string-join, which is in subr-x.  I think subr-x was not a
>>> dependency before.
>>
>> Oh, indeed -- missed that!
>>
>> What should I do about it?
>
> I’d just use mapconcat TBH, since it’s just one place as I recall.
>
> (equal (string-join '("a" "b") " ")
>(mapconcat 'identity '("a" "b") " "))
>
>> Understood, will rename, then.

All done, sending mails..

-- 
с уважениeм / respectfully,
Косырев Сергей

Re: [O] exporting from org-mode to latex

[Josiah Schwab]

Hi Sharon,

> I'm having a strange problem with exporting from org-mode to latex using
> the latex back-end. When the file that I've written is exported to latex
> and I look at the tex file that is created, I see that it has one
> "\usepackage{grffile}" that I didn't place in my list to be included. In
> fact, I'd never even heard of it until I read it there, but I can't find
> where its picking that particular "\usepackage" from! I've searched my
> "init.org" and its not listed anywhere there, its not listed in the
> org-mode manual, so where is it picking it from then please?

The following information should help clarify things.

,[ C-h v org-latex-default-packages-alist RET ]
| org-latex-default-packages-alist is a variable defined in `org.el'.
| Its value is shown below.
| 
| Documentation:
| Alist of default packages to be inserted in the header.
| 
| Change this only if one of the packages here causes an
| incompatibility with another package you are using.
| 
| The packages in this list are needed by one part or another of
| Org mode to function properly:
| 
| - inputenc, fontenc:  for basic font and character selection
| - fixltx2e: Important patches of LaTeX itself
| - graphicx: for including images
| - grffile: allow periods and spaces in graphics file names
| - longtable: For multipage tables
| - wrapfig: for figure placement
| - rotating: for sideways figures and tables
| - ulem: for underline and strike-through
| - amsmath: for subscript and superscript and math environments
| - textcomp, amssymb: for various symbols used
|   for interpreting the entities in `org-entities'.  You can skip
|   some of these packages if you don't use any of their symbols.
| - capt-of: for captions outside of floats
| - hyperref: for cross references
| 
| Therefore you should not modify this variable unless you know
| what you are doing.  The one reason to change it anyway is that
| you might be loading some other package that conflicts with one
| of the default packages.  Each element is either a cell or
| a string.
| 
| A cell is of the format
| 
|   ("options" "package" SNIPPET-FLAG)
| 
| If SNIPPET-FLAG is non-nil, the package also needs to be included
| when compiling LaTeX snippets into images for inclusion into
| non-LaTeX output.
| 
| A string will be inserted as-is in the header of the document.
| 
| You can customize this variable.
| 
| This variable was introduced, or its default value was changed, in
| version 25.1 of Emacs.
`


Best,
Josiah

[O] exporting from org-mode to latex

[Sharon Kimble]

I'm having a strange problem with exporting from org-mode to latex using
the latex back-end. When the file that I've written is exported to latex
and I look at the tex file that is created, I see that it has one
"\usepackage{grffile}" that I didn't place in my list to be included. In
fact, I'd never even heard of it until I read it there, but I can't find
where its picking that particular "\usepackage" from! I've searched my
"init.org" and its not listed anywhere there, its not listed in the
org-mode manual, so where is it picking it from then please?

On a slightly related note, how can I get packages that I want to be
used, to be listed in the latex document preamble please? Specifically
"imakeidx" to help in generating an index?

Aside from those two difficulties its working very well, and writing the
first draft in org-mode seems easier than writing it straight into
latex!

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.0, fluxbox 1.3.7, emacs 24.5.1


signature.asc
Description: PGP signature

Re: [O] exporting from org-mode to latex

[Nick Dokos]

Sharon Kimble  writes:

> I'm having a strange problem with exporting from org-mode to latex using
> the latex back-end. When the file that I've written is exported to latex
> and I look at the tex file that is created, I see that it has one
> "\usepackage{grffile}" that I didn't place in my list to be included. In
> fact, I'd never even heard of it until I read it there, but I can't find
> where its picking that particular "\usepackage" from! I've searched my
> "init.org" and its not listed anywhere there, its not listed in the
> org-mode manual, so where is it picking it from then please?
>

C-h v org-latex-default-packages-alist RET

> On a slightly related note, how can I get packages that I want to be
> used, to be listed in the latex document preamble please? Specifically
> "imakeidx" to help in generating an index?
>

C-h v org-latex-packages-alist RET

-- 
Nick

Re: [O] Allowing loose ordering in Org files (Was: bug in org-habits)

[Aaron Ecay]

Hi John,

2015ko azaroak 9an, John Wiegley-ek idatzi zuen:

[...]

> Lately there seems to be a push to sacrifice some of this freedom in order to
> gain efficiency and regularity. I imagine this is for the benefit of machine
> parsers; but what if one doesn't use any machine parsers? 

I don’t think it’s possible to separate things like this.  Large parts
of org use a machine parser, written in elisp.  There are (perhaps
asymptotic) plans to transition the rest of org to work based on this
parser.

Adding knobs to this parser increases the burden of those who have
to build and maintain it.  It also heightens the burden for users
(especially novices): M-x customize-group org suddenly asks you one
(or more) questions about details of the syntax that previously you
didn’t need to consider.

We have discussions about extending the syntax fairly regularly.  It
would be good to discuss what questions we might ask of those proposals
to determine whether they should go forward.  Some that I can think of
are:
1. Is there a good (user-friendly, reliable) way to accomplish the same
   goal, given the resources currently available?
2. Is there a large community of users who need this feature and/or
   would adopt it if it became available?
3. Is this something that org’s “competitors” provide easily?  (Not
   necessarily out of a spirit of competition, but rather demonstrating
   a use case.)

I don’t include difficulty of implementation on that list.  I don’t
think the developers should wag the users.  Unfortunately however, I
don’t think your proposal fares well in light of these questions.  (I
don’t mean to imply that they are authoritative; anyone could very well
propose others.  I would be happy if a consensus developed about what
the right questions are, even if there is disagreement about the answers
in this specific case.)

> Org never asked me to give up flexibility for unknown benefits before.
> 
> It should be asked whether users want to trade formatting freedom for those
> benefits. If it has been asked, I missed that discussion. So unless it's an
> heavy maintenance burden to allow floating properties, for example, I don't
> see why I, as a user, shouldn't be allowed to make that choice.

I think framing it in terms of freedom is potentially misleading.
Because org is free software, its users are maximally free to do
any of a wide variety of things, including sticking with an old version,
patching the code locally, distributing a patch/fork/set of advices,
using another program, ...

I think it’s more illuminating to think of it in terms of org as a tool:
have the changes made it more difficult for you to accomplish your goals
with org?  Has something that was previously possible become impossible?
Has something that was previously easy gotten harder?  If the answer to
one of these questions is yes, then we can think of ways to solve the
difficulties.

Of course, you’ve already received quite a bit of feedback about the
proposal from a cross-section of the community.  So what I’ve said will,
I hope, function partially as a lens through which to understand that
feedback, as well as a framework in which to continue discussion if it’s
needed.

-- 
Aaron Ecay

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Aaron Ecay  writes:

> Adding knobs to this parser increases the burden of those who have to build
> and maintain it.

Thank you for your reply, Aaron, I found it most illuminating.

If the answer from the maintainers is "It's more work than we want to do",
that's completely acceptable. I've been operating under the premise that it
wouldn't be difficult to add such an option (just the hook, mind you, not the
functionality behind it).

I suppose at this point it becomes a question of whether others want this as
much as I do. If it's just a handful of us, and the maintainers find the
option onerous, that's really the end of it.

> I think it’s more illuminating to think of it in terms of org as a tool:
> have the changes made it more difficult for you to accomplish your goals
> with org? Has something that was previously possible become impossible? Has
> something that was previously easy gotten harder? If the answer to one of
> these questions is yes, then we can think of ways to solve the difficulties.

There is another vector to consider, and a far more nebulous one: How does it
impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
its use.

There are many highly functional alternatives to Org that I've tried and
rejected because they lack the easy grace of Org. That grace is why I've been
able to stick with it after almost 9,000 handled tasks. Any perception of
"inertia" in a tasking system causes me to psychologically avoid it, even if I
have no rational basis for that aversion.

I sincerely hope that those with high technical motives will keep in mind the
usability of Org beyond purely technical considerations. It should say
something that a long-time user is unhappy with the way Org "feels" in 8.3.

John

[O] org export customization: why do #+EXCLUDE_TAGS: settings have no effect?

[Martin Steffen]

Hi,

I want selective export in org (for instance, exporting to beamer/latex, and
html etc). I seem to understand the "theory" but it seems not really to work
for me.


what _works_ is as follows: I set directly a corresponding variable, in
particular, for instance, set it "hard" to

(setq org-export-exclude-tags '("noexport" "private" "handout")


"noexport" is the original value, but I want to keep trees tagged as
"private" and as "handout" out of for instance the slides.

Now that seems to work.

Now: when I want to /customize/ that in the org-file itself, it seems that's
done by doing something like


#+EXCLUDE_TAGS: private


(In (older?) versions, I also found #+EXPORT_EXCLUDE_TAGS). 


Anyhow: having such a specification in the org-file seems to have /no
effect/, even if I "refresh" the org-file, nor does it work when I visit the
file for the first time. It seems simply not to affect the said variable
"org-export-exclude-tags"


--

I use a pretty up-to-date org version pulled from git-hub (org-version
8.3.2, emacs-version 24.3.1)

Martin

[O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Martin Steffen]

Hi,

Perhaps it's not really a "fault" of org (nor of auctex), but both
things interact unfortunate. 

The reason is: when I export org to LaTeX, and I visit the latex file
afterwards, I want that auctex/emacs is instructed about some facts. Thus I
like to have some lines such as

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 

at the end of the latex file. Org allows that, in that I add the
"LATEX-only" export at the end of the org-file

#+BEGIN_LATEX
%
%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 
#+END_LATEX


Doing that produces the desired lines at the end of the generated latex, and
if I visit the latex file, emacs/auctex is instructed according to my wishes.


Now the problem: If I refresh the /org/ file, emacs/org thinks that actually
the file is a latex file (due to the line "mode: latex") and switches from
org-mode to latex-mode.


It's a minor thing, obviously, but I just wonder if there's an easy workaround.

Martin
 

Re: [O] Allowing loose ordering in Org files

[Rasmus]

Hi,

I share my personal views on this below.

John Wiegley  writes:

>> John Wiegley  writes:
>
>> I spoke to Nicolas directly and he mentioned that a goal for syntax
>> regularity is to make it possible to reliably read and manipulate Org files
>> outside of Emacs.
>> 
>> For this I *am* willing to give up order independence of PROPERTIES. Having
>> a customization option would needlessly increases the number of
>> possibilities external processors must consider, and so I retract my
>> request.
>
> I've had time this weekend to rethink my feature request, and I realized that
> even machine-friendly formatting is something I should be able to give up, to
> have an Org that works better for me.
>
> What has always made Org great (to me) is that it's a rather "light" overlay
> on a plain old text file. What structure it does enforce -- say, the actual
> syntax of drawers -- has always felt fairly "fluid".
>
> Lately there seems to be a push to sacrifice some of this freedom in order to
> gain efficiency and regularity. I imagine this is for the benefit of machine
> parsers; but what if one doesn't use any machine parsers? Org never asked me
> to give up flexibility for unknown benefits before.

This is one concern.  Another concern is adhere to the "Org syntax", which
I guess is what you mean by regularity.

There are other implementations of Org.  For instance, Github and Gitlab
display Org files via org-ruby (AFAIK).  If the claim was, that there is a
strong desire to formalize and stick to the Org syntax, I would agree.
Furthermore, I would claim this is a good thing.

http://orgmode.org/worg/dev/org-syntax.html#Property_Drawers

An alternative is a freer take on syntax, such as how MD has evolved,
which IMO is a bit annoying.

> It should be asked whether users want to trade formatting freedom for those
> benefits. If it has been asked, I missed that discussion. So unless it's an
> heavy maintenance burden to allow floating properties, for example, I don't
> see why I, as a user, shouldn't be allowed to make that choice.

That’s a fair point.

> To those who repeat the performance argument: This is an opt-in only request.
> It is not about changing the performance of default Org, or making files more
> difficult to parse outside of Emacs for everyone.

I disagree with your last claim.

Rasmus

-- 
It was you, Jezebel, it was you

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Rasmus   writes:

>> To those who repeat the performance argument: This is an opt-in only
>> request. It is not about changing the performance of default Org, or making
>> files more difficult to parse outside of Emacs for everyone.

> I disagree with your last claim.

I'm not sure I understand, can you clarify? What I meant is that I don't want
to get in the way of the maintainer's vision for "default Org". I would just
like some customization options, to keep using Org as I'm used to it.

John

[O] Allowing loose ordering in Org files (Was: bug in org-habits)

[John Wiegley]

> John Wiegley  writes:

> I spoke to Nicolas directly and he mentioned that a goal for syntax
> regularity is to make it possible to reliably read and manipulate Org files
> outside of Emacs.
> 
> For this I *am* willing to give up order independence of PROPERTIES. Having
> a customization option would needlessly increases the number of
> possibilities external processors must consider, and so I retract my
> request.

I've had time this weekend to rethink my feature request, and I realized that
even machine-friendly formatting is something I should be able to give up, to
have an Org that works better for me.

What has always made Org great (to me) is that it's a rather "light" overlay
on a plain old text file. What structure it does enforce -- say, the actual
syntax of drawers -- has always felt fairly "fluid".

Lately there seems to be a push to sacrifice some of this freedom in order to
gain efficiency and regularity. I imagine this is for the benefit of machine
parsers; but what if one doesn't use any machine parsers? Org never asked me
to give up flexibility for unknown benefits before.

It should be asked whether users want to trade formatting freedom for those
benefits. If it has been asked, I missed that discussion. So unless it's an
heavy maintenance burden to allow floating properties, for example, I don't
see why I, as a user, shouldn't be allowed to make that choice.

To those who repeat the performance argument: This is an opt-in only request.
It is not about changing the performance of default Org, or making files more
difficult to parse outside of Emacs for everyone.

John

Re: [O] Lexical binding bug in org-list.el?

[Kaushal Modi]

Thanks for fixing this.

Re: [O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Nick Dokos]

Marcin Borkowski  writes:

> On 2015-11-09, at 19:54, Martin Steffen  wrote:
>
>> Hi,
>>
>> Perhaps it's not really a "fault" of org (nor of auctex), but both
>> things interact unfortunate. 
>>
>> The reason is: when I export org to LaTeX, and I visit the latex file
>> afterwards, I want that auctex/emacs is instructed about some facts. Thus I
>> like to have some lines such as
>>
>> %%% Local Variables: 
>> %%% mode: latex
>> %%% TeX-master: t
>> %%% End: 
>>
>> at the end of the latex file. Org allows that, in that I add the
>> "LATEX-only" export at the end of the org-file
>>
>> #+BEGIN_LATEX
>> %
>> %%% Local Variables: 
>> %%% mode: latex
>> %%% TeX-master: t
>> %%% End: 
>> #+END_LATEX
>>
>>
>> Doing that produces the desired lines at the end of the generated latex, and
>> if I visit the latex file, emacs/auctex is instructed according to my wishes.
>>
>>
>> Now the problem: If I refresh the /org/ file, emacs/org thinks that actually
>> the file is a latex file (due to the line "mode: latex") and switches from
>> org-mode to latex-mode.
>>
>>
>> It's a minor thing, obviously, but I just wonder if there's an easy 
>> workaround.
>
> Note: this is a terrible hack, so use it your own risk, only if there's
> no sane alternative etc.
>
> #+BEGIN_COMMENT
> %
> %%% Local Variables: 
> %%% mode: org
> %%% End: 
> #+END_COMMENT
> #+BEGIN_LATEX
> %
> %%% Local Variables: 
> %%% mode: latex
> %%% TeX-master: t
> %%% End: 
> #+END_LATEX
>

Is there some rule about what happens when emacs sees two local variable
blocks in a file? It seems that the first one is enforced and the second
ignored: the above works in the given order of the two blocks, but not
if the order is reversed.

In any case, another solution along the same lines is as follows:
local variables are only recognized in the last "page" of the file so
just add a Control-L at the end of the org file:

--8<---cut here---start->8---
...
#+BEGIN_COMMENT
Insert a control-L here to prevent emacs from interpreting the local
variables block above - local variables blocks are recognized only on
the last "page" of the file.

#+END_COMMENT
--8<---cut here---end--->8---

--
Nick

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> The whole point of defining a formal syntax for Org is that it becomes
> possible to parse Org documents with something other than Emacs and still
> make sense of them. To reap that benefit, you need to drop some of the
> ad-hoc parsing that Org did in the past.

Yes, I know this. The benefits of regular structure are unrelated to my
request for freedom from the constraints of such regularity.

> You will find that the argument really wasn't about performance, but
> complexity.

I can accept a complexity argument, if my request were really "a separate
code-path". I'm not sure it is. For example, my needs could be satisfied by
something as simple as:

(defun parse-org-entry (...)
(let ((props (funcall 'parse-org-properties-function ...)))
   ...))

`parse-org-properties-function' would point to a function that does what Org
8.3 does now. This gives me the option of porting over the 8.2 version and
keeping the old behavior. All that needs to be done is to allow this hook, no?

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Rasmus   writes:

> If the placement of properties is "free", the secondary interpreter /must/
> support this customization option to be able to interpret the org format.
> Note, this matters for both interactive usage (being able to click/open a
> reference) and for "export" (e.g. org-ruby).

If my request is fulfilled, I would expect that changing the "find properties
function" would imply that one's Org file is no longer usable by secondary
interpreters. I.e., "If you change this, you do so at your own risk".

John

[O] generating org headings from a source block

[Matt Price]

I would like to be able to insert into an org-buffer the text extracted
from a pdf file. PDF-Tools (https://github.com/politza/pdf-tools/) provides
some excellent tools for doing this.  I've written (well, msotly stolen) a
defun that finds all my highlights and returns them in the form of an org
heading:

(defun pdf-annot-export-as-org-heading (pdfpath)
  "Acquire highlight annotations as text, and insert into existing buffer
as org heading"
  (interactive)
  (let ((outputstring "")

)
(save-excursion
  (find-file pdfpath)
  (let (
(annots (sort (pdf-annot-getannots nil (list 'highlight)  nil)
'pdf-annot-compare-annotations))
(filename (format "%s.org"
  (file-name-sans-extension
   (buffer-name
(linktext (concat "[[file://" (buffer-file-name)
  "][" (file-name-sans-extension (buffer-name))
"]]" )))
  (setq outputstring (concat "** " (file-name-sans-extension
(buffer-name)) "\n\n"))

  ;; (insert (concat "#+TITLE: Notes for " (file-name-sans-extension
filename)))
  ;; (org-insert-heading-respect-content)
  ;; (insert (file-name-sans-extension filename))
  (mapc
   (lambda (annot) ;; traverse all annotations
 (message "%s" annot)
 (let ((page (assoc-default 'page annot))
   (text (assoc-default 'subject annot))
   )
   ;;(insert (concat "\n" text " (" linktext ", " (number-to-string
page) ")\n"))
   (setq outputstring (concat outputstring text " (" linktext ", "
(number-to-string page) ")\n\n"))
   )
 )
   annots)
  ))
;;(write-file filename t)
outputstring
))

-

I'm sure it is very clumsy, but it sort of works.  I would like to be able
to call this function from a source block:

#+BEGIN_SRC elisp
(pdf-annot-export-as-org-heading
"/home/matt/HackingHistory/readings/latour-pandoras-hope.pdf")
(pdf-annot-export-as-org-heading
"/home/matt/HackingHistory/readings/historical-authority-hampton.pdf")
#+END_SRC

The results are close to, but not precisely, what I want:

#+RESULTS:
#+begin_example
** historical-authority-hampton

 
([[file:///home/matt/HackingHistory/readings/historical-authority-hampton.pdf][historical-authority-hampton]],
1)

In the Tudor palace at Hampton Court, there is a
...
#+end_example

(a) I only get the last command, because I guess :results value only
reports the final returned value. But :results output gets me nothing.
What should I be doing?
(b) the whole output is wrapped in an example block, which I don't want.
Can I do something to fix this?
also, (c): I'd rather set the level of the org heading based on context.
Can I do that when I call from a source block? Should I maybe be doing this
some other way (e.g., jsut write an interactive function and call it with
M-x? But I like being able to assemble all the readings at one go, if
possible.

Thanks as always,
Matt

Re: [O] Allowing loose ordering in Org files

[Achim Gratz]

John Wiegley writes:
>> John Wiegley  writes:
>> I spoke to Nicolas directly and he mentioned that a goal for syntax
>> regularity is to make it possible to reliably read and manipulate Org files
>> outside of Emacs.

How about keeping the discussion on the list and stop Cc: and Reaply-To:
madness?

> I've had time this weekend to rethink my feature request, and I realized that
> even machine-friendly formatting is something I should be able to give up, to
> have an Org that works better for me.

The whole point of defining a formal syntax for Org is that it becomes
possible to parse Org documents with something other than Emacs and
still make sense of them.  To reap that benefit, you need to drop some
of the ad-hoc parsing that Org did in the past.

> What has always made Org great (to me) is that it's a rather "light" overlay
> on a plain old text file. What structure it does enforce -- say, the actual
> syntax of drawers -- has always felt fairly "fluid".

Still does.

> Lately there seems to be a push to sacrifice some of this freedom in order to
> gain efficiency and regularity. I imagine this is for the benefit of machine
> parsers; but what if one doesn't use any machine parsers? Org never asked me
> to give up flexibility for unknown benefits before.

Yes it did and still does, just in other places that you may or may not
care about.  For instance, it asks you to not use multi-line table
cells, or column and row spans.  It also doesn't let you use a :TBLFM:
drawer instead of that #+TBLFM: line just because it looks more neat (it
really should, BTW :-).

> It should be asked whether users want to trade formatting freedom for those
> benefits. If it has been asked, I missed that discussion. So unless it's an
> heavy maintenance burden to allow floating properties, for example, I don't
> see why I, as a user, shouldn't be allowed to make that choice.

I won't talk about "maintenance burden", but in any case it's a
technical debt.  You'd have to maintain two code paths that accomplish
the same result or at least should.

> To those who repeat the performance argument: This is an opt-in only request.
> It is not about changing the performance of default Org, or making files more
> difficult to parse outside of Emacs for everyone.

You will find that the argument really wasn't about performance, but
complexity.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [O] Allowing loose ordering in Org files

[Achim Gratz]

John Wiegley writes:
>> You will find that the argument really wasn't about performance, but
>> complexity.
>
> I can accept a complexity argument,

I meant O() complexity, not implementation complexity.

> if my request were really "a separate
> code-path". I'm not sure it is. For example, my needs could be satisfied by
> something as simple as:
>
> (defun parse-org-entry (...)
> (let ((props (funcall 'parse-org-properties-function ...)))
>...))
>
> `parse-org-properties-function' would point to a function that does what Org
> 8.3 does now. This gives me the option of porting over the 8.2 version and
> keeping the old behavior. All that needs to be done is to allow this hook, no?

If it's not about providing the alternative behaviour within Org, then
what does this allow you to do that advising parse-org-entry can't?  A
hook still has the cost of simply being there even when I don't use it.


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] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Cook, Malcolm]

 > -Original Message-
 > From: Charles C. Berry [mailto:ccbe...@ucsd.edu]
 > Sent: Saturday, November 07, 2015 6:33 PM
 > To: Cook, Malcolm 
 > Cc: emacs-orgmode@gnu.org
 > Subject: Re: BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-
 > session over aggressively performs "; ; cleanup extra prompts left in output"
 > and a possible workaround
 > 
 > On Sat, 7 Nov 2015, Cook, Malcolm wrote:
 > 
 > > Thanks Chuck for setting this through.
 > >
 > [...]
 > >
 > > I've wondered if there is not a better way for Babel to share an
 > > interactive session with the user.  For instance, if we wanted to
 > > support a new form of results processing on addition to value and
 > > output Namely, "transcript", wherein the results of evaluating a
 > > source block would be a transcript of the season with statements
 > > interwoven with their respective outputs I suspect that this would
 > > not be easy extension of the current approach since it would require
 > > parsing the source into statements that get evaluated sequentially with
 > > visible results echoed into the transcript.
 > 
 > You can do stuff like this using babel and some R code.
 > 
 > Here is a start:
 > 
 > --8<---cut here---start->8---
 > #+NAME: my-block
 > #+BEGIN_SRC R :eval no
 > ls()
 > a <- 1
 > sqrt(a+2)
 > ls()
 > #+END_SRC
 > 
 > 
 > #+BEGIN_SRC R :session :noweb yes :results value raw :wrap example
 >  capture.output(
 >  source(textConnection("
 ><>
 >"),
 >echo=T,print=T))
 > #+END_SRC
 > 
 > #+RESULTS:
 > #+BEGIN_example
 > 
 > > ls()
 > [1] "a"
 > 
 > > a <- 1
 > 
 > > sqrt(a+2)
 > [1] 1.732051
 > 
 > > ls()
 > [1] "a"
 > #+END_example
 > 
 > 
 > --8<---cut here---end--->8---
 > 
 > I suppose you would want `:exports results'.

Hi Chuck,

Sourcing a textConnection on a :noweb interpolated block will not handle 
embedded quotes in the source block correctly.  Adding an assignment of a 
string to a variable in my-block reveals this (i.e. `b<-"asdf"`)

Nor does it extend to my underspecified conception of what :transcript output 
would be.  I  intended that :transcript would generate a colorized source 
blocks separated by results for statements which generated visible results.  
You implementation makes the source and results undifferentiated.   My mistake 
for underspecifying my intention.  I think I might be able to cobble what I 
want using the 'evaluate' package 
(https://cran.rstudio.com/web/packages/evaluate/evaluate.pdf) with an output 
handler to format source as an R code block and results as R results block.  
Probably not worth the effort.  Or rather, probably already done within the 
knitr/rmarkdown.

Thanks,

Malcolm

 > 
 > Best,
 > Chuck

Re: [O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Marcin Borkowski]

On 2015-11-09, at 19:54, Martin Steffen  wrote:

> Hi,
>
> Perhaps it's not really a "fault" of org (nor of auctex), but both
> things interact unfortunate. 
>
> The reason is: when I export org to LaTeX, and I visit the latex file
> afterwards, I want that auctex/emacs is instructed about some facts. Thus I
> like to have some lines such as
>
> %%% Local Variables: 
> %%% mode: latex
> %%% TeX-master: t
> %%% End: 
>
> at the end of the latex file. Org allows that, in that I add the
> "LATEX-only" export at the end of the org-file
>
> #+BEGIN_LATEX
> %
> %%% Local Variables: 
> %%% mode: latex
> %%% TeX-master: t
> %%% End: 
> #+END_LATEX
>
>
> Doing that produces the desired lines at the end of the generated latex, and
> if I visit the latex file, emacs/auctex is instructed according to my wishes.
>
>
> Now the problem: If I refresh the /org/ file, emacs/org thinks that actually
> the file is a latex file (due to the line "mode: latex") and switches from
> org-mode to latex-mode.
>
>
> It's a minor thing, obviously, but I just wonder if there's an easy 
> workaround.

Note: this is a terrible hack, so use it your own risk, only if there's
no sane alternative etc.

--8<---cut here---start->8---
#+BEGIN_COMMENT
%
%%% Local Variables: 
%%% mode: org
%%% End: 
#+END_COMMENT
#+BEGIN_LATEX
%
%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 
#+END_LATEX
--8<---cut here---end--->8---

> Martin

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Changes to contrib

[Rasmus]

Hi Serge,

Serge Kosyrev <_deepf...@feelingofgreen.ru> writes:

> I'm not sure how wise it would be to raise barriers for contribution,
> given the current state of the thing..

I don't know what state you refer to.

>> Some quick comments from skimming your code (note, I have no idea what a
>> taskjuggler is):
>>
>> I don’t know what you refer to explicitly.  But that should be fixed, I
>> guess.
>
> I'm sorry, what should be?

Sorry, I was referring to this quote by you, which seems to have
disappeared:

>>> (One immediate nitpick, of course, is that none of the additions
>>>  are documented..)


>> I think you add some more taskjuggle keywords/properties for
>> example.
>
> [...]
>
>> Also, you introduce a dependency on subr-x, which may or may not be an
>> issue since it’s in contrib.
>
> I'm sorry, I'm not sure what do you mean?  I looked at subr-x.el, and
> I didn't find any reference to any of those functions..

You use string-join, which is in subr-x.  I think subr-x was not a
dependency before.

>> org-export-map-special-nodes and org-element-multivalued-property are not
>> proper names, as they will supposedly only be used in ox-taskjuggler.
>
> Well, the functions themselves are supposed to be generic.
>
> There are two ways to name a function, in my mind:
>
>   - by intended application
>   - by what it does
>
> ..it's just that I chose the second.. in the futile hope that someone,
> sometime will move/use them. : -)

Then they are in the wrong library.

> If you deem it not to be an appropriate course of thought, I will
> change the name, sure.

At this point, they lack appropriate names.

Rasmus

-- 
Summon the Mothership!

Re: [O] Allowing loose ordering in Org files

[Rasmus]

Hi John,

John Wiegley  writes:

>> Rasmus   writes:
>
>>> To those who repeat the performance argument: This is an opt-in only
>>> request. It is not about changing the performance of default Org, or making
>>> files more difficult to parse outside of Emacs for everyone.
>
>> I disagree with your last claim.
>
> I'm not sure I understand, can you clarify? What I meant is that I don't want
> to get in the way of the maintainer's vision for "default Org".

Note that I’m *not* the maintainer and speak with no authority on the issue!

Some alternative Org interpreter must be able to find the properties
drawer since it needs to support, e.g. linking to headlines,

 * f_0 
 :PROPERTIES:
 :CUSTOM_ID: f0
 :END:
 * f_1
 See also [[#f0]]

If the placement of properties is "free", the secondary interpreter /must/
support this customization option to be able to interpret the org format.
Note, this matters for both interactive usage (being able to click/open a
reference) and for "export" (e.g. org-ruby).

> I would just like some customization options, to keep using Org as I'm
> used to it.

I sympathize, and I don’t know what is the correct behavior here.  I do
think that allowing this is obviously the right thingᵀᴹ, but it might
still be the lesser of two evils.  I don’t fell qualified to form opinions
on this.

Rasmus

-- 
Vote for Dick Taid in an election near you!

Re: [O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Rasmus]

Martin Steffen  writes:

> Hi,
>
> Perhaps it's not really a "fault" of org (nor of auctex), but both
> things interact unfortunate. 
>
> The reason is: when I export org to LaTeX, and I visit the latex file
> afterwards, I want that auctex/emacs is instructed about some facts. Thus I
> like to have some lines such as
>
> %%% Local Variables: 
> %%% mode: latex
> %%% TeX-master: t
> %%% End: 
>
> at the end of the latex file. Org allows that, in that I add the
> "LATEX-only" export at the end of the org-file

If it's only about setting the mode, you could use
org-latex-compiler-file-string (in the git version), and set tex-master in
a latex block...

Rasmus

-- 
Lasciate ogni speranza, voi che leggete questo.

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Charles C. Berry]

On Mon, 9 Nov 2015, Cook, Malcolm wrote:
[...]

> >
> [...]
> >
> > I've wondered if there is not a better way for Babel to share an
> > interactive session with the user.  For instance, if we wanted to
> > support a new form of results processing on addition to value and
> > output Namely, "transcript", wherein the results of evaluating a
> > source block would be a transcript of the season with statements
> > interwoven with their respective outputs I suspect that this would
> > not be easy extension of the current approach since it would require
> > parsing the source into statements that get evaluated sequentially with
> > visible results echoed into the transcript.
>
> You can do stuff like this using babel and some R code.
>
> Here is a start:
>


[snip]


Sourcing a textConnection on a :noweb interpolated block will not
handle embedded quotes in the source block correctly.  Adding an
assignment of a string to a variable in my-block reveals this
(i.e. `b<-"asdf"`)


I know. That is why I said it is a 'start'. You can work around this
with more Babel if that is the only issue. Write a src block `good-fmt' 
that will render the body of another block as you want it and then use

<> to insert it.



Nor does it extend to my underspecified conception of what
:transcript output would be.  I intended that :transcript would
generate a colorized source blocks separated by results for
statements which generated visible results.  You implementation makes
the source and results undifferentiated.  My mistake for
underspecifying my intention.  I think I might be able to cobble what
I want using the 'evaluate' package
(https://cran.rstudio.com/web/packages/evaluate/evaluate.pdf) with an
output handler to format source as an R code block and results as R
results block.


See Aaron Ecay's patches from around 08/2014. And discussions on this
list from about that time.  He had some of this working, but there
were some issues about handling remote calls, IIRC.


Probably not worth the effort.  Or rather, probably
already done within the knitr/rmarkdown.


By default knitr interlaces the code and output in a frame with
the output lines prefixed by '##'. The code is highlighted by default.

In *.Rnw this leads to a single block with a background color and
colorized code.

In *.Rhtml you get source code blocks colored per 
and results blocks uncolored per .

Using *.org via ox-ravel --> *.Rhtml via knitr --> *.html will get you 
that far.


Maybe customizing the classes to your taste will finish it.

Best,

Chuck

p.s. If you go with ox-ravel, I recommend the ravel-lang branch:
https://github.com/chasberry/orgmode-accessories/tree/ravel-lang

Re: [O] unfortunate "feature interaction" of org-export and emacs-latex-auctex mode

[Martin Steffen]

> "Marcin" == Marcin Borkowski  writes:


Marcin> Note: this is a terrible hack, so use it your own risk, only
Marcin> if there's no sane alternative etc.


Works for me, thanks (and for the suggestions of the others in the
thread. Martin


Marcin> #+BEGIN_COMMENT
Marcin> 
%
Marcin> %%% Local Variables: %%% mode: org %%% End:
Marcin> #+END_COMMENT #+BEGIN_LATEX
Marcin> 
%
Marcin> %%% Local Variables: %%% mode: latex %%% TeX-master: t %%%
Marcin> End: #+END_LATEX

>> Martin

Marcin> Hth,

Marcin> -- Marcin Borkowski
Marcin> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of
Marcin> Mathematics and Computer Science Adam Mickiewicz University

Re: [O] exporting from org-mode to latex

[Thomas S . Dye]

Aloha Sharone
Sharon Kimble  writes:

> I'm having a strange problem with exporting from org-mode to latex using
> the latex back-end. When the file that I've written is exported to latex
> and I look at the tex file that is created, I see that it has one
> "\usepackage{grffile}" that I didn't place in my list to be included. In
> fact, I'd never even heard of it until I read it there, but I can't find
> where its picking that particular "\usepackage" from! I've searched my
> "init.org" and its not listed anywhere there, its not listed in the
> org-mode manual, so where is it picking it from then please?

That's in org.el.  I think it's new.

> On a slightly related note, how can I get packages that I want to be
> used, to be listed in the latex document preamble please? Specifically
> "imakeidx" to help in generating an index?

See org-latex-packages-alist.

   (add-to-list 'org-latex-packages-alist '("" "imakeidx"))

> Aside from those two difficulties its working very well, and writing the
> first draft in org-mode seems easier than writing it straight into
> latex!

Ditto, I find the lightweight markup in Org mode liberating.

All the best,
Tom

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

Re: [O] Allowing loose ordering in Org files

[Thomas S . Dye]

John Wiegley  writes:

>
> There is another vector to consider, and a far more nebulous one: How does it
> impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
> its use.
>
> There are many highly functional alternatives to Org that I've tried and
> rejected because they lack the easy grace of Org. That grace is why I've been
> able to stick with it after almost 9,000 handled tasks. Any perception of
> "inertia" in a tasking system causes me to psychologically avoid it, even if I
> have no rational basis for that aversion.
>
> I sincerely hope that those with high technical motives will keep in mind the
> usability of Org beyond purely technical considerations. It should say
> something that a long-time user is unhappy with the way Org "feels" in 8.3.

I admire John's many accomplishments and value his membership in the Org
mode community.

Is the hook he is requesting a difficult thing to implement?  Would it
be possible to describe the customization variable in a "Super User"
section that is clearly not for the faint at heart?

I'm not suggesting anyone should implement a hook or create a
customization variable, I'm just curious (and unable to figure out
answers on my own).

All the best,
Tom

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

Re: [O] org-mode and scrum

[Karl Voit]

* Jude DaShiell  wrote:
> Have we got any software engineers on this list who use or have used 
> org-mode for doing scrum?  How useable is org-mode for scrum anyway?

I am using Org-mode as a Scrum product owner. With a few yasnippet
templates, I'm fine with Org-mode.

There is no collaboration possible for me now. Also I am the only
one in my department using Org-mode.

However, you might want to watch https://t.co/aYBd6MzL5p where
Howard Abrams is demonstrating some DevOps-magic with Org-mode. He's
obviously using it as an engineer within Scrum.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] [PATCH 0/8] A bunch of fixes for contrib/ox-taskjuggler.el

[Kosyrev Serge]

Good evening, folks!

This is a bunch of solutions for the most direct obstacles that
I encountered, mostly additions of direct Org-property -> TJ-attribute
export pathways.

Kosyrev Serge (8):
  ox-taskjuggler.el:  allow direct 'leaves' specification
  ox-taskjuggler.el:  factor 'org-export-map-special-nodes'
  ox-taskjuggler.el:  :POST-INCLUDES lists files to include post-section
  ox-taskjuggler.el:  :PROJECT-{END,DURATION} project attribute
  ox-taskjuggler.el:  add 'org-taskjuggler-multivalued-property'
  ox-taskjuggler.el:  interpret 'allocate' as a multivalued-property
  ox-taskjuggler.el:  allow 'priority' to be a directly-specified
integer
  ox-taskjuggler.el:  allow trimming the task ID from its title

 contrib/lisp/ox-taskjuggler.el | 122 +
 1 file changed, 88 insertions(+), 34 deletions(-)

-- 
2.5.0

[O] [PATCH 3/8] ox-taskjuggler.el: :POST-INCLUDES lists files to include post-section

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-project-plan):  allow for include
directives to be inserted after resource and task sections.
---
 contrib/lisp/ox-taskjuggler.el | 48 ++
 1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 2cf2c78..427fb6e 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -665,19 +665,35 @@ Return complete project plan as a string in TaskJuggler 
syntax."
  main-resources info)))
(concat
 (if main-resources
-(mapconcat
- (lambda (resource) (org-taskjuggler--build-resource resource 
info))
- main-resources "")
+   (concat
+(mapconcat
+ (lambda (resource) (org-taskjuggler--build-resource resource 
info))
+ main-resources "")
+;; Allow resource-tagged node have a 'post-includes' property,
+;; that will instruct the exporter to insert an include directive
+;; after all the resource sections.
+(let ((post-includes (apply 'concat
+(org-taskjuggler-map-special-nodes
+ org-taskjuggler-resource-tag tree
+ (lambda (hl) (org-element-property 
:POST-INCLUDES hl))
+  (when post-includes
+(apply 'concat (mapcar (lambda (inc) (format "include '%s'\n" 
inc))
+   (org-split-string post-includes))
   (format "resource %s \"%s\" {\n}\n" (user-login-name) 
user-full-name))
 ;; 5. Insert tasks.
-(let ((main-tasks
-   ;; If `org-taskjuggler-keep-project-as-task' is
-   ;; non-nil, there is only one task.  Otherwise, every
-   ;; direct children of PROJECT is a top level task.
-   (if org-taskjuggler-keep-project-as-task (list project)
- (or (org-element-map (org-element-contents project) 'headline
-   'identity info nil 'headline)
- (error "No task specified")
+(let* ((main-tasks
+   ;; If `org-taskjuggler-keep-project-as-task' is
+   ;; non-nil, there is only one task.  Otherwise, every
+   ;; direct children of PROJECT is a top level task.
+   (if org-taskjuggler-keep-project-as-task (list project)
+   (or (org-element-map (org-element-contents project) 
'headline
+ 'identity info nil 'headline)
+   (error "No task specified"
+  ;; Allow task-tagged node have a 'post-includes' property,
+  ;; that will instruct the exporter to insert an include directive
+  ;; after all the task sections.
+  (post-includes (mapconcat (lambda (hl) (org-element-property 
:POST-INCLUDES hl))
+main-tasks " ")))
   ;; Assign a unique ID to each task.  Add it to
   ;; `:taskjuggler-unique-ids' property in INFO.
   (setq info
@@ -694,9 +710,13 @@ Return complete project plan as a string in TaskJuggler 
syntax."
  (car main-tasks) :ALLOCATE
  (or (org-taskjuggler-get-id (car main-resources) info)
  (user-login-name
-  (mapconcat
-   (lambda (task) (org-taskjuggler--build-task task info))
-   main-tasks ""))
+ (concat
+  (mapconcat
+   (lambda (task) (org-taskjuggler--build-task task info))
+   main-tasks "")
+  (when post-includes
+(apply 'concat (mapcar (lambda (inc) (format "include '%s'\n" inc))
+   (org-split-string post-includes))
 ;; 6. Insert reports.  If no report is defined, insert default
 ;;reports.
 (let ((main-reports
-- 
2.5.0

[O] [PATCH 6/8] ox-taskjuggler.el: interpret 'allocate' as a multivalued-property

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler--build-task):  interpret 'allocate'
as a multivalued property, to pave the way for future completion-enabled
entry of this property.
---
 contrib/lisp/ox-taskjuggler.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 8036af3..44ffeb6 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -856,7 +856,7 @@ All valid attributes from TASK are inserted.  If TASK 
defines
 a property \"task_id\" it will be used as the id for this task.
 Otherwise it will use the ID property.  If neither is defined
 a unique id will be associated to it."
-  (let* ((allocate (org-element-property :ALLOCATE task))
+  (let* ((allocate (org-taskjuggler-multivalued-property :ALLOCATE task))
  (complete
   (if (eq (org-element-property :todo-type task) 'done) "100"
 (org-element-property :COMPLETE task)))
@@ -892,8 +892,8 @@ a unique id will be associated to it."
   (format "  purge %s\n  allocate %s\n"
   ;; Compatibility for previous TaskJuggler versions.
   (if (>= org-taskjuggler-target-version 3.0) "allocate"
-"allocations")
-  allocate))
+ "allocations")
+  (mapconcat 'identity allocate ", ")))
  (and complete (format "  complete %s\n" complete))
  (and effort
   (format "  effort %s\n"
-- 
2.5.0

[O] [PATCH 2/8] ox-taskjuggler.el: factor 'org-export-map-special-nodes'

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-map-special-nodes):
new function to capture mapping over tagged special nodes.
(org-taskjuggler-project-plan): factor to use the new function.
---
 contrib/lisp/ox-taskjuggler.el | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index ce4a8ab..2cf2c78 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -625,6 +625,12 @@ doesn't include leading \"depends\"."
 
 

 ;;; Translator Functions
+(defun org-taskjuggler-map-special-nodes (tag tree f)
+  (org-element-map tree 'headline
+(lambda (hl)
+  (and (member tag (org-export-get-tags hl info))
+  (funcall f hl)))
+info nil 'headline))
 
 (defun org-taskjuggler-project-plan (contents info)
   "Build TaskJuggler project plan.
@@ -647,13 +653,10 @@ Return complete project plan as a string in TaskJuggler 
syntax."
 ;; `org-taskjuggler-resource-tag'.  Only gather top level
 ;; resources.
 (apply 'append
-   (org-element-map tree 'headline
- (lambda (hl)
-   (and (member org-taskjuggler-resource-tag
-(org-export-get-tags hl info))
-(org-element-map (org-element-contents hl) 
'headline
-  'identity info nil 'headline)))
- info nil 'headline
+  (org-taskjuggler-map-special-nodes
+   org-taskjuggler-resource-tag tree
+   (lambda (hl) (org-element-map (org-element-contents hl) 
'headline
+  'identity info nil 'headline))
;; Assign a unique ID to each resource.  Store it under
;; `:taskjuggler-unique-ids' property in INFO.
(setq info
-- 
2.5.0

[O] [PATCH 8/8] ox-taskjuggler.el: allow trimming the task ID from its title

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-trim-ids-from-titles): new custom
(org-taskjuggler--build-task): trim task ids from titles, when the new
custom variable asks for this (enabled by default).
---
 contrib/lisp/ox-taskjuggler.el | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index d49db62..bca3dc1 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -374,6 +374,11 @@ task buckets, while still sharing the same resources pool."
   :group 'org-export-taskjuggler
   :type 'boolean)
 
+(defcustom org-taskjuggler-trim-ids-from-titles t
+  "Non-NIL trims the part detected as prefix from resulting task titles."
+  :group 'org-export-taskjuggler
+  :type 'boolean)
+
 
 

 ;;; Hooks
@@ -887,9 +892,16 @@ a unique id will be associated to it."
   (- org-lowest-priority 
org-highest-priority)
 (concat
  ;; Opening task.
- (format "task %s \"%s\" {\n"
- (org-taskjuggler-get-id task info)
- (org-taskjuggler-get-name task))
+ (let* ((id   (org-taskjuggler-get-id task info))
+   (raw-name (org-taskjuggler-get-name task))
+   (id-len   (length id))
+   (raw-name-len (length raw-name))
+   (name (if org-taskjuggler-trim-ids-from-titles
+ (if (= raw-name-len id-len)
+ raw-name
+ (subseq raw-name (1+ id-len)))
+ raw-name)))
+   (format "task %s \"%s\" {\n" id name))
  ;; Add default attributes.
  (and depends
   (format "  depends %s\n"
-- 
2.5.0

[O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler--build-task):  fix priority specification
by allowing it to be directly passed down, in case it parses as an integer.
---
 contrib/lisp/ox-taskjuggler.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 44ffeb6..d49db62 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -875,10 +875,16 @@ a unique id will be associated to it."
(org-taskjuggler-get-end task))
   (org-element-property :PERIOD task)
  (priority
-  (let ((pri (org-element-property :priority task)))
+  (let ((pri (org-element-property :PRIORITY task)))
 (and pri
- (max 1 (/ (* 1000 (- org-lowest-priority pri))
-   (- org-lowest-priority org-highest-priority)))
+;; The exported task priority can be either specified
+;; via the Org priority mechahism (which is currently broken),
+;; or it can be specified directly -- by providing it as an 
integer.
+(let ((integer-pri (ignore-errors (parse-integer pri
+  (or integer-pri
+  (max 1
+   (/ (* 1000 (- org-lowest-priority pri))
+  (- org-lowest-priority 
org-highest-priority)
 (concat
  ;; Opening task.
  (format "task %s \"%s\" {\n"
-- 
2.5.0

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Jonas Bernoulli]

> #+BEGIN_SRC emacs-lisp
>   (add-hook 'elisp-mode-hook 'turn-on-orgtbl)
>   (add-hook 'elisp-mode-hook
> (lambda ()
> (setq-local orgstruct-heading-prefix-regexp
> ";; ")))
> #+END_SRC

It appears the stupid thing I did was that I used ";;" instead.

Thanks for the help.

[O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-valid-task-attributes): add depends
to the list of valid task attributes
---
 contrib/lisp/ox-taskjuggler.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 2bd47e6..cfb28f2 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -301,7 +301,7 @@ but before any resource and task declarations."
   :type '(string :tag "Preamble"))
 
 (defcustom org-taskjuggler-valid-task-attributes
-  '(account start note duration endbuffer endcredit end
+  '(account depends start note duration endbuffer endcredit end
flags journalentry length limits maxend maxstart minend
minstart period reference responsible scheduling
startbuffer startcredit statusnote chargeset charge)
-- 
2.5.0

[O] [PATCH 1/8] ox-taskjuggler.el: allow direct 'leaves' specification

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-valid-resource-attributes): add leaves
to the list of valid resource attributes
---
 contrib/lisp/ox-taskjuggler.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index cfb28f2..ce4a8ab 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -327,7 +327,7 @@ list."
   :group 'org-export-taskjuggler)
 
 (defcustom org-taskjuggler-valid-resource-attributes
-  '(limits vacation shift booking efficiency journalentry rate
+  '(limits leaves vacation shift booking efficiency journalentry rate
   workinghours flags)
   "Valid attributes for Taskjuggler resources.
 If one of these appears as a property for a headline, it will be
-- 
2.5.0

[O] [PATCH 5/8] ox-taskjuggler.el: add 'org-taskjuggler-multivalued-property'

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler-multivalued-property): new function
to operate on multivalued properties.
---
 contrib/lisp/ox-taskjuggler.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 82aaa7e..8036af3 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -836,6 +836,16 @@ channel."
;; Closing report.
"}\n"))
 
+(defun org-taskjuggler-multivalued-property (property element)
+  "Obtain PROPERTY of ELEMENT, treating it as a multi-valued property.
+
+See `org-entry-get-multivalued-property' for details."
+  (let ((prop (org-element-property property element)))
+(and prop
+(mapcar 'org-entry-restore-space
+(org-split-string prop
+  "[ \t]")
+
 (defun org-taskjuggler--build-task (task info)
   "Return a task declaration.
 
-- 
2.5.0

[O] Spreadsheet error: invalid reference when using @> in range

[Karl Voit]

Hi!

| | 20 | 21 | 22 | 23 | 24 |
| | :=vsum(@3..@>) |||||
|-+++++|
| ||||||
|-+++++|
| |  1 |  1 |||  1 |
| Foo |  2 |||||
| Bar |||  2 |  3 ||
|-+++++|
| ||||||
|-+++++|
| Bar ||  4 |  1 |||
| Foo |||  2 ||  2 |
| Bar |||  3 |  5 ||
| Foo ||  1 |||  5 |
|-+++++|

I got: Spreadsheet error: invalid reference "vsum(@3..@>)" when I
try to apply the formula.

Also tried and also failed with same message:
vsum(@3$2..@>$2)
vsum(@I$2..@>$2)
vsum(@I+1$2..@>$2)

Working: 
vsum(@I$2..@11$2)
vsum(@I$2..@I$2)

So the problem seems to be the "@>" part.

Why can't I use the "@>" for "last row" in the formula?

Bonus question: when I want to apply the formula to @2$2 and *all*
table elements rights of it until the last column, is there a way to
define this without having five separate formula?

Thanks!

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] [PATCH] ox-html.el ox.el: added list of figures support in html backend

[Joost Helberg]

Hi,

this patch adds the list of figures to the html export backend. It also
includes a translation entry-point for the label "List of Figures" with
already one translation in: dutch.

>From fab9105d04e5cb9f923c17d322d84a25527ec27a Mon Sep 17 00:00:00 2001
From: Joost Helberg 
Date: Sun, 8 Nov 2015 14:34:11 +0100
Subject: [PATCH] ox-html.el: added list of figures support in html backend

* lisp/ox-html.el (org-html-list-of-figures): new, similar to
org-html-list-of-tables but with tables replaced by figures.
(org-html-list-of-tables): added mapping keyword "figures"
to new function org-html-list-of-figures.

ox.el: added label for "list of figures"

* lisp/ox.el (org-export-dictionary): Added label for List of
Figures with dutch translation
---
 lisp/ox-html.el | 36 
 lisp/ox.el  |  2 ++
 2 files changed, 38 insertions(+)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index effd387..3a7d7a1 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2251,6 +2251,41 @@ of listings as a string, or nil if it is empty."
 		 lol-entries "\n"))
 	  "\n\n\n"
 
+(defun org-html-list-of-figures (info)
+  "Build a list of figures.
+INFO is a plist used as a communication channel.  Return the list
+of figures as a string, or nil if it is empty."
+  (let ((lol-entries (org-export-collect-figures info nil)))
+(when lol-entries
+  (concat "\n"
+	  (format "%s\n"
+		  org-html-toplevel-hlevel
+		  (org-html--translate "List of Figures" info)
+		  org-html-toplevel-hlevel)
+	  "\n\n"
+	  (let ((count 0)
+		(initial-fmt (format "%s"
+	 (org-html--translate "Figure %d:" info
+		(mapconcat
+		 (lambda (entry)
+		   (let ((label (org-element-property :name entry))
+			 (title (org-trim
+ (org-export-data
+  (or (org-export-get-caption entry t)
+  (org-export-get-caption entry))
+  info
+		 (concat
+		  ""
+		  (if (not label)
+			  (concat (format initial-fmt (incf count)) " " title)
+			(format "%s %s"
+(org-export-solidify-link-text label)
+(format initial-fmt (incf count))
+title))
+		  "")))
+		 lol-entries "\n"))
+	  "\n\n\n"
+
 (defun org-html-list-of-tables (info)
   "Build a list of tables.
 INFO is a plist used as a communication channel.  Return the list
@@ -2654,6 +2689,7 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 		(localp (org-string-match-p "\\" value)))
 	(org-html-toc depth info (and localp keyword
 	 ((string= "listings" value) (org-html-list-of-listings info))
+	 ((string= "figures" value) (org-html-list-of-figures info))
 	 ((string= "tables" value) (org-html-list-of-tables info
 
  Latex Environment
diff --git a/lisp/ox.el b/lisp/ox.el
index a37de04..f00469f 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5561,6 +5561,8 @@ them."
   :utf-8 "Примітки")
  ("zh-CN" :html "" :utf-8 "脚注")
  ("zh-TW" :html "" :utf-8 "腳註"))
+("List of Figures"
+ ("nl" :default "Figuren"))
 ("List of Listings"
  ("da" :default "Programmer")
  ("de" :default "Programmauflistungsverzeichnis")
-- 
1.9.1


regards,

Joost

-- 
Snow B.V.

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Jonas Bernoulli]

Aaron Ecay  writes:

> Thorsten Jolitz wrote the outshine library

I know. I used it for a while and contributed a few commits.  But I
pretty much only used the cycling functionality at the time and when
I discovered that `org-cycle' worked for that too, I stopped using
outshine.  It also felt a bit like re-inventing the wheel.

> Sadly it’s not actively maintained ATM, but I believe it still works
> fine,

That's a bit of an understatement; if I remember correctly Thorsten
stopped using Emacs.

> and it may be an alternative route towards the features you are
> looking for.

Well currently I am just using `org-cycle' + `outline-minor-mode', which
works well enough for now.  But eventually I would like to also start
using Org's navigational commands.  Unfortunately `orgstruct-mode' only
supports org-like headings (;; * heading\n;; ** subheadng) and not
standard Emacs headings (;;; heading\n subheading).  I hope someone
teaches `orgstruct-mode' to support the latter too.  Otherwise I will
probably give `outshine' another chance.

  But thanks for the tip :-)
  Jonas

Re: [O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer

[Aaron Ecay]

Hi Kosyrev,

2015ko azaroak 8an, Kosyrev Serge-ek idatzi zuen:
> 
> * ox-taskjuggler.el (org-taskjuggler--build-task):  fix priority specification
> by allowing it to be directly passed down, in case it parses as an integer.
> ---
>  contrib/lisp/ox-taskjuggler.el | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
> index 44ffeb6..d49db62 100644
> --- a/contrib/lisp/ox-taskjuggler.el
> +++ b/contrib/lisp/ox-taskjuggler.el
> @@ -875,10 +875,16 @@ a unique id will be associated to it."
> (org-taskjuggler-get-end task))
>(org-element-property :PERIOD task)
>   (priority
> -  (let ((pri (org-element-property :priority task)))
> +  (let ((pri (org-element-property :PRIORITY task)))
>  (and pri
> - (max 1 (/ (* 1000 (- org-lowest-priority pri))
> -   (- org-lowest-priority org-highest-priority)))
> +;; The exported task priority can be either specified
> +;; via the Org priority mechahism (which is currently 
> broken),

Can you say more about what breakage you mean?  Is it something that can
be easily fixed?

Thanks,

-- 
Aaron Ecay

Re: [O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification

[Aaron Ecay]

Hi Kosyrev,

2015ko azaroak 8an, Kosyrev Serge-ek idatzi zuen:
> 
> * ox-taskjuggler.el (org-taskjuggler-valid-task-attributes): add depends
> to the list of valid task attributes
> ---
>  contrib/lisp/ox-taskjuggler.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
> index 2bd47e6..cfb28f2 100644
> --- a/contrib/lisp/ox-taskjuggler.el
> +++ b/contrib/lisp/ox-taskjuggler.el
> @@ -301,7 +301,7 @@ but before any resource and task declarations."
>:type '(string :tag "Preamble"))
>  
>  (defcustom org-taskjuggler-valid-task-attributes

Is this an open-ended list that an average user could meaningfully add
to?  If not, perhaps it should be a defconst.  (I don’t know anything
about the taskjuggler format, so I’m sure whatever decision you make
will be OK.)

-- 
Aaron Ecay

[O] [PATCH 4/8] ox-taskjuggler.el: :PROJECT-{END, DURATION} project attribute

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler--build-project): Allow the project
end and duration to be specified via properties of the root node.
---
 contrib/lisp/ox-taskjuggler.el | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 427fb6e..82aaa7e 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -765,10 +765,13 @@ days from now."
   org-taskjuggler-default-project-version)
   (or (org-taskjuggler-get-start project)
   (format-time-string "%Y-%m-%d"))
-  (let ((end (org-taskjuggler-get-end project)))
+  ;; The 'project-end' and 'project-duration' root node properties 
allow
+  ;; the project end date / duration to be specified directly in the 
Org file.
+  (let ((end  (org-element-property :PROJECT-END project))
+(duration (org-element-property :PROJECT-DURATION project)))
 (or (and end (format "- %s" end))
-(format "+%sd"
-org-taskjuggler-default-project-duration
+(and duration (format "+%s" duration))
+(format "+%sd" org-taskjuggler-default-project-duration
;; Add attributes.
(org-taskjuggler--indent-string
 (org-taskjuggler--build-attributes
-- 
2.5.0

[O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer

[Kosyrev Serge]

* ox-taskjuggler.el (org-taskjuggler--build-task):  fix priority specification
by allowing it to be directly passed down, in case it parses as an integer.
---
 contrib/lisp/ox-taskjuggler.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 44ffeb6..d49db62 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -875,10 +875,16 @@ a unique id will be associated to it."
(org-taskjuggler-get-end task))
   (org-element-property :PERIOD task)
  (priority
-  (let ((pri (org-element-property :priority task)))
+  (let ((pri (org-element-property :PRIORITY task)))
 (and pri
- (max 1 (/ (* 1000 (- org-lowest-priority pri))
-   (- org-lowest-priority org-highest-priority)))
+;; The exported task priority can be either specified
+;; via the Org priority mechahism (which is currently broken),
+;; or it can be specified directly -- by providing it as an 
integer.
+(let ((integer-pri (ignore-errors (parse-integer pri
+  (or integer-pri
+  (max 1
+   (/ (* 1000 (- org-lowest-priority pri))
+  (- org-lowest-priority 
org-highest-priority)
 (concat
  ;; Opening task.
  (format "task %s \"%s\" {\n"
-- 
2.5.0