Re: [O] Effort estimates on repeating tasks

2019-10-03 Thread garjola
On Thu 19-Sep-2019 at 21:39:10 +02, garj...@garjola.net wrote: 
> Hi,
>
> I like the warning in the mode line when the time clocked on a task goes
> beyond the effort estimates in the properties drawer.
>
> However, I don’t know how to use this for repeating tasks or habits.
> That is, I want to work on a given task every day for less than N
> minutes and be warned when going beyond this amount. Of course,
> using the Effort property will warn me the first time, but will be
> useless after that, unless I delete the clocked time at the beginning of
> each new session.
>
> Is there a way to do that properly?
>
> Thanks in advance for your help.
>
> G.

Hi,

I have been investigating this and I think I could advice 
org-clock-get-clock-string. I have never written advices to functions and I 
don’t know org’s API.

Since I want to change the clock string only for repeating tasks, I have done 
this, which just adds “Repeating” to the clock string when clocking a repeating 
task:

#+BEGIN_SRC emacs-lisp
(defun ocgcs (orig-fun  args)
  "Advice for effort in repeating tasks"
  (progn
(if (org-entry-get (point) "LAST_REPEAT")
(concat "Repeating" 
(apply orig-fun args))
  (apply orig-fun args
(advice-add 'org-clock-get-clock-string :around #'ocgcs)
#+END_SRC

What I would like to do now is getting the total time clocked today for the 
task and then compare it to the Effot property value. I have found how to get 
the total amount of time clocked for the task, but I don’t know how to limit 
this to today.

Any ideas?

Thank you.

G.



Re: [O] [RFC] Document level property drawer

2019-10-03 Thread Adam Porter
Hi Gustav,

Gustav Wikström  writes:

> I'd argue that precedence already works that way. One has to take
> inheritance into account. With inheritance turned on, tell me which
> value for Property1 is used for the nodes in the following example:
>
> #+begin_src org
>   ,* Node 1
>   ,* Node 2
>   :PROPERTIES:
>   :Property1: Value1
>   :END:
>
>   ,#+PROPERTY: Property1 Value2
> #+end_src
>
> As you'll see line number already isn't the deciding factor.
>
> With two ways to define properties it makes sense to first think of
> which syntax to promote as "more important" and then to think of
> precedence rules for duplicates within each syntax.
>
> Having the same syntax for node level 0 as for regular nodes makes the
> property functionality easy to understand and congruent. Something I
> think is worth promoting by saying that property blocks on file-level
> has precedence over the keyword syntax.

I think this example illustrates the issue better.  This is how Org
currently works:

#+BEGIN_SRC org
  # Category here is "Alpha"

  ,* Node 1

  # Category here is "Alpha"

  ,* Node 2
  :PROPERTIES:
  :CATEGORY: Beta
  :END:

  # Category here is "Beta"

  ,#+CATEGORY: Alpha
#+END_SRC

IIUC, your proposal would work like this:

#+BEGIN_SRC org
  :PROPERTIES:
  :CATEGORY: Gamma
  :END:
  
  # Category here is "Gamma"

  ,* Node 1

  # Category here is "Gamma"

  ,* Node 2
  :PROPERTIES:
  :CATEGORY: Beta
  :END:

  # Category here is "Beta"

  ,#+CATEGORY: Alpha
#+END_SRC

So the #+CATEGORY: line has no effect because of the first-line property
drawer.

In Org, some keywords are special, like #+CATEGORY.  For many years,
such keywords have had file-wide effects regardless of their placement
in the file.  IIUC, your proposal would change that, and that would
still be a major, breaking change.

> If you think of the document as an outline, something Org mode is all
> about, it makes sense to also think of things before the first
> headline as "node level 0". And with that way of conceptually thinking
> of the document it makes perfect sense to have a property drawer fixed
> at the top - in the same way as it is required for all other node
> levels.

What you're proposing is actually a fundamental change to the way Org
documents are interpreted.  Org documents are not currently an outline,
just a series of elements which may include an outline.  Text and
elements before a first heading are not part of a node, they're just
text and elements in the document.

If Org were a new project, I think your proposal might be very
suitable.  But at this point, it would be a significant, breaking
change, even without the org-element parser changes.

Consider as well that the Org format has recently been seeing wider use,
with more implementations becoming available in several languages and on
several platforms.  Fundamental changes like this would affect more than
just the official Org software, and the costs of breaking software in
the wider Org community should be carefully considered.




Re: [O] [RFC] Document level property drawer

2019-10-03 Thread Adam Porter
Marco Wahl  writes:

> You say the visibility is better for the #+-property keywords.  I say
> they can occur _anywhere_ in the file and even in some drawers.  See
> above "#+CATEGORY:  cat-doc-prop-keyword-2".
>
> Further you say 
>
 - However, it seems to me that the simplest, most natural protocol would
   be for later declarations to override earlier ones.
>
> This means that cat-doc-prop-keyword-2 from the example defines the
> CATEGORY property which at least I find not so natural.  And I already
> stated what I find natural.

Hi Marco,

Org may allow #+KEYWORD: lines to appear anywhere in a file, including
in arbitrary drawers, but that's up to the user.  If the user chooses to
hide them in drawers, it's his responsibility.

AFAICT that's not a common or generally recommended thing to do.  Most
Org files have such lines at the top of the file, and some under a
heading at the bottom of the file with other settings.  Such lines don't
need to be in drawers, and this proposal wouldn't change that.

So I think it would be confusing if settings in a drawer at the top of
the file were to absolutely override settings outside of drawers (which
would mean that hidden settings could override plainly visible ones).
The most natural protocol would be like written language: later
declarations override earlier ones.




Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation

2019-10-03 Thread Adam Porter
"Fraga, Eric"  writes:

> Hi Adam,
>
> I've had a chance to play with it a little bit.  Works very well
> generally.  Some notes:

Hi Eric,

> - a way to exit the sidebar-tree mode to get back to the full buffer
>   (e.g. to run commands that require the whole file).  The documentation
>   seems to indicate that 'q' should do this but it didn't work for
>   me.  I do use evil mode but q didn't work whether in evil or emacs
>   states.

Please note that it's not a mode, it's just a side window displaying an
indirect buffer in Org mode (like how org-tree-to-indirect-buffer
works).  You can do anything in the tree-view buffer that you can do in
any other Org buffer, including inputting characters, calling Org
commands, switching windows, killing the buffer, deleting the window,
etc.

The only difference is that certain keys are bound by default to
commands which are more appropriate for the tree-view buffer, e.g. the
cycle commands don't show body text, and RET/mouse-1 jump to headings in
the source window.

"q" is no longer bound differently, and the readme has been updated.

> - hitting RET on a headline which has subtrees doesn't show the
>   subtrees.  Can this be customized?  It might be nice to have two
>   different bindings to allow for recursion and not.

Like other Org buffers,  is used to cycle headings by default.  As
documented, the keymap org-sidebar-tree-map is used, which you're free
to customize.

I recently improved the tree-view cycling command to work more like
org-cycle.  Please let me know if you think it needs more work.

> - invoking org-sidebar-tree when point is at the top of the file,
>   e.g. on the #+title: line of a document, gives an error:
>   outline-back-to-heading: Before first heading.

That bug is fixed.

Note as well that the tree-view can be activated for narrowed Org
buffers, in which case it is also narrowed to the visible portion of the
buffer.  So you can, e.g.:

1.  "M-x customize-option RET org-sidebar-tree-jump-fn RET", and set it to
use indirect buffers when jumping to headings.
2.  "M-x org-sidebar-tree RET" in an Org buffer.
3.  Move point to a heading and press RET to display that heading in the
other window.
4.  "M-x org-sidebar-tree RET" to display only that subtree in the
tree-view buffer.

This makes it easy to treat subtrees as separate projects or entities.

Thanks for your feedback!




[O] export file within a folder (and possibly with a pattern)

2019-10-03 Thread Luca Ferrari
Hi all,
in my org files I've got something like:

#+export_file_name: PDF/2019_MY_PRESENTATION

but I've seen that if the containing folder (PDF) is not there there
is no way to generate the file at all. Is there any toggle to
instrument org to create the directory if it does not exist?
Also, any chance to place a pattern (e.g., timestamp) in the name of
the exported file?

Thanks,
Luca



Re: [O] Dates with repeaters, times and range

2019-10-03 Thread Robert Pluim
> On Wed, 2 Oct 2019 09:31:33 +, "Fraga, Eric"  said:

Eric> On Tuesday,  1 Oct 2019 at 23:38, Nathan Neff wrote:
>> I have a meeting that's scheduled from 10:00 - 11:00 for the next three
>> days.

Eric> This is discussed in the FAQ on the org mode website.

Eric> Quick answer: not possible the way you wish.  Instead, the easiest
Eric> solution is to make a one day entry and then use M-x
Eric> org-clone-subtree-with-time-shift RET.

This works for me:

**  Meeting 08:30-15:00
<%%(org-block 2019 10 2 2019 10 4)>


You can even make the period discontiguous:

**  Meeting 08:30-15:00
<%%(org-block 2019 10 2 2019 10 4)>
<%%(org-block 2019 10 7 2019 10 8)>



[O] Specifying ATTR_HTML class for source blocks

2019-10-03 Thread Martin G . Skjæveland

Hi all,

I would like my source blocks to be exported to HTML as textareas with a 
class attribute -- so I can later use this in my javascript code. I can 
use ":textarea t" [1], but it seems that other attributes except width 
and height are ignored:


#+ATTR_HTML: :textarea t :class testing
#+BEGIN_SRC n3
My code
#+END_SRC

gives

My code


and, testing without ":textarea",

#+ATTR_HTML: :class testing
#+BEGIN_SRC n3
My code
#+END_SRC

gives

My code



Preferably, I want the following html:

My code


Is there a way to achieve this?

Thanks,
Martin

[1] https://orgmode.org/manual/Text-areas-in-HTML-export.html