Re: [O] avoiding "First item of list cannot move without its subtree"

2017-02-21 Thread Max Rydahl Andersen

On 21 Feb 2017, at 18:35, Nicolas Goaziou wrote:


"Max Rydahl Andersen"  writes:


Any pointers on how to do this ?

I tried this but no luck to get hooked in:

```
(defadvice org-fix-list-indent
(around org-list-indent-item-generic)
  "Advise list indention to trigger creation of star instead"
  (message "DO MAGIC!")
  (ad-do-it)
)
```

But with this "DO MAGIC!" does not show up.


The function to advice is `org-shiftmetaleft', not
`org-fix-list-indent'.

Anyway, you can also add something like the following to
`org-shiftmetaleft-hook':

  (defun my-shiftmetaleft ()
(interactive)
(let* ((element (org-element-at-point))
   (list-parent (org-element-lineage element '(item 
plain-list) t)))

  (when (and list-parent
 (= (line-beginning-position)
(org-element-property :post-affiliated element)))
(call-interactively
 (if (org-element-lineage list-parent '(item)) ;not at top 
level

 #'org-outdent-item-tree
   #'org-ctrl-c-star))
t)))


Thanks! I did this but still no effect ;/

What am I doing wrong ?

```
(add-hook 'org-shiftmetaleft-hook
  (lambda ()
(interactive)
(let* ((element (org-element-at-point))
   (list-parent (org-element-lineage element '(item plain-list) 
t)))
  (when (and list-parent
 (= (line-beginning-position)
(org-element-property :post-affiliated element)))
(call-interactively
 (if (org-element-lineage list-parent '(item)) ;not at top level
 #'org-outdent-item-tree
   #'org-ctrl-c-star))
t
```

/max
http://about.me/maxandersen


Re: [O] Python loops with ":results output"

2017-02-21 Thread John Kitchin
The startup is a bit slower I find too. On the other hand I get the right
output, async execution, multiple inline images, and export to jupyter
notebooks with my scimax modifications.


On Tue, Feb 21, 2017 at 3:53 PM Sebastian P. Luque 
wrote:

> On Tue, 21 Feb 2017 08:58:59 -0500,
> John Kitchin  wrote:
>
> > On Mon, Feb 20, 2017 at 11:04 PM, Seb  wrote:
> > #+BEGIN_SRC python :session :results output :exports results for i
> > in range(3): print("Iter {0}".format(i))
>
> > #+END_SRC
>
> > Try using ob-ipython. It doesn't have that issue for me.
>
> Thank you; unfortunately, this seems to work with Jupyter/Ipython
> kernels running as a service, which adds quite an overhead to the
> workflow.
>
> --
> Seb
>
>
> --
John

---
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] Python loops with ":results output"

2017-02-21 Thread Sebastian P . Luque
On Tue, 21 Feb 2017 08:58:59 -0500,
John Kitchin  wrote:

> On Mon, Feb 20, 2017 at 11:04 PM, Seb  wrote:
> #+BEGIN_SRC python :session :results output :exports results for i
> in range(3):     print("Iter {0}".format(i))

> #+END_SRC

> Try using ob-ipython. It doesn't have that issue for me.

Thank you; unfortunately, this seems to work with Jupyter/Ipython
kernels running as a service, which adds quite an overhead to the
workflow.

-- 
Seb




Re: [O] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
> You can post your old customization here, I try to help you convert it
> to the new format, if possible at all.

Well, once I remembered why I had to customize it, things fell into
place.  It wasn't something complicated, just that I wanted all
durations shown in h:mm, without days (for the timetable at work).

>> I'd first need to understand what the options there really mean.  It
>> seems that the variable can be set to just a symbol or (maybe) a string
>> or a list of conses.
>
> Strings are not allowed. It is either a symbol (h:mm:ss or h:mm) or
> a list of conses.

That sentence in the documentation would have helped.

>> I don't really see why you'd mix symbols and strings in the same
>> position.
>
> Probably because I couldn't find a better idea to cover all cases.

If units are defined as strings, then why can the format not be a string
also?  I still find this confusing, especially as there are multiple
other places in Org that use format strings quite happily.

>> I have no idea what "mixed mode" is supposed to be
>
> The definition of "mixed mode" is in the docstring:
>
>   When any of the first two is present, a duration is expressed in
>   mixed mode, where the hours and minutes of the duration are
>   expressed as a \"H:MM:SS\" or \"H:MM\" string while still using
>   other units defined.

Lost me right there again.  Please tell the user what problem he can
solve with this and then tell him how to do it, not the other way
around.  So, the purpose of this variable is to specify how you want
durations displayed in Org, using the predefined "special" formats or
user-defined org-duration units (there's a default on those as well).  A
duration format doesn't necessarily use all defined units, and of those
it is using it (always?) starts with the largest unit and ends with the
smallest.  This is the only one that can usefully have PRECISION, I
suppose, but the docstring shows there might be a possibility to chose
differently (I believe that means it ignores the smaller units in this
case).

> There is even an example in the docstring:
>
>   The following format
>
> ((\"d\" . nil) (special . h:mm))

Except the default really is shown as (("d") (special . h:mm)) if the
user cares to look things up.

>   means that any duration longer than a day is expressed with both
>   a \"d\" unit and a \"H:MM\" part, whereas a duration shorter than
>   a day is expressed only as a \"H:MM\" string.
>
> Basically,
>
>   1d 8:30
>
> is mixed mode.
>
>> and what happens if I specify both (special . h:mm) and ("h" . nil)
>> for instance. Is the order of these important?
>
> Specifying both (special . h:mm) and ("h" . nil) is nonsensical, since
> you request something like "0:30" in the first case, and "0h" in the
> second one.
>
> In this case, I think ("h" . nil) is going to be ignored since (special
> . h:mm) already takes care of hours an minutes.

I've picked something that I expected to be nonsensical on purpose,
although I think it wouldn't be entirely unreasonable for a user to
expect that the duration would simply get formatted both ways.  The
documentation should tell me not to do that or if it's ignoring part of
the specification.  I take from your answer that the order of
specification might not be important, but it's not spelled out in the
docstring yet.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra




Re: [O] [ANN] New Org duration library

2017-02-21 Thread Nicolas Goaziou
Achim Gratz  writes:

> Thanks, but will there be some helper function to migrate the old
> customizations?  I didn't even remember that I had customized this
> variable until I couldn't clock in or out anymore (I remember now that I
> customized it so it would record durations in hours, not days/hours).

A helper function is not really possible since there is no 1 to
1 equivalence between the two systems. They share the same default
value, tho.

You can post your old customization here, I try to help you convert it
to the new format, if possible at all.

> I'd first need to understand what the options there really mean.  It
> seems that the variable can be set to just a symbol or (maybe) a string
> or a list of conses.

Strings are not allowed. It is either a symbol (h:mm:ss or h:mm) or
a list of conses.

> The conses form refer to org-duration-units, but there the units are
> all defined as strings and no mention of the symbol special that
> apparently is another possibility.

The mention of the symbol special is there:

  Eventually, the list can contain an entry indicating special
  formatting needs.  It can follow one of the three following
  patterns:

(special . h:mm)
(special . h:mm:ss)
(special . PRECISION)

  When any of the first two is present, a duration is expressed in
  mixed mode, where the hours and minutes of the duration are
  expressed as a \"H:MM:SS\" or \"H:MM\" string while still using
  other units defined.

> I don't really see why you'd mix symbols and strings in the same
> position.

Probably because I couldn't find a better idea to cover all cases.

> I have no idea what "mixed mode" is supposed to be

The definition of "mixed mode" is in the docstring:

  When any of the first two is present, a duration is expressed in
  mixed mode, where the hours and minutes of the duration are
  expressed as a \"H:MM:SS\" or \"H:MM\" string while still using
  other units defined.

There is even an example in the docstring:

  The following format

((\"d\" . nil) (special . h:mm))

  means that any duration longer than a day is expressed with both
  a \"d\" unit and a \"H:MM\" part, whereas a duration shorter than
  a day is expressed only as a \"H:MM\" string.

Basically,

  1d 8:30

is mixed mode.

> and what happens if I specify both (special . h:mm) and ("h" . nil)
> for instance. Is the order of these important?

Specifying both (special . h:mm) and ("h" . nil) is nonsensical, since
you request something like "0:30" in the first case, and "0h" in the
second one.

In this case, I think ("h" . nil) is going to be ignored since (special
. h:mm) already takes care of hours an minutes.

> I've set it to the symbol h:mm (shown as H:MM in customize) via the
> value menu in customize.  I might read the documentation incorrectly,
> but to me it seems to say it should be the string "h:mm" instead.

The first paragraph of the docstring is

  The value can be set to, respectively, `h:mm:ss' or `h:mm', which
  means a duration is expressed as, respectively, a \"H:MM:SS\" or
  \"H:MM\" string.

`...' implies a symbol, so `h:mm' is definitely a correct value. 

> I'm left to wonder if (h:mm) is the same or different from ((special .
> h.mm)).

There is no such thing as (h:mm). However, 'h:mm is morally equivalent
to ((special . h:mm)).

HTH,



Re: [O] BUG: agenda for current days excludes reoccurring events

2017-02-21 Thread Nicolas Goaziou
Hello,

Jarmo Hurri  writes:

> If I am on the right track here, org-agenda-show-future-repeats controls
> future repetitions, and org-agenda-prefer-last-repeat controls
> repetitions for today?

Almost. The former controls repetitions starting from tomorrow.  The
latter controls repetitions before yesterday. Repetitions for today are
always shown.

> Sounds like the best option to me. I can try give better informed
> comments after I see what the effect will be in my setup.

I pushed a change in that direction. Here is the new docstring for
`org-agenda-prefer-last-repeat'.

  Non-nil sets date for repeated entries to their last repeat.

  When nil, display SCHEDULED and DEADLINE dates at their base
  date, and in today's agenda, as a reminder.  Display plain
  time-stamps, on the other hand, at every repeat date in the past
  in addition to the base date.

  When non-nil, show a repeated entry at its latest repeat date,
  possibly being today even if it wasn't marked as done.  This
  setting is useful if you do not always mark repeated entries as
  done and, yet, consider that reaching repeat date starts the task
  anew.

  When set to a list of strings, prefer last repeats only for
  entries with these TODO keywords.

The problem is that plain timestamps OTOH and SCHEDULED, DEADLINE
keywords OTOH are no longer consistent. However, displaying too much
past SCHEDULED reminders could clutter the agenda.

I'm now waiting for your better informed comments.

Regards,

-- 
Nicolas Goaziou



Re: [O] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
>> You seem to have (some of) these aliased to org-duration format somehow.
>> This breaks a lot of things because the format of the former variables
>> is not recognized.  I got a bunch of errors about :hour not being a list
>> for instance.  There surely must be a better way to handle the
>> transition?
>
> Fixed. Thank you.

Thanks, but will there be some helper function to migrate the old
customizations?  I didn't even remember that I had customized this
variable until I couldn't clock in or out anymore (I remember now that I
customized it so it would record durations in hours, not days/hours).

>> Also, I find the documentation to be completely impenetrable.
>
> Great. Suggestions welcome.

I'd first need to understand what the options there really mean.  It
seems that the variable can be set to just a symbol or (maybe) a string
or a list of conses.  The conses form refer to org-duration-units, but
there the units are all defined as strings and no mention of the symbol
special that apparently is another possibility.  I don't really see why
you'd mix symbols and strings in the same position.  I have no idea what
"mixed mode" is supposed to be and what happens if I specify both
(special . h:mm) and ("h" . nil) for instance.  Is the order of these
important?

>> Customization has offered to create a setting for org-duration-format
>> that's not even mentioned in the documentation.
>
> Would it be possible, by any chance, to get a glimpse of that setting?

I've set it to the symbol h:mm (shown as H:MM in customize) via the
value menu in customize.  I might read the documentation incorrectly,
but to me it seems to say it should be the string "h:mm" instead.  I'm
left to wonder if (h:mm) is the same or different from ((special . h.mm)).


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra




Re: [O] [ANN] New Org duration library

2017-02-21 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> You seem to have (some of) these aliased to org-duration format somehow.
> This breaks a lot of things because the format of the former variables
> is not recognized.  I got a bunch of errors about :hour not being a list
> for instance.  There surely must be a better way to handle the
> transition?

Fixed. Thank you.

> Also, I find the documentation to be completely impenetrable.

Great. Suggestions welcome.

> Customization has offered to create a setting for org-duration-format
> that's not even mentioned in the documentation.

Would it be possible, by any chance, to get a glimpse of that setting?

Regards,

-- 
Nicolas Goaziou



Re: [O] avoiding "First item of list cannot move without its subtree"

2017-02-21 Thread Nicolas Goaziou
"Max Rydahl Andersen"  writes:

> Any pointers on how to do this ?
>
> I tried this but no luck to get hooked in:
>
> ```
> (defadvice org-fix-list-indent
> (around org-list-indent-item-generic)
>   "Advise list indention to trigger creation of star instead"
>   (message "DO MAGIC!")
>   (ad-do-it)
> )
> ```
>
> But with this "DO MAGIC!" does not show up.

The function to advice is `org-shiftmetaleft', not
`org-fix-list-indent'.

Anyway, you can also add something like the following to
`org-shiftmetaleft-hook':

  (defun my-shiftmetaleft ()
(interactive)
(let* ((element (org-element-at-point))
   (list-parent (org-element-lineage element '(item plain-list) t)))
  (when (and list-parent
 (= (line-beginning-position)
(org-element-property :post-affiliated element)))
(call-interactively
 (if (org-element-lineage list-parent '(item)) ;not at top level
 #'org-outdent-item-tree
   #'org-ctrl-c-star))
t)))
  

Regards,



Re: [O] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
> `org-time-clocksum-format', `org-time-clocksum-use-fractional' and
> `org-time-clocksum-fractional-format' are obsolete. If you changed them,
> consider modifying ~org-duration-format~ instead.

You seem to have (some of) these aliased to org-duration format somehow.
This breaks a lot of things because the format of the former variables
is not recognized.  I got a bunch of errors about :hour not being a list
for instance.  There surely must be a better way to handle the
transition?

Also, I find the documentation to be completely impenetrable.
Customization has offered to create a setting for org-duration-format
that's not even mentioned in the documentation.

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

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




Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

2017-02-21 Thread Charles C. Berry

On Tue, 21 Feb 2017, Aaron Ecay wrote:


Hi Chuck,

2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen:

[...]




Allowing header args to be processed (as before) also allows for arbitrary
code to be executed.  The point of setting ‘org-export-use-babel’ or
`org-export-babel-evaluate' to nil was to prevent this.  For that reason
the former behavior was a bug.


Iʼm not sure I agree that itʼs so simple.  There are still ways to execute
arbitrary code on export independently of babel (e.g. eval macros).  The
advice to use o-e-babel-evaluate for security was never (IMO) correct –
the only properly secure wat to export untrusted documents would involve
some kind of sandboxing of the emacs executable.



Fair enough.

[snip]



Taking a step back, I would ask what justifies o-e-b-eʼs existence at
all.  This thread demonstrates that itʼs not the right way to prevent
babel blocks from executing on export.  Itʼs also not a good solution to
the security issue.  Given the potential for confusion, Iʼd be in favor
of deprecating it entirely unless thereʼs some compelling reason for it
to exist that Iʼve overlooked.


In view of your point above about `eval' macros, I do not disagree.

Chuck.

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

2017-02-21 Thread Charles C. Berry

On Mon, 20 Feb 2017, Derek Feichtinger wrote:


Hi Chuck

On 21.02.2017 00:54, Charles C. Berry wrote:

On Mon, 20 Feb 2017, Derek Feichtinger wrote:

When org-export-babel-evaluate is set to nil, I see a different behavior 
now as compared to earlier versions of org.


Indeed.

It is now *obsolete* and its behavior has intentionally been changed as 
noted here:





So, I still feel that this is a very much needed functionality that has been 
lost on the way.


Nothing is lost here.

Reread the part of my post that you deleted in your reply:

: | ...  Users
: | who wish to avoid evaluating code on export should use the header
: | argument ‘:eval never-export’.
: |

which is how to do what you want.

And maybe review how to set header args buffer wide or system-wide.

HTH,

Chuck

Re: [O] avoiding "First item of list cannot move without its subtree"

2017-02-21 Thread Max Rydahl Andersen
On 21 Feb 2017, at 8:42, Nicolas Goaziou wrote:

> Hello,
>
> "Max Rydahl Andersen"  writes:
>
>> Might be - but seems it fits very naturally to be able to at least
>> allow to move list items outside its parent.
>>
>> Don't get me wrong - I  like it defaults to stopping, but would prefer
>> it would ask or let me do shift + left + left to override or something
>> similar.
>
> IMO, the current behaviour is the right one.
>
> However, you can advice, e.g., `org-shiftmetaleft' so it catches the
> error and calls `org-ctrl-c-star' instead.

Any pointers on how to do this ?

I tried this but no luck to get hooked in:

```
(defadvice org-fix-list-indent
(around org-list-indent-item-generic)
  "Advise list indention to trigger creation of star instead"
  (message "DO MAGIC!")
  (ad-do-it)
)
```

But with this "DO MAGIC!" does not show up.

/max
http://about.me/maxandersen


Re: [O] Python loops with ":results output"

2017-02-21 Thread John Kitchin
On Mon, Feb 20, 2017 at 11:04 PM, Seb  wrote:

> #+BEGIN_SRC python :session :results output :exports results
> for i in range(3):
> print("Iter {0}".format(i))
>
> #+END_SRC
>

Try using ob-ipython. It doesn't have that issue for me.


John

---
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] Saving org-capture buffer while writing it

2017-02-21 Thread Ian Barton

> > Hi,
> >
> > Sometimes when I am taking notes, I end up spending a lot of time in a
> > capture buffer. If I happen to switch to something else, I end up
> > loosing the capture buffer. I probably just kill the buffer
> > accidentally, or do `C-c C-k'.
> >
> > Is there a way I can take backups of the buffer to a file?
>
> I usually just save it (C-c s) and it is saved to where it would be
> saved anyway when I eventually do C-c C-c.
>
> Myles
>
If I am going to leave a capture buffer open for a long time I just do
C-u C-c C-c, which saves the capture buffer and then switches to the
buffer where it's saved where you can continue entering text.

Ian.



Re: [O] Possible Bug in Capture.

2017-02-21 Thread Ian Barton


>
> Your template is invalid. Per `org-capture-templates', it should be
>
>   (file+datetree "path/to/file")
>
> IOW, there should be no "Notes."
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Thank you! Things have obviously changed since the last time I set up
a capture template. Note to self: "Remember to RTFM first".

Ian.



Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

2017-02-21 Thread Aaron Ecay
Hi Chuck,

2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen:

[...]


> 
> Allowing header args to be processed (as before) also allows for arbitrary 
> code to be executed.  The point of setting ‘org-export-use-babel’ or 
> `org-export-babel-evaluate' to nil was to prevent this.  For that reason 
> the former behavior was a bug.

Iʼm not sure I agree that itʼs so simple.  There are still ways to execute
arbitrary code on export independently of babel (e.g. eval macros).  The
advice to use o-e-babel-evaluate for security was never (IMO) correct –
the only properly secure wat to export untrusted documents would involve
some kind of sandboxing of the emacs executable.

The original bug that led to the change in the behavior of o-e-b-e was
that a misspecified var header would lead to an error on export
.  I think the
change was an overreaction to that problem (and insofar as it changed
the long-standing behavior of that variable, a regression).  Export
(c/sh)ould still respect static (i.e. non-executable) header args;
o-e-b-e should only inhibit executable args.  From the standpoint of
implementation, the execution of code in header args can be controlled
by the inhibit-eval argument to org-babel-read and the light argument to
org-babel-get-src-block-info (and both functions might need to be
extended to look at dynamic variables in addition to these arguments).

Taking a step back, I would ask what justifies o-e-b-eʼs existence at
all.  This thread demonstrates that itʼs not the right way to prevent
babel blocks from executing on export.  Itʼs also not a good solution to
the security issue.  Given the potential for confusion, Iʼd be in favor
of deprecating it entirely unless thereʼs some compelling reason for it
to exist that Iʼve overlooked.

-- 
Aaron Ecay