Re: [O] bug in org-habits

2015-11-04 Thread John Wiegley
> Bastien Guerry  writes:

> I think Achim's points above are very valid, and the flexibility offered by
> the option above should be very carefully examined.

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.

John



[O] org-capture-template: file+datetree+prompt not using prompted date in template

2015-11-04 Thread Shankar Rao
For the following org capture template:

(setq org-capture-templates
  '(("d" "Date Tree Test" plain
(file+datetree+prompt "~/org/testdt.org")
"This date should be the date i picked: %<%y%m%d>")))

Though this is filed under the correct date in the datetree, no matter what
date I select in the prompt, the date displayed in the template is the
current date. Is this a bug or a feature?

How do I use the prompt-selected date in the template?

Shankar


Re: [O] org-capture-template: file+datetree+prompt not using prompted date in template

2015-11-04 Thread Shankar Rao
Earlier in org-capture-fill-template, there is the following:

(let* (...
   (ct (org-capture-get :default-time))
   ...

The property :default-time defaults to the current time and is overwritten
by file+datetree+prompt,

If ct was passed as a 2nd argument to format-time-string in your code
snippet:

  ;; The current time
  (goto-char (point-min))
  (while (re-search-forward "%<\\([^>\n]+\\)>" nil t)
(replace-match (format-time-string (match-string 1) ct) t t))

this should provide the behavior I'm looking for with file+datetree+prompt,
but still use the current time for other capture types. Will this solution
break anything?

Shankar

On Wed, Nov 4, 2015 at 2:15 PM, Nick Dokos  wrote:

> Shankar Rao  writes:
>
> > For the following org capture template:
> >
> > (setq org-capture-templates
> >   '(("d" "Date Tree Test" plain
> > (file+datetree+prompt "~/org/testdt.org")
> > "This date should be the date i picked: %<%y%m%d>")))
> >
> > Though this is filed under the correct date in the datetree, no matter
> what date I select in the prompt,
> > the date displayed in the template is the current date. Is this a bug or
> a feature?
> >
>
> It's a feature I guess - org-capture.el says:
>
>   ;; The current time
>   (goto-char (point-min))
>   (while (re-search-forward "%<\\([^>\n]+\\)>" nil t)
> (replace-match (format-time-string (match-string 1)) t t))
>
> and there is no provision for another time to be given here. I don't
> think there is any provision in the template for a time other than the
> current time: at least I can't see a %-escape that takes a different
> time.
>
> --
> Nick
>
>
>


Re: [O] org-capture-template: file+datetree+prompt not using prompted date in template

2015-11-04 Thread Nick Dokos
Shankar Rao  writes:

> For the following org capture template:
>
> (setq org-capture-templates
>       '(("d" "Date Tree Test" plain
> (file+datetree+prompt "~/org/testdt.org")
> "This date should be the date i picked: %<%y%m%d>")))
>
> Though this is filed under the correct date in the datetree, no matter what 
> date I select in the prompt,
> the date displayed in the template is the current date. Is this a bug or a 
> feature?
>

It's a feature I guess - org-capture.el says:

  ;; The current time
  (goto-char (point-min))
  (while (re-search-forward "%<\\([^>\n]+\\)>" nil t)
(replace-match (format-time-string (match-string 1)) t t))

and there is no provision for another time to be given here. I don't
think there is any provision in the template for a time other than the
current time: at least I can't see a %-escape that takes a different
time.

--
Nick




Re: [O] contributing to work on citations

2015-11-04 Thread Matt Price
On Wed, Nov 4, 2015 at 10:18 AM, Aaron Ecay  wrote:

> Hi Matt,
>
> Thanks for your willingness to help with the project.
>
> 2015ko urriak 30an, Matt Price-ek idatzi zuen:
> >
> > So, from the "some projects" thread I have the sense there is a group of
> > users with some interest in improving citation support. What is the best
> > way to kickstart that process? it seems to me that, at a minimum, the
> > following is needed:
> >
> > 1. Finalization of the citation syntax.
> >
> > IIUC, This involves refining and merging the work in the wip-cite git
> > branch.
>
> There was a very voluminous discussion on this last time.  Lots of
> people proposed various additions.  I’d be inclined to go with whatever
> syntax is implemented currently, and let any needed extensions sort
> themselves out through real-world testing.
>

OK, great.  Does this mean just checking out the org-wip-cite branch? Or
has someone perhaps merged more recent changes into wip-cite somewhere
else?

>
> >
> > 2. Choice of a citation creation tool
> >
> > IIUC, the two main candidates are pandoc-citeproc and citeproc-js/node.
> > Pandoc-citeproc works well but requires users to install the whole pandoc
> > infrastructure, and needs to be wrapped in a thin tool for use with org.
> > Citeproc-node has fewer dependencies (I guess), but needs to be updated
> to
> > support additional output formats (e.g. latex, odt, and org) and is a
> > little more elaborate to run from the command line (runs as a service,
> can
> > only be communicated with over http).
>
> IIUC, citeproc-node just wraps citeproc-js, which has a “normal” API.
> So it should be possible to write a CLI wrapper for citeproc-js.  (But I
> have not studied citeproc-js at all, so I could be wrong).
>

I am not sure but I don't think it's trivial; and alas i am slow at eveyr
kind of coding, but I will certainly look into this.

>
> My plan is to create preliminary citation support based on Richard’s
> haskell tool, with the intention of moving to a JS-based tool when
> possible.  So implementing a work-alike of Richard’s tool in JS would be
> a good development.
>
>
OK, I'll pay more attention to Richard's tool and how it works, with the
goal of making something like a drop-in replacement.

> >
> > 3. Handling of citation links in the various export engines
> > Functions must be written to handle citations in, at minimum, latex,
> html,
> > and org
> >
> > 4. Interface with backends
> > Org should be able to talk to bibtex and zotero databases, at least (and
> > maybe more).
>
> The code I wrote should have enough hooks to enable this.  But I haven’t
> looked at zotero at all.  If zotero support is important to you, you
> could investigate the “lookup types” in the citation code I wrote, see
> if they are adequate, and try to use them to implement zotero lookup.
> From the docstring:
>
> "Types of citation lookup backends.
>
> Alist from type to list of:
>
> - Function called at the beginning of export, with the rest of
>   the keyword line after #+BIBDB: type, and the info plist.
>   Should cache whatever it needs in the info plist.
>
> - Function to lookup a citation.  Called with the key and the
>   info plist.  Will be memoized by
>   `org-export-cite--lookup' (TODO).  Should return an alist of
>   keys and values about the citation (author, year, title, etc.)
>
> - A boolean; non-nil = this lookup type is remote.  All local
>   lookups will be tried before any remote one is.
>   TODO: not yet implemented"
>
>
I'll start here.  Thanks for the pointer.


> >
> > A lot of this work has already been done. Richard has written
> org-citeproc
> > as a wrapper for pandoc-citeproc https://github.com/wyleyr/org-citeproc
> .
> > Aaron has written some functions for org-citeproc in the wip-cite-awe
> > branch. Nicolas has developed the syntax in wip-cite. I even have a fork
> of
> > citeproc-node that could be used to develop the missing features we need.
> > And of course John has org-ref (
> >
> http://kitchingroup.cheme.cmu.edu/blog/2014/05/13/Using-org-ref-for-citations-and-references/
> )
>
> The org-ref features provide a good aspirational horizon for us, I think.
> I.e. org’s core should aim to support almost all of them eventually.  But
> the support for citation syntax is not so far along that creating such
> support is an immediate prospect.
>
> > while Erik H has zotxt-emacs for Zotero integration (
> > https://github.com/egh/zotxt-emacs).
> >
> > What would be the best next move? It seems to me there are enough moving
> > parts that the process will be quite a bit easier if we co-ordinate.
>
> Based on the interests you’ve expressed, I think working on the JS
> citation processor and/or zotero integration would be good contributions
> you can make.  But you can work on other things as well.  I think the
> best way to coordinate will be to keep the list apprised of your
> progress.  If you have push access, you can push WIP code as branches in
> the 

Re: [O] Adding new switch or header

2015-11-04 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> On Tuesday,  3 Nov 2015 at 21:57, Phillip Lord wrote:
>
> [...]
>
>> Are these form of attributes specific to the source block which they
>> precede? Or is it possible to do any kind of inheritance with them? For
>> my use case, all the code blocks inside a Header One block will behave
>> in the same way (either with \[ escaping or without).
>
> No idea!  Maybe Nicolas can help here as I assume this is all a function
> of the parser.

Attributes apply to the block below. However, with a parse tree filter,
it is possible to find a block with some attribute and apply the same
attribute to all blocks in the same level one heading.


Regards,

-- 
Nicolas Goaziou



Re: [O] problems with export and :cache

2015-11-04 Thread Nicolas Goaziou
Hello,

Aaron Ecay  writes:

> See the attached patch.  I’ve tried to put all my experience and best
> practices in there; comments are welcome of course.

Thank you. It looks good. Some comments follow.

> +unchanged code blocks.  When the cache is active, a source block is not
> +re-evaluated if a result for it is present in the buffer and neither the
> +header arguments (including the value of @code{:var} references) nor the text
> +of the block itself has changed since the result was computed.  The feature
> +helps avoid re-running long calculations.  However, there are edge cases and
> +you should not rely on the cache to behave reliably in all circumstances.
> +
> +The caching feature works best when a babel block is a pure function of its
> +arguments (see @ref{var}).  That is, the function always returns the
> same

  (see @ref{var}) => (@pxref{var})

> +results when given the same arguments, and does not touch external resources
> +(like the filesystem or the language’s RNG) in any way.
> +
> +The documentation of the knitr reproducible research package for the R
> +language has some good discussion of issues that may arise when using the
> +cache in such a context.  See @uref{http://yihui.name/knitr/demo/cache/},
> +especially the sections “Even more stuff for cache?” and “Reproducibility
> +with RNG”.

Shouldn't this be : ``Even more stuff for cache?''. Ditto for the other
title.

> (Obviously, you will have to abstract away from the knitr
> +implementation details which the documentation also discusses.)

I think this last paragraph could go in a footnote at the end of the
paragraph before it.

> +Note that the @code{:cache} header argument will attempt to cache results
> +when the @code{:session} header argument is used, even though the results of
> +the code block execution stored in the session may lead to unexpected
> +results.
> +
> +Noweb references (see @ref{Noweb reference syntax}) are currently not

(see @ref{Noweb reference syntax}) => (@pxref{Noweb reference syntax})

> +expanded when calculating whether the text of the code block has changed.
> +Perhaps in principle they ought to be, but this could introduce unexpected
> +complexity.  See @uref{http://thread.gmane.org/gmane.emacs.orgmode/79046}.
> +
> +The @code{:cache} header argument can have one of two values: @code{yes} or
> +@code{no}.

Regards,

-- 
Nicolas Goaziou



[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically

2015-11-04 Thread Emanuel Evans
Apologies if this is a dupe; I think some of my posts aren't getting
through to the list (I just subscribed, so hopefully that will help).

Glenn Morris  writes:

> Nope, just a mailing list AFAIK. Assigning something to the debbugs
> org-mode package (which I already did for this report) sends stuff there.

Great, is there anything else I should do from my end to make sure it
gets to the org mailing list? (I looked for the original post there and
didn't see it.)






Re: [O] ox-html HOWTO? exporting #+RESULTS inside div

2015-11-04 Thread Cook, Malcolm
Charles,

Thanks again for you suggestion.

Alas, using 'header-args :wrap org-results-container' has the unforeseen (by 
me) side effect of masking my use of `#+ATTR_HTML :class dataTable` on selected 
exported tables (which I use to allow for search/sortable/scrollable tables).  

Now, the ':class dataTable' attribute is placed on the new  instead of the 
 with undesired outcome.

Do you have any thoughts on how to accomplish both my goals (apply :class table 
to selected results, and making ALL results be addressable using javascript.  
FYI - My application is to hide all source blocks on html open.  Clicking on a 
source block caption shows the source.  This provides an HTML view that hides 
the source until desired.  My recipients of such analysis write-ups really like 
this.

Thanks,
Malcolm

PS: as an Example of the issue, the following exports the table with :class of 
dataTable.  However, when I uncomment the :wrap directive, and re-eval the 
block, and export, then :class is now on the div...


#+HTML_HEAD: http://code.jquery.com/jquery-1.11.2.min.js";>
#+HTML_HEAD: http://cdn.datatables.net/1.10.9/css/jquery.dataTables.min.css;>
#+HTML_HEAD: http://cdn.datatables.net/1.10.9/js/jquery.dataTables.js";>
#
# #+PROPERTY: header-args :wrap org-results-container
#
#+CAPTION: Contrive to display mtcars
#+BEGIN_SRC R :exports both :results value :colnames yes 
mtcars
#+END_SRC
#+ATTR_HTML: :class dataTable 
#+RESULTS:
|  mpg | cyl |  disp |  hp | drat |wt |  qsec | vs | am | gear | carb |
|--+-+---+-+--+---+---+++--+--|
|   21 |   6 |   160 | 110 |  3.9 |  2.62 | 16.46 |  0 |  1 |4 |4 |
|   21 |   6 |   160 | 110 |  3.9 | 2.875 | 17.02 |  0 |  1 |4 |4 |
| 22.8 |   4 |   108 |  93 | 3.85 |  2.32 | 18.61 |  1 |  1 |4 |1 |
| 21.4 |   6 |   258 | 110 | 3.08 | 3.215 | 19.44 |  1 |  0 |3 |1 |
| 18.7 |   8 |   360 | 175 | 3.15 |  3.44 | 17.02 |  0 |  0 |3 |2 |
| 18.1 |   6 |   225 | 105 | 2.76 |  3.46 | 20.22 |  1 |  0 |3 |1 |
| 14.3 |   8 |   360 | 245 | 3.21 |  3.57 | 15.84 |  0 |  0 |3 |4 |
| 24.4 |   4 | 146.7 |  62 | 3.69 |  3.19 |20 |  1 |  0 |4 |2 |
| 22.8 |   4 | 140.8 |  95 | 3.92 |  3.15 |  22.9 |  1 |  0 |4 |2 |
| 19.2 |   6 | 167.6 | 123 | 3.92 |  3.44 |  18.3 |  1 |  0 |4 |4 |
| 17.8 |   6 | 167.6 | 123 | 3.92 |  3.44 |  18.9 |  1 |  0 |4 |4 |
| 16.4 |   8 | 275.8 | 180 | 3.07 |  4.07 |  17.4 |  0 |  0 |3 |3 |
| 17.3 |   8 | 275.8 | 180 | 3.07 |  3.73 |  17.6 |  0 |  0 |3 |3 |
| 15.2 |   8 | 275.8 | 180 | 3.07 |  3.78 |18 |  0 |  0 |3 |3 |
| 10.4 |   8 |   472 | 205 | 2.93 |  5.25 | 17.98 |  0 |  0 |3 |4 |
| 10.4 |   8 |   460 | 215 |3 | 5.424 | 17.82 |  0 |  0 |3 |4 |
| 14.7 |   8 |   440 | 230 | 3.23 | 5.345 | 17.42 |  0 |  0 |3 |4 |
| 32.4 |   4 |  78.7 |  66 | 4.08 |   2.2 | 19.47 |  1 |  1 |4 |1 |
| 30.4 |   4 |  75.7 |  52 | 4.93 | 1.615 | 18.52 |  1 |  1 |4 |2 |
| 33.9 |   4 |  71.1 |  65 | 4.22 | 1.835 |  19.9 |  1 |  1 |4 |1 |
| 21.5 |   4 | 120.1 |  97 |  3.7 | 2.465 | 20.01 |  1 |  0 |3 |1 |
| 15.5 |   8 |   318 | 150 | 2.76 |  3.52 | 16.87 |  0 |  0 |3 |2 |
| 15.2 |   8 |   304 | 150 | 3.15 | 3.435 |  17.3 |  0 |  0 |3 |2 |
| 13.3 |   8 |   350 | 245 | 3.73 |  3.84 | 15.41 |  0 |  0 |3 |4 |
| 19.2 |   8 |   400 | 175 | 3.08 | 3.845 | 17.05 |  0 |  0 |3 |2 |
| 27.3 |   4 |79 |  66 | 4.08 | 1.935 |  18.9 |  1 |  1 |4 |1 |
|   26 |   4 | 120.3 |  91 | 4.43 |  2.14 |  16.7 |  0 |  1 |5 |2 |
| 30.4 |   4 |  95.1 | 113 | 3.77 | 1.513 |  16.9 |  1 |  1 |5 |2 |
| 15.8 |   8 |   351 | 264 | 4.22 |  3.17 |  14.5 |  0 |  1 |5 |4 |
| 19.7 |   6 |   145 | 175 | 3.62 |  2.77 |  15.5 |  0 |  1 |5 |6 |
|   15 |   8 |   301 | 335 | 3.54 |  3.57 |  14.6 |  0 |  1 |5 |8 |
| 21.4 |   4 |   121 | 109 | 4.11 |  2.78 |  18.6 |  1 |  1 |4 |2 |



 > -Original Message-
 > From: emacs-orgmode-bounces+mec=stowers@gnu.org [mailto:emacs-
 > orgmode-bounces+mec=stowers@gnu.org] On Behalf Of Cook, Malcolm
 > Sent: Thursday, October 22, 2015 1:14 AM
 > To: Charles C. Berry 
 > Cc: emacs-orgmode@gnu.org
 > Subject: Re: [O] ox-html HOWTO? exporting #+RESULTS inside div
 > 
 > Charles,
 > 
 > Excellent - that is precisely what I needed.
 > 
 > Additionally, I can avoid having to include the :wrap keyword on every header
 > by specifying a single  buffer-wide  header arguments, such as
 > 
 > #+PROPERTY: header-args :wrap org-results-container
 > 
 > Thanks,
 > 
 > ~ malcolm_c...@stowers.org
 > 
 > 
 > From: Charles C. Berry 
 > Sent: Wednesday, October 21, 2015 9:18 PM
 > To: Cook, Malcolm
 > Cc: emacs-orgmode@gnu.org
 > Subject: Re: ox-html HOWTO? exporting #+RESULTS inside div
 > 
 > On Wed, 21 

Re: [O] Favorite contrib/ packages?

2015-11-04 Thread Samuel Wales
mouse
capture
link minor mode

dunno which are contrib



[O] Capture and use export header numbering?

2015-11-04 Thread Lawrence Bottorff
When an outline tree of headers

* top 1
** something
** something
** something
*** something
 something
* something
** something

is exported, say, to html, org-mode produces a numerical outline as deep as
the options are set

1. top
1.1. something
1.2. something
1.3. something
1.3.1. something
1.3.1.1. something
1.3.1.1.1. something
1.3.1.1.1.1. something


Now, is there any way to actually capture that outline numeration for use
in the original buffer? I'm thinking I would like to make a sort of tags or
custom_id  system based on these numbers.

* top :1:
** something :1.1:
** something :1.2:
** something :1.3:
*** something :1.3.1:
 something :1.3.1.1:
* something :1.3.1.1.1:
** something :1.3.1.1.1.1:

It would also be nice if org-mode simply used these numbers in the original
buffer instead of stars.

LB


[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically

2015-11-04 Thread Emanuel Evans
Apologies if this is a dupe; I think some of my posts aren't getting
through to the list (I just subscribed, so hopefully that will help).

Glenn Morris  writes:

> Nope, just a mailing list AFAIK. Assigning something to the debbugs
> org-mode package (which I already did for this report) sends stuff there.

Great, is there anything else I should do from my end to make sure it
gets to the org mailing list? (I looked for the original post there and
didn't see it.)





Re: [O] org-capture-template: file+datetree+prompt not using prompted date in template

2015-11-04 Thread Shankar Rao
Looks like a similar issue was addressed earlier here:

http://sachachua.com/blog/2015/02/org-mode-reusing-date-file-datetree-prompt/

Shankar

On Wed, Nov 4, 2015 at 2:54 PM, Shankar Rao  wrote:

> Earlier in org-capture-fill-template, there is the following:
>
> (let* (...
>(ct (org-capture-get :default-time))
>...
>
> The property :default-time defaults to the current time and is overwritten
> by file+datetree+prompt,
>
> If ct was passed as a 2nd argument to format-time-string in your code
> snippet:
>
>   ;; The current time
>   (goto-char (point-min))
>   (while (re-search-forward "%<\\([^>\n]+\\)>" nil t)
> (replace-match (format-time-string (match-string 1) ct) t t))
>
> this should provide the behavior I'm looking for with
> file+datetree+prompt, but still use the current time for other capture
> types. Will this solution break anything?
>
> Shankar
>
> On Wed, Nov 4, 2015 at 2:15 PM, Nick Dokos  wrote:
>
>> Shankar Rao  writes:
>>
>> > For the following org capture template:
>> >
>> > (setq org-capture-templates
>> >   '(("d" "Date Tree Test" plain
>> > (file+datetree+prompt "~/org/testdt.org")
>> > "This date should be the date i picked: %<%y%m%d>")))
>> >
>> > Though this is filed under the correct date in the datetree, no matter
>> what date I select in the prompt,
>> > the date displayed in the template is the current date. Is this a bug
>> or a feature?
>> >
>>
>> It's a feature I guess - org-capture.el says:
>>
>>   ;; The current time
>>   (goto-char (point-min))
>>   (while (re-search-forward "%<\\([^>\n]+\\)>" nil t)
>> (replace-match (format-time-string (match-string 1)) t t))
>>
>> and there is no provision for another time to be given here. I don't
>> think there is any provision in the template for a time other than the
>> current time: at least I can't see a %-escape that takes a different
>> time.
>>
>> --
>> Nick
>>
>>
>>
>


Re: [O] ox-html HOWTO? exporting #+RESULTS inside div

2015-11-04 Thread Charles C. Berry

On Wed, 4 Nov 2015, Cook, Malcolm wrote:


Charles, Thanks again for you suggestion.  Alas, using 'header-args
:wrap org-results-container' has the unforeseen (by me) side effect
of masking my use of `#+ATTR_HTML :class dataTable` on selected
exported tables (which I use to allow for search/sortable/scrollable
tables).  Now, the ':class dataTable' attribute is placed on the new
 instead of the  with undesired outcome.



Do you have any thoughts on how to accomplish both my goals (apply
:class table to selected results, and making ALL results be
addressable using javascript.  FYI - My application is to hide all
source blocks on html open.  Clicking on a source block caption
shows the source.  This provides an HTML view that hides the source
until desired.  My recipients of such analysis write-ups really like
this.


[snip]


# #+PROPERTY: header-args :wrap org-results-container
#


This creates a special block and attributes on the results will apply
to it - not its contents.

What you want can be obtained by creating a different special block
and then applying a filter. So, wrap like this

#+PROPERTY: header-args :wrap org-results-container-to-filter

and add a filter to `org-export-filter-special-block-functions' that 
strips the 'to-filter' and adds the `dataTable' where it is needed.


HTH,

Chuck



Re: [O] contributing to work on citations

2015-11-04 Thread William Denton

On 4 November 2015, Will Monroe wrote:


As someone who uses Zotero and org-mode quite a bit, I'd be glad to help
with testing, if that would be useful.  I'm learning Elisp but I'm still
a beginner.  Nevertheless, I have a keen interest in bringing together
these tools.


Same here---I'm glad to test.

Bill
--
William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/

Re: [O] contributing to work on citations

2015-11-04 Thread John Wiegley
> Will Monroe  writes:

> As someone who uses Zotero and org-mode quite a bit, I'd be glad to help
> with testing, if that would be useful. I'm learning Elisp but I'm still a
> beginner. Nevertheless, I have a keen interest in bringing together these
> tools.

Me too, I'm a fan and active user of both tools as well.

John



Re: [O] contributing to work on citations

2015-11-04 Thread Will Monroe
Aaron, Matt:

> Based on the interests you’ve expressed, I think working on the JS
> citation processor and/or zotero integration would be good contributions
> you can make.  But you can work on other things as well.  I think the
> best way to coordinate will be to keep the list apprised of your
> progress.

As someone who uses Zotero and org-mode quite a bit, I'd be glad to help
with testing, if that would be useful.  I'm learning Elisp but I'm still
a beginner.  Nevertheless, I have a keen interest in bringing together
these tools.

All the best,

Will



Re: [O] [PATCH 3/9] org-clock: fix `org-clock-time%'

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> This could be converted to dolist while you’re here (I realize you
> didn’t touch this line).

Ok.

>> -  (if (string-match "\\([0-9]+\\):\\([0-9]+\\)" s)
>> -  (throw 'exit
>> - (/ (* 100.0 (+ (string-to-number (match-string 2 s))
>> -(* 60 (string-to-number
>> -   (match-string 1 s)
>> -tot
>> -0
>> +  (setq cur (org-clocksum-string-to-minutes s))
>> +  (if (not (equal cur nil)) (throw 'exit (/ (* 100.0 cur) tot

Ok.



Re: [O] [PATCH 5/9] rename `org-duration-string-to-minutes' to `org-clocksum-string-to-minutes' everywhere

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> You can use ‘define-obsolete-function-alias’.

Ok.



Re: [O] problems with export and :cache

2015-11-04 Thread Aaron Ecay
Hi Nicolas,

2015ko azaroak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> If this means “can it ever work?” then I think the answer is “yes it
>> can”.  But I think the current implementation is broken and likely to
>> remain so for the foreseeable future.  The issues are:
>> 
>> 1. :cache only works for code which is a pure function of its header args
>> 2. When combined with :session, the environment that the code is evaluated
>> in is not created anew each time it is run.  This makes it much easier
>> to leak references to (e.g.) variables defined in other blocks
>> 3. The proper notion of purity is not easily defined when the code does
>> things like modifying the emacs environment, touching the filesystem,
>> or accessing the language’s RNG.
>> 4. We (org devs) don’t actually understand how the semantics of cache
>> interacts with other babel features.  See:
>> .
>> 
>> 1-3 are likely to be extremely confusing for users, especially less
>> technically sophisticated ones (what’s a “pure function” anyway)?  The
>> inability to give a clear introductory explanation of the feature in
>> combination with 4 indicating we don’t actually understand it ourselves
>> makes me feel like we should not be advertising, let alone recommending,
>> it.
>> 
>> The only other literate programming environment that I know of that
>> implements such a feature is knitr (for R).  They address these issues
>> by providing (optional) free-variable analysis to construct a dependency
>> graph between code blocks.  There is also some handling of RNG seed
>> values.  The documentation  is much
>> more comprehensive, including a prominent statement about the dangers of
>> side effect-ful code and a nuanced discussion of several issues,
>> including the RNG.
> 
> Thank you for the explanations.
> 
> Assuming the user knows what s?he is doing (so I'm not bothered by
> issues 2 and 3), :cache is still a somewhat useful feature. I don't mind
> advertising it. Though, I agree we could include big fat warnings about
> it in the manual.

See the attached patch.  I’ve tried to put all my experience and best
practices in there; comments are welcome of course.

> 
> Also, :cache might be a bit misleading as it implies more than what this
> feature offer, i.e., a dumb "don't update results if contents didn't
> change". I cannot think of a better name, tho.

There are backwards compatibility implications to renaming the header,
of course.  (And I can’t think of a better name either).

Thanks,

-- 
Aaron Ecay
>From bb0f43948384448225323abcfe7a662d110d1389 Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Wed, 4 Nov 2015 11:57:49 +
Subject: [PATCH] babel: update the manual wrt :cache header arg

* doc/org.texi (cache): Update manual section.
---
 doc/org.texi | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index ba402bf..48ae017 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -16166,11 +16166,37 @@ used.
 
 The @code{:cache} header argument controls the use of in-buffer caching of
 the results of evaluating code blocks.  It can be used to avoid re-evaluating
-unchanged code blocks.  Note that the @code{:cache} header argument will not
-attempt to cache results when the @code{:session} header argument is used,
-because the results of the code block execution may be stored in the session
-outside of the Org mode buffer.  The @code{:cache} header argument can have
-one of two values: @code{yes} or @code{no}.
+unchanged code blocks.  When the cache is active, a source block is not
+re-evaluated if a result for it is present in the buffer and neither the
+header arguments (including the value of @code{:var} references) nor the text
+of the block itself has changed since the result was computed.  The feature
+helps avoid re-running long calculations.  However, there are edge cases and
+you should not rely on the cache to behave reliably in all circumstances.
+
+The caching feature works best when a babel block is a pure function of its
+arguments (see @ref{var}).  That is, the function always returns the same
+results when given the same arguments, and does not touch external resources
+(like the filesystem or the language’s RNG) in any way.
+
+The documentation of the knitr reproducible research package for the R
+language has some good discussion of issues that may arise when using the
+cache in such a context.  See @uref{http://yihui.name/knitr/demo/cache/},
+especially the sections “Even more stuff for cache?” and “Reproducibility
+with RNG”.  (Obviously, you will have to abstract away from the knitr
+implementation details which the documentation also discusses.)
+
+Note that the @code{:cache} header argument will attempt to cache results
+when the @code{:session} header argument is used, even 

Re: [O] Org Babel resolution of `:var` value reference inconsistent

2015-11-04 Thread Andreas Leha
Hi Nick,

Nick Dokos  writes:
> Andreas Leha  writes:
>
>> ...
>> So, to me it is more surprising that the manual execution works.  For
>> instance, I might have two tables with the same name.  Then, COMMENTing
>> one of them should ensure that the other one is used.
>>
>
> COMMENT works during export *only* I believe. You have to explicitly
> comment out one of the tables otherwise. If there are two tables with
> the same name, babel will use the one nearer the beginning of the file
> and ignore the second one (I determined this experimentally, *not* by
> reading and understanding the code - ymmv).

Thanks for following up on this.  I also ran some tests now and confirm
what you see.  Test code below [2].

I'd say it is a bug if the results from evaluation differ between
manual evaluation and during export.

And even if it is not explicitely contradicting the manual [1] (which
does not say anything about finding references), I'd prefer if
references in COMMENT'ed sections are not found -- neither during export
nor during evaluation.  This would be more inline with my intuition of
COMMENT is equivalent to # (which is also suggested by the fact that
COMMENT is described in the section on #).


Regards,
Andreas

[1] http://orgmode.org/manual/Comment-lines.html#Comment-lines


[2] Test code
--8<---cut here---start->8---
* Test COMMENTing babel reference

** COMMENT Table 1
#+name: testtable
| a | b |
|---+---|
| 1 | 2 |


# ** Table 2
# #+name: testtable
# | c | d |
# |---+---|
# | 3 | 4 |


# ** Table 2.5
# #+name: testtable2
# | c | d |
# |---+---|
# | 3 | 4 |



** Table 3
#+name: testtable
| e | f |
|---+---|
| 5 | 6 |


** Use (one of) the visible tables
This gives different results during export compared to manual
evaluation.
#+begin_src R :var tab=testtable :colnames yes :exports results
  tab
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |

** Use the #'ed table  :noexport:
This works neither during export nor during manual evaluation.
#+begin_src R :var tab=testtable2 :colnames yes :exports results
  tab
#+end_src
--8<---cut here---end--->8---




[O] export to beamer

2015-11-04 Thread 童俊翔
I want to export org to beamer. It worked well previously when I press C-c C-e 
l O. But in recent days, when I press C-c C-e l, the options for beamer are 
missing. I can only export to pdf, not beamer.

What’s the problem, and what can I do?

Thanks a lot!


Re: [O] [PATCH 9/9] ob-calc: don't leave garbage on the stack

2015-11-04 Thread Aaron Ecay
2015ko azaroak 4an, Jan Malakhovski-ek idatzi zuen:
> 
> Aaron Ecay  writes:
> 
>> Are you missing a close paren at the end of the above line?
> 
> It evaluates and works ok, so I think it's ok.

Ok.  Then:
1. The indentation is wrong, because (calc-pop 1) is the second argument
   to calc-eval.
2. The prog1 form is not needed, because it only wraps a single form
   (the calc-eval call).

This looks wrong to me, so please double-check.

-- 
Aaron Ecay



[O] export to beamer

2015-11-04 Thread 童俊翔
I want to export org to beamer. It worked well previously when I press C-c C-e 
l O. But in recent days, when I press C-c C-e l, the options for beamer are 
missing. I can only export to pdf, not beamer.

What’s the problem, and what can I do?

Thanks a lot!


Re: [O] export to beamer

2015-11-04 Thread Benda Xu
童俊翔  writes:

> I want to export org to beamer. It worked well previously when I press
> C-c C-e l O. But in recent days, when I press C-c C-e l, the options
> for beamer are missing. I can only export to pdf, not beamer.
>
> What’s the problem, and what can I do?

I found the same issue.  Try add

#+startup: beamer

to the beginning is the org file.

Cheers,
Benda


Re: [O] export to beamer

2015-11-04 Thread Eric S Fraga
On Wednesday,  4 Nov 2015 at 22:29, 童俊翔 wrote:
> I want to export org to beamer. It worked well previously when I press
> C-c C-e l O. But in recent days, when I press C-c C-e l, the options
> for beamer are missing. I can only export to pdf, not beamer.
>
> What’s the problem, and what can I do?

Make sure you have

 (require 'ox-beamer)

in your startup to enable the option.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33



Re: [O] [babel] :eval and #+call lines

2015-11-04 Thread Aaron Ecay
Hi Andreas,

2015ko urriak 29an, Andreas Leha-ek idatzi zuen:
> 
> Hi all,
> 
> Since this is not related to caching, I post this as a separate question
> from [1].

Thanks for the report.

> 
> I want to argue that specifying ':eval never' as argument to a #+call
> line should transitively apply to the called block as well.

I’m not sure what we should do here.  The system of inner and outer
header args is consistent, even when it leads to strange results as in
this case.  I would hesitate to introduce special cases to the system.

A better option would be to fix the system in general.  Ideally we would
not need both sets of header arguments.  Currently, for evaluating:

#+call: foo[:inner args](bar="baz") :outer args

babel in effect evaluates this dummy elisp code block:

#+begin_src emacs-lisp :var results=foo(bar="baz")
  results
#+end_src

Resolving the :var reference causes the block named foo to be evaluated.
The inner args go to the foo block, and the outer args are added to the
dummy elisp block.  It would be better (less confusing) if there were no
need to evaluate the dummy elisp block.  Rather, foo should be evaluated
and its result inserted directly (somehow...).

This change is not straightforward though.  It also has backwards
compatibility implications (what to do with the header args when both
sets are given).  And it interacts with the behavior of :cache, as
you’ve pointed out in the other thread.

Certainly a warning could be put in the manual about this case (patches
welcome...)

-- 
Aaron Ecay



Re: [O] [PATCH 6/9] factor out date-timestamp* calculations to org-store-link-props

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> Checking the source, date-to-time can raise an error (invalid date).
> format-time-string is a C function, so it’s less easy for me to
> understand.  But it looks like if it raises any errors, these are bugs
> that we want to know about and not suppress.
>
> The ignore-error call was introduced to org-gnus in commit 0dfde2da.
> Based on the commit message, it looks like the problem being solved was
> invalid dates getting passed to date-to-time.
>
> So I think the ignore-error can just wrap the date-to-time call.

Thanks. Ok.



[O] [RFC] [PATCH] Automatically quote the arguments to an eval macro

2015-11-04 Thread Aaron Ecay
Hello all,

Currently, eval macros need to quote their arguments:

#+macro: identity (eval "$1")

This means:
1. Users need to remember to put quotes around $n all the time
2. It’s impossible to pass arguments with a " character to a macro

The attached patch changes the behavior of eval macro arguments so that
$1 etc. expand to the argument with quotation marks.  That is, the
following is now the correct way to write a macro (note lack of "s):

#+macro: identity (eval $1)

This solves the above problems but:
1. breaks backwards compatibility of eval macros, since the with-quotes
   version is now incorrect
2. disables macros like the following, where the macro arguments are
   interpreted as lisp symbols:

#+macro: funcall2 (eval ($1 $2 $3))

{{{funcall2(setq,org-export-with-date,nil)}}}

For 1, I can add a check for "$n" constructs (including quotes) to
org-lint and/or org-macro, to detect the backwards compatibility error.
I believe that macros like in 2 are rather perverse: macro arguments
are most similar to strings, not symbols or arbitrary pieces of lisp.
(For arbitrary lisp evaluation, there’s babel.)  Nonetheless, such
macros can be recreated explicitly in the new system using eval+read
and string interpolation:

#+macro: funcall2 (eval (eval (read (format "(%s %s %s)" $1 $2 $3

Thoughts?

Thanks,

-- 
Aaron Ecay
>From c44b9b1f9a88e3bb88d1b4d9b59284ae840f02ce Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Wed, 4 Nov 2015 12:13:07 +
Subject: [PATCH] macros: automatically quote the arguments to an eval macro

* lisp/org-macro.el (org-macro-expand): Automatically quote the
arguments to an eval macro.
---
 lisp/org-macro.el | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 5f9c227..4858427 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -159,20 +159,24 @@ MACRO is an object, obtained, for example, with
 `org-element-context'.  TEMPLATES is an alist of templates used
 for expansion.  See `org-macro-templates' for a buffer-local
 default value.  Return nil if no template was found."
-  (let ((template
-	 ;; Macro names are case-insensitive.
-	 (cdr (assoc-string (org-element-property :key macro) templates t
+  (let* ((template
+	  ;; Macro names are case-insensitive.
+	  (cdr (assoc-string (org-element-property :key macro) templates t)))
+	 ;; Macro starts with "(eval": it is a s-exp and will be `eval'-ed.
+	 (evalp (string-match "\\`(eval\\>" template)))
 (when template
   (let ((value (replace-regexp-in-string
 "\\$[0-9]+"
 (lambda (arg)
-  (or (nth (1- (string-to-number (substring arg 1)))
-   (org-element-property :args macro))
-  ;; No argument: remove place-holder.
-  ""))
+		  (let ((arg-val (nth (1- (string-to-number (substring arg 1)))
+	  (org-element-property :args macro
+			(cond
+			 (evalp (format "%S" arg-val))
+			 (arg-val arg-val)
+			 ;; No argument: remove place-holder.
+			 (t ""
 template nil 'literal)))
-;; VALUE starts with "(eval": it is a s-exp, `eval' it.
-(when (string-match "\\`(eval\\>" value)
+(when evalp
   (setq value (eval (read value
 ;; Return string.
 (format "%s" (or value ""))
-- 
2.6.2



Re: [O] [PATCH 6/9] factor out date-timestamp* calculations to org-store-link-props

2015-11-04 Thread Aaron Ecay
Hi Jan,

2015ko azaroak 4an, Jan Malakhovski-ek idatzi zuen:

[...]

>> Also, what is ignore-errors protecting? The call to date-to-time, or
>> format-time-string? I think the scope of ignore-errors should be as
>> narrow as it can be.
> 
> I have no idea. I moved these lines from org-gnus, equivalent lines in
> org-*other-mail-reader*s don't use ignore-errors at all. I don't use
> gnus so went for the safest change.

Checking the source, date-to-time can raise an error (invalid date).
format-time-string is a C function, so it’s less easy for me to
understand.  But it looks like if it raises any errors, these are bugs
that we want to know about and not suppress.

The ignore-error call was introduced to org-gnus in commit 0dfde2da.
Based on the commit message, it looks like the problem being solved was
invalid dates getting passed to date-to-time.

So I think the ignore-error can just wrap the date-to-time call.

-- 
Aaron Ecay



Re: [O] [PATCH 9/9] ob-calc: don't leave garbage on the stack

2015-11-04 Thread Aaron Ecay
Hi Jan,

2015ko azaroak 3an, Jan Malakhovski-ek idatzi zuen:
> 
> * lisp/ob-calc.el (org-babel-calc-eval-string): Clean up the stack after 
> expression
>   evaluation.
> ---
>  lisp/ob-calc.el | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
> index e8b43e7..2656f27 100644
> --- a/lisp/ob-calc.el
> +++ b/lisp/ob-calc.el
> @@ -196,7 +196,9 @@ See `org-babel-calc-eval' for more info."
>(mapc #'org-babel-calc-eval-line (split-string text "[\n\r]"))
>(save-excursion
>  (with-current-buffer (get-buffer "*Calculator*")
> -  (calc-eval (calc-top 1)
> +  (prog1
> +(calc-eval (calc-top 1)

Are you missing a close paren at the end of the above line?  Also,
shouldn’t calc-eval take a string as an argument, not a lisp form?  (I’m
asking based on the docstring, I don’t know the calc API at all).

-- 
Aaron Ecay



Re: [O] [PATCH v2 0/9] mail, clock and calc changes

2015-11-04 Thread Aaron Ecay
Hi Jan,

Thanks for the patches!  They look good to me.  I sent a few minor
comments about code style.  I didn’t review the 8th patch (ob-calc: add
more API, documentation and examples so that it can be used in tables)
because I didn’t feel familiar enough with the calc API to be useful.

Do you want somebody to apply the tinychange patches already?  Or do you
want to wait until your assignment is processed and apply them yourself?
(IMO patch 4 could also be a TINYCHANGE, since it is only code movement
with no actual changes).

-- 
Aaron Ecay



Re: [O] [PATCH 9/9] ob-calc: don't leave garbage on the stack

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> Are you missing a close paren at the end of the above line?

It evaluates and works ok, so I think it's ok.

> Also, shouldn’t calc-eval take a string as an argument, not a lisp
> form? (I’m asking based on the docstring, I don’t know the calc API at
> all).

1) It was like this before.
2) It works.
3) calc-eval calls calc-do-calc-eval on this argument and the code
   there does a dispatch on expression, so I think it's safe to assume
   it's not actually a string (calc is a mess, yep).



Re: [O] how to set the max width of the table in the exported pdf?

2015-11-04 Thread Grant Rettke
On Mon, Oct 12, 2015 at 11:19 PM, glen  wrote:
> Hi, all.
>
> The table in org file is too wide, so the default table in the exported pdf
> only show the left parts.
> Is there anyway to set set max-width to the 90% of the page's width? [The
> contents in the table is wrapped automatically].

Something similar?

https://tex.stackexchange.com/questions/10863/is-there-a-way-to-slightly-shrink-a-table-including-font-size-to-fit-within-th



Re: [O] [PATCH 6/9] factor out date-timestamp* calculations to org-store-link-props

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> Can you introduce a let binding so that (date-to-time x) is only called
> once?

Ok.

> Also, what is ignore-errors protecting? The call to date-to-time, or
> format-time-string? I think the scope of ignore-errors should be as
> narrow as it can be.

I have no idea. I moved these lines from org-gnus, equivalent lines in
org-*other-mail-reader*s don't use ignore-errors at all. I don't use
gnus so went for the safest change.



Re: [O] [PATCH v2 0/9] mail, clock and calc changes

2015-11-04 Thread Jan Malakhovski
Hi.

Aaron Ecay  writes:

> Thanks for the patches!  They look good to me.  I sent a few minor
> comments about code style.  I didn’t review the 8th patch (ob-calc: add
> more API, documentation and examples so that it can be used in tables)
> because I didn’t feel familiar enough with the calc API to be useful.

Thanks for the comments!

> Do you want somebody to apply the tinychange patches already?  Or do you
> want to wait until your assignment is processed and apply them yourself?
> (IMO patch 4 could also be a TINYCHANGE, since it is only code movement
> with no actual changes).

I'm fine either way, including patch 4. If somebody merges those, I'll
just resend the rest when I fix the pieces you pointed to.

Cheers,
  Jan



Re: [O] Resolving links breaks workflow using org-narrow-to-subtree

2015-11-04 Thread Aaron Ecay
Hi Andreas,

This issue has been discussed recently.  Nicolas proposed a “draft mode”
that would solve your problem.  His most recent proposal is at
.  It hasn’t been
pushed to the org repository yet though.

-- 
Aaron Ecay



Re: [O] [PATCH 6/9] factor out date-timestamp* calculations to org-store-link-props

2015-11-04 Thread Aaron Ecay
Hi Jan,

2015ko azaroak 3an, Jan Malakhovski-ek idatzi zuen:

[...]

> diff --git a/lisp/org.el b/lisp/org.el
> index c466870..cf0ef1f 100755
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -9960,7 +9960,7 @@ active region."
>(car org-stored-links))
>  
>  (defun org-store-link-props ( plist)
> -  "Store link properties, extract names and addresses."
> +  "Store link properties, extract names, addresses and dates."
>(let (x adr)
>  (when (setq x (plist-get plist :from))
>(setq adr (mail-extract-address-components x))
> @@ -9969,7 +9969,18 @@ active region."
>  (when (setq x (plist-get plist :to))
>(setq adr (mail-extract-address-components x))
>(setq plist (plist-put plist :toname (car adr)))
> -  (setq plist (plist-put plist :toaddress (nth 1 adr)
> +  (setq plist (plist-put plist :toaddress (nth 1 adr
> +(when (setq x (plist-get plist :date))
> +  (setq plist (plist-put plist :date-timestamp
> + (ignore-errors
> +   (format-time-string
> + (org-time-stamp-format t)
> + (date-to-time x)
> +  (setq plist (plist-put plist :date-timestamp-inactive
> + (ignore-errors
> +   (format-time-string
> + (org-time-stamp-format t t)
> + (date-to-time x)))

Can you introduce a let binding so that (date-to-time x) is only called
once?  Also, what is ignore-errors protecting?  The call to date-to-time,
or format-time-string?  I think the scope of ignore-errors should be as
narrow as it can be.

-- 
Aaron Ecay



Re: [O] [PATCH 9/9] ob-calc: don't leave garbage on the stack

2015-11-04 Thread Jan Malakhovski
Aaron Ecay  writes:

> Ok.  Then:
> 1. The indentation is wrong, because (calc-pop 1) is the second argument
>to calc-eval.
> 2. The prog1 form is not needed, because it only wraps a single form
>(the calc-eval call).
>
> This looks wrong to me, so please double-check.

Ah, I misunderstood. You are correct about parens indeed. Fixed, ok. Why
it wored as expected I have no idea.



Re: [O] Adding new switch or header

2015-11-04 Thread Phillip Lord
Eric S Fraga  writes:

> On Tuesday,  3 Nov 2015 at 21:57, Phillip Lord wrote:
>
> [...]
>
>> Are these form of attributes specific to the source block which they
>> precede? Or is it possible to do any kind of inheritance with them? For
>> my use case, all the code blocks inside a Header One block will behave
>> in the same way (either with \[ escaping or without).
>
> No idea!  Maybe Nicolas can help here as I assume this is all a function
> of the parser.

No worries. Many thanks for the feedback.

Phil



[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically

2015-11-04 Thread Glenn Morris
Eli Zaretskii wrote:

> Org mode has its own bug tracker, AFAIR.

Nope, just a mailing list AFAIK. Assigning something to the debbugs
org-mode package (which I already did for this report) sends stuff there.





Re: [O] Combine tables which are results from calculations?

2015-11-04 Thread Rick Frankel
On Wed, Nov 04, 2015 at 10:03:48AM +0100, Rainer M Krug wrote:
> Rick Frankel  writes:
>
> > On Tue, Nov 03, 2015 at 02:18:05PM +0100, Rainer M Krug wrote:
> >> Hi
> >>
> >> Considering the following example:
> >
> > here's a way to do it in ruby. There is probably a way in {emacs,cl}-lisp, 
> > but
> > I'm not sure how...
> >
> > #+BEGIN_SRC ruby :var a=t1[,0] b=t2[,0] c=t3[,0] :colnames '(a b c)
> >   r = [a, b, c]
> >   len = r.collect(&:length).max
> >   r.each { |l| l.fill('', l.length, len - l.length) }
> >   a.zip(b, c)
> > #+END_SRC
>
> Thanks - I'll look into this and see if I can do something similar in R
> or elisp.

Here's a elisp version:

* zip lists
#+name: a
| a |
|---|
| 1 |
| 2 |


#+name: b
| b |
|---|
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |

#+name: c
|  c |
||
|  9 |
| 10 |
| 11 |

#+BEGIN_SRC emacs-lisp :var a=a[,0] b=b[,0] c=c[,0] :colnames '(a b c)
  (let*  ((l (list a b c))
  (max (apply #'max (mapcar #'length l
(apply
 #'mapcar* #'list
 (mapcar (lambda (x) (append x (make-list (- max (length x)) ""))) l)))
#+END_SRC


rick

Note: previous reply was not to list (whoops) CC'ing the list on this so the
answer is saved for posterity :).



Re: [O] Favorite contrib/ packages?

2015-11-04 Thread Michael Strey
On Di, 2015-11-03 at 19:58, Kaushal Modi wrote:

> What are your favorite org contrib/ packages that you simply can't
> live without, and consider them to be a part of your org-mode core?

org-checklist org-collector org-contacts org-dial org-download org-drill
org-learn org-mime org-notmuch org-registry ox-koma-letter

-- 
Michael Strey
http://www.strey.biz * https://twitter.com/michaelstrey




Re: [O] bug in org-habits

2015-11-04 Thread Stelian Iancu

On 04/11/15 02:01, John Wiegley wrote:

Nicolas Goaziou  writes:

Also, supporting both locations means that users will pay the full price in
entries without a property drawer, even if they chose the fast path, i.e.,
drawer at the beginning of the entry, in the first place. This kind of
defeats some of the advantages of the current state.


It wouldn't be "users": it would be people intentionally opting to allow
floating properties. _I_ would be paying the price, and I will pay it happily
to keep 8.2 behavior.

John



I would also like to have the 8.2 behavior. If it's easier, it would be 
fine to always have the drawer either in the beginning or in the end and 
nowhere else (and have an option to chose with the default in the 
beginning).


S.




Re: [O] Adding new switch or header

2015-11-04 Thread Eric S Fraga
On Tuesday,  3 Nov 2015 at 21:57, Phillip Lord wrote:

[...]

> Are these form of attributes specific to the source block which they
> precede? Or is it possible to do any kind of inheritance with them? For
> my use case, all the code blocks inside a Header One block will behave
> in the same way (either with \[ escaping or without).

No idea!  Maybe Nicolas can help here as I assume this is all a function
of the parser.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33



Re: [O] bug in org-habits

2015-11-04 Thread Eric S Fraga
On Tuesday,  3 Nov 2015 at 20:01, John Wiegley wrote:

[...]

> I'm having a hard time buying the performance argument, since I've been using
> Org-mode for many years, and never has this been a problem. You're making me
> pay a cost (enforced structure), for a value only one of us perceives.

John,

others *have* found issues with performance.

In 8.2, org struggled with many of my documents, some of which are very
large.  Most, if not all, of the performance problems I was having have
disappeared since then (thank you Nicolas!).  I cannot attribute the
improvements directly to the move to a fixed structure for headline
meta-data but I can easily believe that this move has contributed due to
anecdotal experience with complex sections within my org files.

This does not mean I am against your suggestion of a variable
controlling this behaviour.  Maybe implement it and post a patch for the
community to try out?

I am perfectly happy with the current format, however, so would be
unlikely to try it.  (sorry)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33



Re: [O] Favorite contrib/ packages?

2015-11-04 Thread Eric S Fraga
On Tuesday,  3 Nov 2015 at 13:58, Kaushal Modi wrote:
> HI all,
>
> What are your favorite org contrib/ packages that you simply can't
> live without, and consider them to be a part of your org-mode core?

There is only one that I use with any regularity: org-mime.

Well, and maybe org-bullets when I get tired of the default look... :-)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33



Re: [O] [PATCH] Prevent overwriting of output files from babel calls with nil result

2015-11-04 Thread Aaron Ecay
Hi Éibhear,

2015ko urriak 30an, Éibhear-ek idatzi zuen:

[...]

> 
> The following works (":results raw" being the significant change):

I’m glad you figured it out!  Thanks for updating us with your solution.

-- 
Aaron Ecay



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

2015-11-04 Thread John Kitchin
Thanks for all the notes! It looks like a not too trivial exercise that
might have to be a summer project for me.

briangpowell . writes:

> * Here are some of my notes+URL links on some docker+emacs experiments thus
> far:
>
> ** Last I checked some glimmering developments seem to be coming to light
> in the docker+emacs realm:
>
> *** Believe some links below might be stepping-stones for your students,
> Dr. Kitchin:
>
> ** Happily, below, I note coming across some work by one of our favorite
> Elisp hackers of "elnode" fame: Nic Ferrier
>
> ** "docker.el" was in development too last I looked into this--see link
> below.
>
> * Linux Containers: ###1 read and take advice here FIRST:
> http://stackoverflow.com/questions/27083182/running-emacs-in-a-docker-container
>
>
> ** These links are slightly tangential but I suggest them since they're
> also stepping-stones to really what's going on under-the-docker-hood:
>
> ** https://en.wikipedia.org/wiki/Copy-on-write
> **
> http://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment?page=0,0
> ** http://www.liquidweb.com/kb/how-to-install-docker-on-ubuntu-14-04-lts
> ** http://aufs.sourceforge.net
> ** https://linuxcontainers.org
>
> * Can run xampp on a docker--see notes and experiments below, here are
> first checks and steps:
> ** docker inspect garland/xampp-base docker
> ** netstat -lnp|grep 8080" ; echo "=>" ; netstat -lnp | grep 8080 ; sleep 3
> * Now try to run the xampp container:
> docker run -t -i -p 8080:80 garland/xampp-base /bin/bash &
>
> * /opt/lampp/lampp startapache
> ** http://localhost:8080/xampp/splash.php
> ** xterm -e docker run -i -t debian /bin/bash
> ** xterm -e docker run -i -t ubuntu /bin/bash
> ** docker run -i -t debian /bin/bash &
> *** xampp on docker!?:
>
> * Enabling XAMPP Web Interface with docker:
>
> Start Docker in interactive mode
>
> [[shell:docker run -t -i -p 8080:80 garland/xampp-base /bin/bash &]]
>
> vim /opt/lampp/etc/extra/httpd-xampp.conf
> Remove the bottom 4 lines.docker.el
>  Commented out the bottom 4 lines and then this got it semi-working
> (returned "Object not found!" error) after I did this:
> /opt/lampp/lampp startapache
> google-chrome http://localhost:8080/:80
> * This worked!(after starting apache in the docker xterm): google
> http://localhost:8080/xampp/splash.php
>
> ** https://github.com/Silex/docker.el
>
> * [[shell:echo * Put emacs in Docker(but remember all writes will be
> lost--so to really keep things write to volume(s)):";cd;docker pull
> biscarch/emacs &]]
>
> ** Just mounted a "volume" (to Docker: volumes are read-write(usually) dirs
> and/or files outside the Union File system (aufs) and available to the host
> AND the container)
> docker run -it --name container-test -h CONTAINER -v /data debian /bin/bash
> docker inspect -f {{.Volumes}} container-test =>
> map[/data:/var/lib/docker/vfs/dir/79d22ddf7a12b6e283c74df521289adb6b537883686eb43aa3c2405f0c6aacae]
> date >
> /var/lib/docker/vfs/dir/79d22ddf7a12b6e283c74df521289adb6b537883686eb43aa3c2405f0c6aacae/date.j
> root@CONTAINER:/# cat /data/date.j => Mon Jul 20 09:08:33 EDT 2015
> ** http://container-solutions.com/understanding-volumes-docker/ "Quite
> simply, volumes are directories (or files) that are outside of the default
> Union File System and exist as normal directories and files on the host
> filesystem."
> In order to be able to save (persist) data and share data between
> containers, Docker came up with the concept of volumes:
> Quite simply, volumes are directories (or files) that are outside of the
> default Union File System and exist as normal directories and files on the
> host filesystem.
> There are two ways to initialise volumes, with some subtle differences that
> are important to understand. We can declare a volume at run-time with the
> -v flag:
> 
> $ docker run -it --name container-test -h CONTAINER -v /data debian
> /bin/bash
>
> root@CONTAINER:/# ls /data
> root@CONTAINER:/#
> This will make the directory /data inside the container live outside the
> Union File System and directly accessible on the host.
> *** Trying this but fails--may have to do before booting the container?:
> docker run -v /home/b/data55:/data55 debian ls /data55
> ** Can also give access to a "volume" that is available in one container to
> another
> *** Can't you use FUSE with a container!?
> ** "you can also mount a directory from your own host into a container:"
> $ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp
> training/webapp python app.py
> *** The above will mount the local directory, /src/webapp, into the
> container as the /opt/webapp directory. This is very useful for testing;
> for example,
> we can mount our source code inside the container and see our application
> at work as we change the source code!
>  But with UNIONFS and AUFS this functionality has been available for
> many years.
> ** To test docker install
> docker search debian
> docker pull 

Re: [O] [PATCH 3/9] org-clock: fix `org-clock-time%'

2015-11-04 Thread Aaron Ecay
Hi Jan,

A couple stylistic comments.

2015ko azaroak 3an, Jan Malakhovski-ek idatzi zuen:
> 
> * lisp/org-clock.el (org-clock-time%): Respect org-effort-durations.
> 
> This also fixes a bug with time percents looking pretty much random and adding
> to a number that is less than 100% when a clock report has long intervals
> (e.g. days).
> ---
>  lisp/org-clock.el | 29 +++--
>  1 file changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/lisp/org-clock.el b/lisp/org-clock.el
> index ad423f1..4563a8a 100644
> --- a/lisp/org-clock.el
> +++ b/lisp/org-clock.el
> @@ -2867,27 +2867,20 @@ TIME:  The sum of all time spend in this tree, in 
> minutes.  This time
>  
>  (defun org-clock-time% (total  strings)
>"Compute a time fraction in percent.
> -TOTAL s a time string like 10:21 specifying the total times.
> +TOTAL s a total time string.
>  STRINGS is a list of strings that should be checked for a time.
> -The first string that does have a time will be used.
> -This function is made for clock tables."
> -  (let ((re "\\([0-9]+\\):\\([0-9]+\\)")
> - tot s)
> -(save-match-data
> +Strings are parsed using `org-duration-string-to-minutes`.
> +The first string that does have a time will be used. This
> +function is made for clock tables."
> +  (save-match-data
> +(let (tot s cur)
>(catch 'exit
> - (if (not (string-match re total))
> - (throw 'exit 0.)
> -   (setq tot (+ (string-to-number (match-string 2 total))
> -(* 60 (string-to-number (match-string 1 total)
> -   (if (= tot 0.) (throw 'exit 0.)))
> + (setq tot (org-duration-string-to-minutes total))
> + (if (= tot 0.) (throw 'exit 0.))
>   (while (setq s (pop strings))

This could be converted to dolist while you’re here (I realize you
didn’t touch this line).

> -   (if (string-match "\\([0-9]+\\):\\([0-9]+\\)" s)
> -   (throw 'exit
> -  (/ (* 100.0 (+ (string-to-number (match-string 2 s))
> - (* 60 (string-to-number
> -(match-string 1 s)
> - tot
> - 0
> +   (setq cur (org-clocksum-string-to-minutes s))
> +   (if (not (equal cur nil)) (throw 'exit (/ (* 100.0 cur) tot

(when cur (throw 'exit ...))

-- 
Aaron Ecay



Re: [O] [PATCH 5/9] rename `org-duration-string-to-minutes' to `org-clocksum-string-to-minutes' everywhere

2015-11-04 Thread Aaron Ecay
Hi Jan,

2015ko azaroak 3an, Jan Malakhovski-ek idatzi zuen:
> 
> * lisp/org-agenda.el:
> * lisp/org-clock.el:
> * lisp/org-colview.el:
> * lisp/org.el:
> * contrib/lisp/org-depend.el:
> * contrib/lisp/ox-taskjuggler.el: Rename (org-duration-string-to-minutes)
>   to (org-clocksum-string-to-minutes).
> ---
>  contrib/lisp/org-depend.el |  2 +-
>  contrib/lisp/ox-taskjuggler.el |  2 +-
>  lisp/org-agenda.el |  2 +-
>  lisp/org-clock.el  | 14 +++---
>  lisp/org-colview.el|  2 +-
>  lisp/org.el| 14 +-
>  6 files changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/contrib/lisp/org-depend.el b/contrib/lisp/org-depend.el
> index 1cd4130..7b263bc 100644
> --- a/contrib/lisp/org-depend.el
> +++ b/contrib/lisp/org-depend.el
> @@ -270,7 +270,7 @@ This does two different kinds of triggers:
>   (effort (when (or effort-up effort-down)
> (let ((effort (get-text-property (point) 
> 'org-effort)))
>   (when effort
> -   (org-duration-string-to-minutes 
> effort))
> +   (org-clocksum-string-to-minutes 
> effort))
>   (push (list (point) todo-kwd priority tags effort)
> items))
> (unless (org-goto-sibling)
> diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
> index 2bd47e6..b425b1b 100644
> --- a/contrib/lisp/ox-taskjuggler.el
> +++ b/contrib/lisp/ox-taskjuggler.el
> @@ -861,7 +861,7 @@ a unique id will be associated to it."
>   (and complete (format "  complete %s\n" complete))
>   (and effort
>(format "  effort %s\n"
> -  (let* ((minutes (org-duration-string-to-minutes effort))
> +  (let* ((minutes (org-clocksum-string-to-minutes effort))
>   (hours (/ minutes 60.0)))
>  (format "%.1fh" hours
>   (and priority (format "  priority %s\n" priority))
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 6313f52..ab4595b 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -7665,7 +7665,7 @@ E looks like \"+<2:25\"."
>  ((equal op ??) op)
>  (t '=)))
>  (list 'org-agenda-compare-effort (list 'quote op)
> -   (org-duration-string-to-minutes e
> +   (org-clocksum-string-to-minutes e
>  
>  (defun org-agenda-compare-effort (op value)
>"Compare the effort of the current line with VALUE, using OP.
> diff --git a/lisp/org-clock.el b/lisp/org-clock.el
> index 4563a8a..ab65d3b 100644
> --- a/lisp/org-clock.el
> +++ b/lisp/org-clock.el
> @@ -668,7 +668,7 @@ If not, show simply the clocked time like 01:50."
>(let ((clocked-time (org-clock-get-clocked-time)))
>  (if org-clock-effort
>   (let* ((effort-in-minutes
> - (org-duration-string-to-minutes org-clock-effort))
> + (org-clocksum-string-to-minutes org-clock-effort))
>  (work-done-str
>   (org-propertize
>(org-minutes-to-clocksum-string clocked-time)
> @@ -749,10 +749,10 @@ clocked item, and the value displayed in the mode line."
> ;; A string.  See if it is a delta
> (setq sign (string-to-char value))
> (if (member sign '(?- ?+))
> -   (setq current (org-duration-string-to-minutes current)
> +   (setq current (org-clocksum-string-to-minutes current)
>   value (substring value 1))
>   (setq current 0))
> -   (setq value (org-duration-string-to-minutes value))
> +   (setq value (org-clocksum-string-to-minutes value))
> (if (equal ?- sign)
> (setq value (- current value))
>   (if (equal ?+ sign) (setq value (+ current value)
> @@ -770,7 +770,7 @@ clocked item, and the value displayed in the mode line."
>"Show notification if we spent more time than we estimated before.
>  Notification is shown only once."
>(when (org-clocking-p)
> -(let ((effort-in-minutes (org-duration-string-to-minutes 
> org-clock-effort))
> +(let ((effort-in-minutes (org-clocksum-string-to-minutes 
> org-clock-effort))
> (clocked-time (org-clock-get-clocked-time)))
>(if (setq org-clock-task-overrun
>   (if (or (null effort-in-minutes) (zerop effort-in-minutes))
> @@ -1193,7 +1193,7 @@ make this the default behavior.)"
>(setq org-clock-notification-was-shown nil)
>(org-refresh-properties
> org-effort-property '((effort . identity)
> -  (effort-minutes . org-duration-string-to-minutes)))
> +  (effort-minutes . org-clocksum-string-to-minutes)))
>(catch 'abort
>  (let ((interrupting (and (not org-clock-resolving-clocks-due-to-idleness)
>(org-clocking-p)))
> @@ -2869,13 +2869,13 @@