Re: [O] Deadline warning period, and property to override it

[Eric S Fraga]

On Sunday, 19 Nov 2017 at 10:54, James Harkins wrote:
> Hi,
>
> Two questions about deadline items in the agenda.
>
> 1. The default warning period for upcoming deadlines is 14 days. There
> must be a variable to control this, but I'm having trouble finding it
> in the manual.

org-deadline-warning-days

> 2. Is there a property to override the warning period for specific
> headlines? For example, if I have a project due on a certain date, a
> two-week warning makes sense. But, for paying the rent, a two-week
> warning means that I see the warning for half the month, which is a
> bit too much. I'd like to make that one 7 days.

you can specify the warning time directly in the time stamp.  See
example in the info manual (section 8.3: deadlines and scheduling).

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

Re: [O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Eric S Fraga]

On Sunday, 19 Nov 2017 at 13:03, Charles R (Charlie) Martin wrote:
> I think the problem is that if you register graphviz-dot as a language, it
> generates that require.  I got it halfway working by changing the language
> back to just dot; I need to go back figure out how to nonetheless use
> graphviz-mode for editing.

I got my setup working.  I had to use the git version of graphviz-dot
mode as the one that comes with emacs-goodies-el Debian package is out
of date and doesn't load (assumes that there is a variable called
default-tab-width, which does not exist, at least in Emacs 26+, whereas
the newer version uses tab-width).

If you (require 'graphiz-dot-mode) before any use of org for editing dot
files, everything seems to work just fine with the language registered
as dot.

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

Re: [O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Eric S Fraga]

On Sunday, 19 Nov 2017 at 13:03, Charles R (Charlie) Martin wrote:
> I think the problem is that if you register graphviz-dot as a language, it
> generates that require.  I got it halfway working by changing the language
> back to just dot; I need to go back figure out how to nonetheless use
> graphviz-mode for editing.

I see.  You are right: there is a problem with the mode being found for
dot files.  I cannot even load graphviz-dot-mode as it complains about
default-tab-width not being defined.

I'll play a bit to see if I can figure this out.

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

[O] Deadline warning period, and property to override it

[James Harkins]

Hi,

Two questions about deadline items in the agenda.

1. The default warning period for upcoming deadlines is 14 days. There must be 
a variable to control this, but I'm having trouble finding it in the manual.

2. Is there a property to override the warning period for specific headlines? 
For example, if I have a project due on a certain date, a two-week warning 
makes sense. But, for paying the rent, a two-week warning means that I see the 
warning for half the month, which is a bit too much. I'd like to make that one 
7 days.

Thanks,
hjh

Re: [O] ob-python newline & indentation behavior

[Kyle Meyer]

Jack Kamm  writes:

> Here is the new version of the patch:

I haven't had any luck applying this patch to master.  Perhaps your
email client is altering the inline patch; you can instead attach the
output file of 'git format-patch'.

> From f009da37d3b7e2730abb8cbb10f4d07b3d456dd8 Mon Sep 17 00:00:00 2001
>
> From: Jack Kamm 
> Date: Sun, 19 Nov 2017 07:13:56 +
> Subject: [PATCH] Squashed commit of the following:
>
> commit d1fe88a9f61a8e7082f08b7c190a29737bb655d5
> Author: Jack Kamm 
> Date:   Sun Nov 19 07:08:31 2017 +
>
> fix block ending in blank lines; send multiline blocks to tmpfile
>
> commit fcc5a7795e882716775c9d925b0cd5b657da041b
> Author: Jack Kamm 
> Date:   Sat Nov 18 22:40:31 2017 +
>
> fix newlines and blanklines when sending codeblock to tmpfile
>
> commit a5d553ece9f6ee35cd1e273e554a21a19e80ec3c
> Author: Jack Kamm 
> Date:   Sat Nov 18 21:47:09 2017 +
>
> fix newline/indentation issues in ob-python :session

Please see 
for information on Org's convention for commit messages.  In addition to
following this format, ideally the message would contain a brief
description of the problem the patch is fixing.

> ---
>  lisp/ob-python.el | 29 +
>  1 file changed, 29 insertions(+)

This patch probably passes the TINYCHANGE threshold, so please see
 for
information about assigning copyright.

> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
> index 60ec5fa47..c3dba1565 100644
> --- a/lisp/ob-python.el
> +++ b/lisp/ob-python.el
> @@ -303,6 +303,9 @@ last statement in BODY, as elisp."
>(mapc (lambda (line) (insert line) (funcall
> send-wait))
>  (split-string body "[\r\n]"))
>(funcall send-wait)))
> +(body (if (string-match-p ".\n+." body) ;; Multiline

nitpick: When a comments is on the same line as code, the convention is
to use a single ";".

I see your point that sending all multiline code through a temporary
file is consistent with python.el's behavior.  When you say that it
"gives more consistent behavior for ":results output", I believe you're
talking about problems with ">>>" and "..."  markers leaking into the
output.  I agree that this change should be an improvement since I think
most of the prompt issues are racy problems related to sending multiple
lines.  (I think there still might be a unrelated prompt issue regarding
python.el's startup message leaking into the output of the first
executed block.)

Looking back at my summary of ob-python problems in
,
this seems like a good way to take the solution to problem #3
(indentation, multiline syntax errors) and apply it to problem #1
(markers leaking into the output).  Nice, hadn't occurred to me.

Assuming we do go this direction, I wonder if there's any ob-python code
that can be cleaned up or simplified since the multiline processing
logic is no longer needed.

> +  (org-babel-python--replace-body-tmpfile body)
> +body))
>   (results
>(pcase result-type
>  (`output
> @@ -340,6 +343,32 @@ last statement in BODY, as elisp."
>(substring string 1 -1)
>  string))
>
> +
> +(defun org-babel-python--replace-body-tmpfile (body)
> +  "Place body in tmpfile, and return string to exec the tmpfile.

nitpick: s/body/BODY/ here and below

> +If last line of body is not indented, place it at end of exec string
> +instead of tmpfile, so shell can see the result"

nitpick: missing trailing period

This is the part of the patch that I'm unsure about.  I don't like that
it

  * can fail if the last line is a non-indented, continued string

  * doesn't allow you to get a return value for commons things like
conditionals, try-except blocks, context statements.

I can't think of a good solution, though.  Stepping back a bit, I think
it's unfortunate that python blocks handle ":results value" differently
depending on whether the block is hooked up to a session or not.  For
non-sessions, you have to use return.  Using the same approach
(org-babel-python-wrapper-method) for ":session :results value", we
could then get the return value reliably, but the problem with this
approach is that any variables defined in a ":results value" block
wouldn't be defined in the session after executing the block because the
code is wrapped in a function.

So at this point I think the choice is between

  * restricting the return value to unindented last lines and not
supporting continued strings in the last line

  * wrapping the return value with org-babel-python-wrapper-method and
not supporting persistent session variables in that block

  * not supporting ":session :results value"

> +  (let* ((body (string-trim-right body))
> +(tmp-file (org-babel

Re: [O] Summary for user: function for inserting a block

[Eric Abrahamsen]

AW  writes:

> Hi!
>
> I updated to orgmode 9.1.3 and tried to find out about this new feature. 
>
> In vain. C-c C-x w is undefined.
>
> Can someone give a short abstract about the new function for inserting a 
> block?

The change is in master now, I don't think it will be available until
9.2 is released...

Re: [O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Charles R (Charlie) Martin]

oh and the answer to your direct question is 9.1.3.

I suspect this is related to the issue where you can have a source-type
'shell' but only can execute a shell blockif it's source type 'sh'.

On Sun, Nov 19, 2017 at 1:03 PM, Charles R (Charlie) Martin <
chasrmar...@gmail.com> wrote:

> I think the problem is that if you register graphviz-dot as a language, it
> generates that require.  I got it halfway working by changing the language
> back to just dot; I need to go back figure out how to nonetheless use
> graphviz-mode for editing.
>
> On Sun, Nov 19, 2017 at 12:57 PM, Eric S Fraga  wrote:
>
>> On Saturday, 18 Nov 2017 at 12:57, Charles R (Charlie) Martin wrote:
>> > I'm trying to use `dot` inside `org-mode` and having no luck, because
>> when
>> > I evaluate
>>
>> What version of org are you using?  The version I'm using has no
>> reference to ob-graphviz-dot.
>>
>> (but the version I am using is a week or so out of date...).
>>
>> --
>> : Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d
>>
>
>

Re: [O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Charles R (Charlie) Martin]

I think the problem is that if you register graphviz-dot as a language, it
generates that require.  I got it halfway working by changing the language
back to just dot; I need to go back figure out how to nonetheless use
graphviz-mode for editing.

On Sun, Nov 19, 2017 at 12:57 PM, Eric S Fraga  wrote:

> On Saturday, 18 Nov 2017 at 12:57, Charles R (Charlie) Martin wrote:
> > I'm trying to use `dot` inside `org-mode` and having no luck, because
> when
> > I evaluate
>
> What version of org are you using?  The version I'm using has no
> reference to ob-graphviz-dot.
>
> (but the version I am using is a week or so out of date...).
>
> --
> : Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d
>

Re: [O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Eric S Fraga]

On Saturday, 18 Nov 2017 at 12:57, Charles R (Charlie) Martin wrote:
> I'm trying to use `dot` inside `org-mode` and having no luck, because when
> I evaluate

What version of org are you using?  The version I'm using has no
reference to ob-graphviz-dot.

(but the version I am using is a week or so out of date...).

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

Re: [O] Public TODO agendas

[Eric S Fraga]

On Sunday, 19 Nov 2017 at 11:10, David Arroyo Menendez wrote:
> Hello Colin,
>
> org-secretary seems designed to manage teams. I want read agendas of
> org-mode users, friends ... In Barcelona Supercomputing Center all
> people is sharing the agendas to stimulate to the people to collaborate
> in good ideas, I like this methodology, but I prefer use org-mode. Many
> people in org-mode is connected with the science or creative
> programming, perhaps is a good idea share the agenda between us.

I guess one approach could be to make specific agenda files available on
a remote server and use tramp syntax to add these files to the
org-agenda-files variable?  (untested)  Of course, this would be limited
to those access methods defined for tramp, i.e. ssh in practice, which
might be quite limiting.

A more general approach would be to export your agenda to Google's
calendar or equivalent and share that and import any shared calendar
using an ical access to these.  This is possible (my wife and I share our
calendars that way) but not purely org.


-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

[O] Potential bug: embedded dot fails on require ob-graphviz-dot

[Charles R (Charlie) Martin]

I'm trying to use `dot` inside `org-mode` and having no luck, because when
I evaluate

(org-babel-do-load-languages
 'org-babel-load-languages
 '((dot . t)))

it tries to require `ob-graphviz-dot` -- unsuccessfully.

Debugger entered--Lisp error: (file-error "Cannot open load file" "No
such file or directory" "ob-graphviz-dot")
  require(ob-graphviz-dot)

I can't find `ob-graphviz-dot` anywhere.

Re: [O] ob-python newline & indentation behavior

[Kyle Meyer]

Jack Kamm  writes:

> I adapted your old patch to the current master branch. I also extended it
> to work for ":results value" (the original patch only worked for ":results
> output"). I did this by not writing the last line of the code block to the
> tmpfile, unless it is indented.
>
> I've never contributed before so would appreciate any comments on this
> patch, and how to get it accepted. Cheers, Jack.

Thanks for picking this up.  I'll find time in the next couple of days
to review your patch.  For general information about contributing, take
a look at http://orgmode.org/worg/org-contribute.html

-- 
Kyle

Re: [O] Public TODO agendas

[Colin Baxter]

> "David" == David Arroyo Menendez  writes:

David> Hello Colin,

David> org-secretary seems designed to manage teams. I want read
David> agendas of org-mode users, friends ... In Barcelona
David> Supercomputing Center all people is sharing the agendas to
David> stimulate to the people to collaborate in good ideas, I like
David> this methodology, but I prefer use org-mode. Many people in
David> org-mode is connected with the science or creative
David> programming, perhaps is a good idea share the agenda between
David> us.

Ok - best of luck in finding what you want.

Best wishes,

-- 
Colin Baxter
m43...@yandex.com
-
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
-
The sole cause of all human misery is the inability of people to sit
quietly in their rooms.  Blaise Pascal, 1670

Re: [O] Public TODO agendas

[David Arroyo Menendez]

Hello Colin,

org-secretary seems designed to manage teams. I want read agendas of
org-mode users, friends ... In Barcelona Supercomputing Center all
people is sharing the agendas to stimulate to the people to collaborate
in good ideas, I like this methodology, but I prefer use org-mode. Many
people in org-mode is connected with the science or creative
programming, perhaps is a good idea share the agenda between us.

Thanks!

[O] Summary for user: function for inserting a block

[AW]

Hi!

I updated to orgmode 9.1.3 and tried to find out about this new feature. 

In vain. C-c C-x w is undefined.

Can someone give a short abstract about the new function for inserting a 
block?

Thank you!

Regards,

Alexander

Re: [O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]

[Eric S Fraga]

On Friday, 17 Nov 2017 at 23:30, Nicolas Goaziou wrote:

[...]

> It would be nice to know, however, if there is the same problem with
> that new implementation.

I have been using display-line-numbers in emacs 26+ for a while now,
with org-indent-mode, and have not seen any strange behaviour along the
lines described by the OP.  There are some issues with the width of the
space for line numbers that arise when hundreds or thousands of lines
are hidden but this is not due to org.

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-162-gde289d


signature.asc
Description: PGP signature

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

On 2017-11-17, Nicolas Goaziou wrote:

> SUBTITLE keyword may not be supported in every back-end. As
> a consequence, supporting a global {{{subtitle}}} macro sounds
> presumptuous.
>
> Anyway, it begs for generalisation. The same problem is going to arise
> for CREATOR, KEYWORDS, and WHATNOT. Instead of {{{subtitle}}}, we could
> implement {{{option(KWD)}}}. Basically,
>
>   {{{option(SUBTITLE)}}} => (org-element-interpret-data (plist-get
> info :subtitle))
>
> Options with a `split' behaviour would need a special treatment,
> however.
>
> WDYT? Do you want to have a stab at it?

Thanks for your reply.  That would be great but goes way beyond my
current understanding of org internals.  I've never heard of `split'
behaviour.  Currently I don't have time to investigate this.

I'll stick with a local change for now.

Best wishes
Jens

Re: [O] org-depend: TRIGGER XYZ(KEYWORD) not working

[Karl Voit]

* Karl Voit  wrote:
> Hi,
>
> I am playing around with org-depend[1] again[2].

I forgot to mention: I am using maint from the git from today.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

[O] org-depend: TRIGGER XYZ(KEYWORD) not working

[Karl Voit]

Hi,

I am playing around with org-depend[1] again[2].

I noticed that certain TRIGGER events do not get executed.

> # -*- mode: org; coding: utf-8; -*-
> * heading 1
> :PROPERTIES:
> :ID:   foo
> :TRIGGER: bar(NEXT) baz(NEXT)
> :END:
> 
> * Heading 2
> :PROPERTIES:
> :ID:   bar
> :END:
> 
> * Heading 3
> :PROPERTIES:
> :ID:  baz
> :END:

First observation:

When I set the heading 1 to DONE (without assigning it any other
keyword), the TRIGGER events are ignored totally.  I guess this is
an edge-case that may be considered as a bug.

Second observation:

However, what is bugging me even more is that even when "heading 1"
has a TODO keyword assigned, in *some* cases, the TRIGGER event does
not get executed when I do it in my large Org-mode file.

Copying the corresponding headings (the one with the TRIGGER prop
and the headings containing the "target" IDs) from my real-world
Org-mode file to my small test.org from above and marking the
heading that contains the TRIGGER properties to DONE, it then works
as expected. 

I then took the simple example from above, added a TODO keyword to
the heading 1, copied it to my real-world Org-mode file and even
this did not work: Heading 2 and 3 don't get their "NEXT" keyword
assigned.

So the behavior changes within different Org-file contexts.
Therefore, I do have an issue creating a minimal example to
demonstrate the bug.

Can somebody give me an advice how to debug this behavior?

[1] http://orgmode.org/worg/org-contrib/org-depend.html
[2] http://karl-voit.at/2016/12/18/org-depend/

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/