[O] Bug: ordered property blocks grandchildren [9.1.3 (9.1.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171116/)]

Create a file tmp.org with contents * TODO parent :PROPERTIES: :ORDERED: t :END: ** TODO child1 ** TODO child2 *** TODO grandchild1 *** TODO grandchild2 1. emacs -Q 2. M-: (setq org-enforce-todo-dependencies t) RET 3. C-x C-f tmp.org RET 4. Move point to

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross wrote: > > OK, thanks for the additional information. That helps a lot. > > We can now narrow down where the issue is. > > After having looked (only very casually) at some of the org date/time > related functions, I think there may

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

Sorry for the spam, but I am digging to see how deep the rabbit hole goes. All five of the first branches in org-matcher-time are wrong (again, local timezone dependent): (org-time= "<2017-11-01>" "") nil (org-time= "<2017-10-31>" "") nil (org-time= "<2017-11-02>" "") nil (org-time=

[O] Bug: org-parse-time-string et al hit recursion limit [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

Running (org-parse-time-string "<@@@>") results in hitting max-lisp-eval-depth org-parse-time-string calls org-matcher-time calls org-2ft calls org-parse-time-string There is a condition-case in org-2ft that catches the error and returns 0, but it would be nice if this wasn't implemented via

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

I found another one (It is 2017-11-01 in local time for me) (org-time= "<2017-11-01>" "") nil This is also local timezone dependent. Tim made the point that these floats are not intended to be Unix timestamps and only used for comparison, but this implementation detail leaks quite heavily.

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Wed, Nov 1, 2017 at 8:27 PM, Tim Cross wrote: > > I get that, what I am not clear about is where you encounter this issue > when using org .eg. is it when entering now as a date for generating an > agenda of past or current scheduled items etc or is this a problem with >

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

olid way to > address all of these issues. I suspect there are still edge cases in > time related computations which fail even with the UTC approach and > there are certainly extensions which could benefit from explicit TZ > information (for example, taskgjuggler, which does time calc

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Wed, Nov 1, 2017 at 1:55 PM, Nicolas Goaziou wrote: > > IIRC, the point is to remove DST in durations, i.e., in the difference > between two dates. One way to do that is to assume UTC in both start end > end date. Most of the commits are about making sure UTC is used

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

Apologies, my reply was partially omitted. My full reply follows On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross <theophil...@gmail.com> wrote: > > Allen Li <vianchielfa...@gmail.com> writes: > >> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> wr

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross <theophil...@gmail.com> wrote: > > Allen Li <vianchielfa...@gmail.com> writes: > >> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> wrote: >>> >>> My preferences would be >>>

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross wrote: > > My preferences would be > > 1. If a timestamp does not include the TZ, then assume the local TZ > 2. If a timestamp does include the TZ, honour that TZ Org mode does not support TZ in time strings and adding support

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Tue, Oct 31, 2017 at 10:41 PM, Tim Cross wrote: > > I think this whole issue really requires a lot more analysis and > design. Just removing or cancelling various commits is unlikely to > improve matters and could result in new problems. You're right, but the new

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Tue, Oct 31, 2017 at 11:52 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Allen Li <vianchielfa...@gmail.com> writes: > >> Can you clarify on the issues the UTC timezone fixes? > > At the moment, I can only give you a pointer, which is commit > 97a1a49

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Tue, Oct 31, 2017 at 11:23 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> Removing the t for zone fixes it > > [...] > >> I will also note that the FIXME comment in org-parse-time-s

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

On Mon, Oct 30, 2017 at 5:40 PM, Allen Li <vianchielfa...@gmail.com> wrote: > (current-time-string (time-to-seconds (org-2ft "<2017-10-31>"))) > "Sun Oct 29 17:00:00 2017" > > This seems wrong > > In org-2ft > > (org-parse-time-string s ni

[O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

(current-time-string (time-to-seconds (org-2ft "<2017-10-31>"))) "Sun Oct 29 17:00:00 2017" This seems wrong In org-2ft (org-parse-time-string s nil t) The t means use UTC instead of Emacs local time. However, Org translates into (float-time), which is in Emacs localtime. 1. SCHEDULED>""

Re: [O] Bug: Missing agenda files file causes org to fail [9.1.2 (9.1.2-22-ga2a034-elpaplus)]

On Sat, Oct 28, 2017 at 1:44 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> If org-agenda-files is set to a file through customize.el and that >> file is missing, Org will fail to load at all.

[O] Bug: Missing agenda files file causes org to fail [9.1.2 (9.1.2-22-ga2a034-elpaplus)]

If org-agenda-files is set to a file through customize.el and that file is missing, Org will fail to load at all. Org should not fail to load, either it should create an empty file or it should print a warning and still load itself. I think the former would be easier to implement.

[O] org-capture-kill uses the kill ring

org-capture-kill (C-c C-k) used to abort capturing puts the contents of the capture buffer into the kill ring. This is obstructive when the user wants to abort a capture, but save a portion of the text into the kill ring to yank elsewhere. The aborted capture contents will replace the desired

Re: [O] [PATCH] Use the same TODO keyword as the current heading

On Tue, Oct 17, 2017 at 12:47 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> This makes org-insert-todo-heading-respect-content use the previous >> heading of the same level instead of the pre

Re: [O] [PATCH] Update documentation on org-protocol template placeholders

On Tue, Oct 17, 2017 at 1:01 AM, Nicolas Goaziou wrote: > > This is not directly related to your patch, but isn't something wrong > here? > > I.e., shouldn't Org Protocol be able to capture arbitrary keywords > according to the attributes of the "org-protocol" link? What

[O] [PATCH] Use the same TODO keyword as the current heading

This makes org-insert-todo-heading-respect-content use the previous heading of the same level instead of the previous heading regardless of level. Given: * TODO some task ** WAITING other task The original code yields: * TODO some task ** WAITING other task * WAITING This

[O] org-refile and Archive headings

The current default behavior for org-refile and org-reverse-note-order does not treat Archive headings specially. Consider a .org file: * Some projects ** Some item... ** Archive :ARCHIVE:... Refiling an entry to "Some projects" results in: * Some projects ** Some item... ** Archive

[O] [PATCH] Update documentation on org-protocol template placeholders

* doc/org.texi (@code{capture} protocol): Fix placeholder names (Template expansion): Add org-protocol placeholders * lisp/org.el (org-store-link-plist): Fix docstring grammar (org-store-link-props): Fix docstring grammar --- doc/org.texi | 25 + lisp/org.el | 5 +++--

[O] Org-specific completing-read-function

Would it be acceptable to have an Org-specific completing-read-function? My use case is that I would like to use a different completing-read function like ido of ivy for Org mode, especially for refiling, but I don't want to modify completing-read-function globally. This isn't entirely

[O] Changing behavior of org-insert-todo-heading-respect-content

Regarding the behavior of org-insert-todo-heading-respect-content, bound to C-S-return, consider the following .org file: * TODO some task ** WAITING other task If point is on the TODO line, pressing C-S-return yields * TODO some task ** WAITING other task * WAITING When I use C-S-return, I

Re: [O] capture template placeholders do not work

On Thu, Oct 12, 2017 at 6:24 AM, Kaushal Modi wrote: > > I don't use org-protocol, but I'd just like to understand how you derived > that. > > Source code: > > (defun org-protocol-do-capture (info) > "Perform the actual capture based on INFO." > (let* ((temp-parts

Re: [O] Bug: Key binding M-S-up does not invoke org-move-subtree-up [9.1.2 (9.1.2-7-g027cfc-elpa @ /home/john/.emacs.d/elpa/org-20171009/)]

On Wed, Oct 11, 2017 at 11:53 AM, Johann Höchtl wrote: > According to the documentation, the keys M-S-up should invoke > org-move-subtree-up, and M-S-down the command org-move-subtree-down but > instead org-shiftmetaup or org-shiftmetadown gets executed (I am on a >

Re: [O] capture template placeholders do not work

On Wed, Oct 11, 2017 at 11:47 AM, Carl Bolduc wrote: > Hi, > > I want to use org-mode to store my bookmarks. I configured the following > template: > ("b" "Bookmark" entry (file+headline "~/org/bookmarks.org" "Bookmarks") "* > %:url %:title %?\n”) %:url and $:title are wrong, they

Re: [O] org-meta-return not on M-RET

On Sat, Sep 16, 2017 at 8:20 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> When I could not get org-meta-return to work in terminal Emacs, I >> realized that org-meta-return is only bound to M-r

[O] org-meta-return not on M-RET

When I could not get org-meta-return to work in terminal Emacs, I realized that org-meta-return is only bound to M-return and not M-RET. Is there any particular reason for this?

Re: [O] [PATCH] org.el: Allow tags without keys in customization

* lisp/org.el (org-tag-alist, org-tag-persistent-alist): Add non-keyed tag type. --- lisp/org.el | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4bb2345a3..32c337601 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3574,8 +3574,10 @@

[O] [PATCH] org.el: Allow tags without keys in customization

* lisp/org.el (org-tag-alist, org-tag-persistent-alist): Add non-keyed tag type. --- lisp/org.el | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 335d6c48a..28b206d99 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3456,8 +3456,10 @@

[O] Bug: org-tag-alist defcustom does not allow ("tag") [9.0.9 (9.0.9-40-gb7fdc3-elpaplus @ elpa/org-plus-contrib-20170710/)]

`org-tag-alist' and `org-tag-persistent-alist' defcustom types are not set up to accept non-cons cell tags like ("tag"). Emacs : GNU Emacs 25.2.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8), modified by Debian Package: Org mode version 9.0.9 (9.0.9-40-gb7fdc3-elpaplus @

[O] Should org-insert-todo-heading be a state change?

Org mode allows logging timestamps and making notes when changing to a TODO keyword: TODO(!) | DONE(!) However, org-insert-todo-heading does not respect this. I'm wondering whether it should. For example, given the above keywords, the intent would most likely be to log when TODO headings

Re: [O] [PATCH 2/2] org-refile: Fix inconsistency when listing refile targets

<m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> I just realized that this patch was applied to the master branch, not >> the maint branch. >> >> The absence of this patch results in the continued life of a bug in >

Re: [O] [PATCH 2/2] org-refile: Fix inconsistency when listing refile targets

-path. Is it possible to backport this to the maint branch? This will require adding the org-protect-slash that I mentioned earlier in this thread. Otherwise, refile is basically unusable for me when full-file-path is set. On Wed, Jun 21, 2017 at 1:01 AM, Allen Li <vianchielfa...@gmail.com>

Re: [O] [PATCH 2/2] org-refile: Fix inconsistency when listing refile targets

Thanks for the info. I was chasing down this bug in org-20170606, where it still required `org-protect-slash`, so I was anxious about its absence in your patch. On Wed, Jun 21, 2017 at 12:55 AM, Sebastian Reuße <s...@wirrsal.net> wrote: > Hello Allen, > > Allen Li <vianch

Re: [O] [PATCH 2/2] org-refile: Fix inconsistency when listing refile targets

On Mon, May 15, 2017 at 5:54 AM, Sebastian Reuße wrote: > * org.el (org-refile-get-targets): Setting org-refile-use-outline-path > to `file' or `buffer-name' causes an additional target for the file’s > root node to be inserted. This functionality was absent when using >

[O] [PATCH] Respect org-attach-commit everywhere

TINYCHANGE * lisp/org-attach.el (org-attach-delete-one): Respect org-attach-commit (org-attach-delete-all): Respect org-attach-commit (org-attach-sync): Respect org-attach-commit --- lisp/org-attach.el | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[O] Bug: org-attach-commit not respected everywhere [9.0.8 (9.0.8-elpa @ /home/mir/.emacs.d/elpa/org-20170606/)]

There are multiple places in org-attach.el where org-attach-commit isn't respected. This means that while adding a new attachment will respect the user setting and not make Git commits, various other commands will. Emacs : GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10) of

Re: [O] Bug: Bulk reschedule with reschedule logging on fails

Hello, I'm replying to a very old thread about a bug. Hopefully I haven't munged the headers. Following is a summary of the thread. Allen Li writes: > When bulk rescheduling TODO items with org-log-reschedule set to > 'note, only the first marked item will get rescheduled.

[O] [PATCH] org-agenda: Store stuck project redo command

* lisp/org-agenda.el (org-agenda-list-stuck-projects): Store the redo command in a text property so it is found correctly. `org-agenda-redo' checks the `org-redo-cmd' text property, not `org-agenda-redo-command'. TINYCHANGE --- lisp/org-agenda.el | 6 +- 1 file changed, 5 insertions(+), 1

Re: [O] Bug: Stuck projects view reverts to tag match on refresh [9.0.5]

On Tue, Apr 18, 2017 at 1:33 AM, Nicolas Goaziou wrote: > I cannot reproduce it. Could you provide an ECM? Create a file tmp.org with the contents: * Stuck :project: * Unstuck :project: ** TODO thing 1. emacs -q 2. Eval: (setq org-agenda-files '("~/tmp.org")

[O] Bug: Stuck projects view reverts to tag match on refresh [9.0.5]

The stuck projects agenda view reverts to a tag match when it is refreshed with r or g Example of original view: List of stuck projects: Refile: Stuck :refile::project: After refreshing: Headlines with TAGS match: project

[O] Bug: Clipboard history is empty when using %^C in capture template [9.0.5 (9.0.5-elpaplus @ /home/mir/.emacs.d/elpa/org-plus-contrib-20170210/)]

Using the %^C expansion in a capture template brings up a minibuffer prompt to read/select a clipboard value, but there are no values to select from. The relevant code is in the function org-capture-fill-template. ("C" (cond ((= (length clipboards) 1) (insert (car clipboards))) ((>

[O] Bug: Missing space in Babel disabled evaluation message [9.0 (9.0-elpa @ /home/mir/.emacs.d/elpa/org-20161102/)]

In ob-core.el, in `org-babel-check-evaluate', when the code block is missing a name, the formatted message is missing a space. Compare: Evaluation of this python code-block (read-future) is disabled. Evaluation of this python code-blockis disabled. Emacs : GNU Emacs 25.1.1

[O] Bug: Missing space in mode line clock display [9.0 (9.0-elpa @ ~/.emacs.d/elpa/org-20161102/)]

There's a missing leading space in the mode line clock display when the current task does not have an effort value set. In org-clock.el, `org-clock-get-clock-string'. Emacs : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8), modified by Debian Package: Org mode version 9.0 (9.0-elpa

[O] Bug: file+olp capture target path relative to default-dir [9.0 (9.0-elpa @ /home/mir/.emacs.d/elpa/org-20161102/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

Re: [O] Bug: Bulk reschedule with reschedule logging on fails [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /home/tyria/.emacs.d/elpa/org-plus-contrib-20160229/)]

Nicolas Goaziou writes: > > This raises another question, though. What is a reasonable behaviour for > bulk schedule+log? I can think of three reasonable options: 1. Prompt for a note, then apply it to all affected items. 2. Prompt for a note, then apply it only to

Re: [O] Bug: Bulk reschedule with reschedule logging on fails [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /home/tyria/.emacs.d/elpa/org-plus-contrib-20160229/)]

The TODO items need to be scheduled first (since it's the REschedule that is causing it). Can you try: * TODO A SCHEDULED: <2016-01-01 Mon> * TODO B SCHEDULED: <2016-01-01 Mon> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Allen Li <darkfel...@fe

[O] Bug: Bulk reschedule with reschedule logging on fails [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /home/tyria/.emacs.d/elpa/org-plus-contrib-20160229/)]

When bulk rescheduling TODO items with org-log-reschedule set to 'note, only the first marked item will get rescheduled. I have reproduced this on a fresh clone of the Git repo with a minimal config. Here is the *Messages* snippet: Org-mode version 8.3.4 (release_8.3.4-635-g268486 @

[O] Asynchronous mobileorg push/pull

Hello, I've started using MobileOrg to do capturing and simple Org tasks on my phone. Although it seems to work well enough so far, running org-mobile-push and org-mobile-pull synchronously locks up Emacs for an unacceptably long period of time. Does anyone have any asynchronous solutions for

<    1   2