Re: [O] Effort estimates on repeating tasks
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
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
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
"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)
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
> 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
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
