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

[Allen Li]

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 grandchild2
5. C-c C-t

user-error: TODO state change from TODO to DONE blocked (by "TODO child1")

The documentation emphasizes that ORDERED is not inherited.  The
behavior that I would expect is that child1 blocks child2, but it should
not block grandchild1 or grandchild2.

However, I think the current behavior is also reasonable under some
workflows.  I’m creating a bug to track opinions, if one behavior is
significantly more desired than the other, or if an option to control
this behavior would be welcome.

Emacs  : GNU Emacs 25.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version
3.22.11), modified by Debian
Package: Org mode version 9.1.3 (9.1.3-elpaplus @
/usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20171116/)

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/)]

[Allen Li]

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 be quite a few issues. I'm not
> convinced the root cause is org-2ft converting to UTC, though I think
> that change has probably revealed some of the issues.
>
> There does seem to be some inconsistency or lack of clarity regarding
> some of these operations and it could well be that the switch to using
> UTC is not the correct approach, but just switching back probably isn't
> either What does appear to be required is increased consistency in some
> of these functions or where/how they are used. .

Thanks.  I think I have been harping a bit too hard on org-2ft, but
indeed it seems to be a bit more systemic an issue.

> To correctly fix this, I feel more analysis is warranted. I'm prepared
> to look at this and present a summary and options, but it will have to
> wait until after 21st when I start leave from work. It is a complex area
> and perhaps my skills won't be up to it, but I should at least be able
> to identify the main areas needing attention/decisions.

My initial approach would be to do some refactoring here, especially
among org-2ft, org-matcher-time, and org-parse-time-string, each of
which calls the others in a cycle and each share a part of the logic
for interpreting Org mode timestamps.

I'm not familiar with refactoring FOSS code via mailed patches, nor if
Org maintainers would welcome such patches, but I would be willing to
do some refactoring here.

>
> Whether we should change back to non-UTC for time comparisons in the
> meantime is not something I feel informed enough to make a call. It
> really depends on the daylight savings time related issues affecting
> clock tables and other functionality.  This is probably something core
> org maintainers will need to make a call on.
>
> Tim

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/)]

[Allen Li]

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= "<2017-11-02>" "<+1d>")
nil

For my immediate bug, all that is needed is a small fix to
org-time-today and modifying the call to float-time in
org-matcher-time.

However, there are a lot of float-time calls in Org mode, and I don't
know how many of them need to be modified to return org-2ft time
shifted timestamps instead of UTC Unix timestamps.

[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/)]

[Allen Li]

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 hitting
the recursion limit.

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/)]

[Allen Li]

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.  Furthermore, the value returned by
org-2ft for these comparisons isn't even constant.

For example (org-2ft "<2017-10-10 10:00:00>") returns 1507629600.0 for
me today, but in four days it will return a different value,
1507626000.0.  Surprise, the offset from local time to UTC is not
constant, even on the same machine in the same timezone.

The most immediate impact of this is that all of Org mode's time
comparison functions will be wrong when called during a local time
offset change.  For those of us who are lucky, this may be twice a
year, but for others who are unlucky, it may be multiple times per
year or month, up to the whims of the local government.

This is one of the reasons I think "we're just using them for
comparisons" doesn't excuse org-2ft doing its little time shift.  The
other reason is all of the regressions that change caused, including
this current bug, and yet another is my gut instinct that this is a
poor design choice from a technical perspective as a software
engineer.

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/)]

[Allen Li]

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
> some custom functions you have written where you need to enter 'now'
> manually and due to the use of UTC in time comparisons are forced to
> adjust manually for UTC or something else? This is what is not
> clear. From my own use, I don't see the issue you describe with
> scheduled items not appearing or appearing when they shouldn't, so don't
> know how to reproduce the issue your having i.e. when I do agenda
> searches, I don't see deadline or scheduled items showing up when they
> should not etc.

It is when doing any kind of tag search.  So org-agenda, mostly.

I'm not surprised you cannot reproduce it because it is dependent on
your local timezone.

>
> This matters because if the issue is the former, then we likely do have
> a real bug. However, if it is the latter, then it may be a bug or it may
> be just an implementation weakness or it could just be a difference of
> opinions on how it should be.
>
> Your examples don't clarify what the issue is. It is obvious that if we
> convert times to UTC for calculation purposes that this will affect the
> display of those timestamps, but as far as I can tell, org doesn't
> convert back and use those converted values in any visible way. Provided
> all values are converted consistently, it should not matter. Therefore,
> if there is a problem, then something must not be getting converted
> correctly, but it is not possible to narrow down where this is without
> more info.

Ah, perhaps I should make the issue clearer.

When I run this at 2017-11-01 20:55:30

(org-2ft "")
1509594900.0

(org-2ft "<2017-11-01 20:55:30>")
1509569700.0

Therefore when org.el does a tag search for SCHEDULED="", it will
not match <2017-11-01 20:55:30>, assuming that I have frozen my system
clock to that time.

>
> If you can provide an ECM then we can avoid assumptions and different
> interpretations and focus on the issue.

Again, this is dependent on your local time zone.  Try setting your
time zone to America/Los_Angeles.

1. emacs -Q
2. Assume it is 2017-10-10 12:00:00 local time
3. Create an agenda file

* TODO thing
SCHEDULED:<2017-10-10 13:00:00>

4. M-x org-agenda RET m SCHEDULED>""

Expected:

thing shows up

Actual:

thing does not show up

>
> Tim
>
> --
> Tim Cross

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/)]

[Allen Li]

On Wed, Nov 1, 2017 at 5:09 PM, Tim Cross <theophil...@gmail.com> wrote:
>
> Let me try to clarify and see if that helps.
>
> Org is only forcing time into UTC format for functions which deal with
> time comparisons. i.e. those which use org-2ft. The reason for doing
> this is to try and avoid issues relating to daylight savings timezone
> changes when performing comparison operations.
>
> It is not clear to me exactly how this is actually creating a problem
> for your scenario as there does not seem to be anywhere in org where
> values created by org-2ft are converted back to human readable time
> strings. If you can provide more details on how this is a practical
> issue in org-mode that might help.

I think I made the problem quite clear multiple times.

Assuming today is 2017-10-31, SCHEDULED<"" will match results
that have SCHEDULED=<2017-11-01> depending on your local time zone.

>
> I do think there was an error in your example analysis.
>
> In your examples of
>
> (current-time-string (float-time))
> "Mon Oct 30 21:21:31 2017" ; right
>
> (current-time-string (org-time-today))
> "Mon Oct 30 00:00:00 2017" ; right
>
> (current-time-string (org-2ft "<2017-10-31>"))
> "Mon Oct 30 17:00:00 2017" ; wrong
>
> the last one is only wrong because you have failed to tell
> current-time-string that the value you are converting is a UTC time. If
> you change the code to
>
> (current-time-string (org-2ft "<2017-10-31>") "UTC")
> "Mon Oct 30 00:00:00 2017" ; correct

No, that is wrong. Mon Oct 30 00:00:00 2017 UTC != Mon Oct 30 00:00:00
2017 UTC-7

(format-time-string "%FT%T%z" (org-2ft "<2017-10-31>"))
"2017-10-30T17:00:00+0700" ; wrong
(format-time-string "%FT%T%z" (org-2ft "<2017-10-31>") "UTC")
"2017-10-31T00:00:00+" ; wrong

In fact, you haven't solved a thing, since (current-time-string
(org-2ft "<2017-10-31>") "UTC") == (current-time-string (org-2ft
"<2017-10-31>"))  The time is still the same, and still wrong, just
formatted differently if you silently drop the TZ info from the time
string.

>
> Now, considering your suggestion to change org-2ft to not use UTC.
>
> If we change org-2ft to not use UTC time, we end up with time
> related calculations which cross daylight savings boarders becoming
> incorrect. So, if you have a clock table where you want to calculate the
> number of hours between two timestamps and one is within daylgiht
> savings time and the other is outside it, your calculation will be out
> by an hour.

Or rather, we end up with time related calculations which cross
daylight savings becoming correct.

But I am beginning to see the picture; someone wanted time related
calculations crossing DST to be incorrect to appear "right" to time
zone naive applications.

>
> As org-2ft is not used in conversion of 'epoch' time to times strings by
> org, I'm not sure reverting the change gains us anything and will likely
> adversely impact things like clock table calculations. What may be
> justified is to add a note to the manual which clearly states that if
> you are using org-2ft in your own code and plan to convert the result
> back to a timestamp string, you need to ensure you explicitly tell the
> function performing the conversion the input value is in UTC and not
> local time.

Yes, org-2ft documentation should be updated at the very least,
assuming that this behavior is desired.

>
> I agree that enhancing org timestamps to include TZ information would be
> a non-trivial chunk of work, I do feel it is the only solid 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 calculations for
> planning and where such calculations can easily cross multiple daylight
> savings TZ changes or include operations covering different timezones
> etc).
>
> Tim
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> 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> wrote:
>>>>>
>>>>> My preferences would be
>>>>>
>>>>> 1. If a timestamp does not include the TZ, then assume the local TZ
>>&g

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/)]

[Allen Li]

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 whenever
> two Org dates are to be used in a duration computation, and nowhere
> else.

Alas, I still can't seem to find the original DST bug.  I'm not sure
using UTC solves DST problems.

For example, in the timezone America/Los_Angeles,

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour

This is what Emacs gives me using the default time zone

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour

This is what Emacs gives me using UTC

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 3 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 3 hours

Using UTC seems strictly wrong to me.

>
> I think the change to org-2ft was a side-effect, since it is indirectly
> used is a duration.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738

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/)]

[Allen Li]

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> 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 isn't
>> the topic of the current bug.
>>
>
> I disagree. The root cause of the bug is due to a lack of clarity
> regarding timezones. I also suspect this is also the basic cause of
> issues relating to the use of timestamps/time strings and daylight
> savings, especially when it comes to performing calculations etc.

Unless I missed something, Org mode does not support explicit
timezones in Org timestamps, and adding such support would take a
large effort [1].

[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00299.html

Unfortunately, I do not have time for the task.  Thus, Org mode
will have to make due with only Org timestamps without an
explicit timezone unless a savior appears.

>
>> I want to emphasize the distinction between timestamps and time
>> strings.  Timestamps are a
>> float value, Unix timestamps.  Time strings are Org mode specific,
>> like <2017-10-30 12:34:56>
>
> Org mode refers to what you are calling time strings as timestamps. In
> reality, there is no difference - one is just a numeric representation
> and the other is a string representation. It is good you have clarified
> your definition to reduce confusion. However, I think the problems are
> arising because of a lack of explicit TZ handling.

There's a pretty significant difference.  Unix timestamps are
standardized and used widely by most computers and Emacs itself.
Unix timestamps are time zone agnostics.

Org timestamps (time strings, whatever) are used exclusively by
Org mode.  As Org timestamps do not support explicit timezones,
they are not time zone agnostic.  The interpretation of an Org
timestamp depends on the time zone of the local machine, whereas
the interpretation of a Unix timestamp does not depend on the
time zone of the local machine.

>
>>
>> Timestamps do not have timezone information since they describe an
>> exact (well, minus leap seconds)
>> point in time, the number of seconds after the epoch.
>>
>
> A point in time is measured in number of seconds since epoch. However,
> if you want to use local (wall) time to display that point, you have to
> include TZ information when converting that number to a more
> meaningful/usable (for humans) format.

I'm not sure what you mean.  Time zone information is provided by
the local machine OS.  If I pass a Unix timestamp to Emacs/the OS
and tell it to format it in human readable format in the local
time zone (the default behavior), then it will be done, without
my having to attach time zone information anywhere.

> The point 'now' for me is UTC+1100
> and for you (based on your previous post) UTC-0700, so our
> representations in string format of this value will be different. Even
> on a single machine, it is also relevant. For example, if I have two org
> timestamps (your times strings) and I want to calculate the number of
> hours between the two, I need to include TZ information as one timestamp
> might be during daylight savings time and the other outside daylight
> savings time.

Ideally, except Org mode does not support including explicit TZ
information in Org timestamps.  Thus, Org mode can only current
interpret Org timestamps according to some blessed time zone.
Four months ago, that blessed time zone changed from the local
machine's time zone to UTC.

> Any calculation which fails to consider TZ information in
> this case will be out by an hour.
>
> If we just take the simple solution and ignore TZ information,

Org timestamps do not have TZ information.  It's not a matter of
not ignoring TZ information, support for TZ information would
have to be added, which as I understand is non-trivial.

> we will
> break calculations which cross daylight savings 'boarders'. I also
> suspect we will get inconsistent behaviour when integrating with other
> systems (such as external calendars, ical integration or sharing
> timestamp data with others etc).

As long as we use Unix timestamps when integrating with other
systems, there is no ambiguity.

>
>>> 3. If the timestamp does not include a time component, default to 0:00:0
>>
>> This is what Org mode does
>>
>>> for the local TZ
>>
>> This is what Org mode used to do, now it interprets 

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/)]

[Allen Li]

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
>>>
>>> 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 isn't
>> the topic of the current bug.
>>
>
> I disagree. The root cause of the bug is due to a lack of clarity
> regarding timezones. I also suspect this is also the basic cause of
> issues relating to the use of timestamps/time strings and daylight
> savings, especially when it comes to performing calculations etc.

Unless I missed something, Org mode does not support explicit
timezones in Org timestamps, and adding such support would take a
large effort [1].

[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00299.html

Unfortunately, I do not have time for the task.  Thus, Org mode
will have to make due with only Org timestamps without an
explicit timezone unless a savior appears.

>
>> I want to emphasize the distinction between timestamps and time
>> strings.  Timestamps are a
>> float value, Unix timestamps.  Time strings are Org mode specific,
>> like <2017-10-30 12:34:56>
>
> Org mode refers to what you are calling time strings as timestamps. In
> reality, there is no difference - one is just a numeric representation
> and the other is a string representation. It is good you have clarified
> your definition to reduce confusion. However, I think the problems are
> arising because of a lack of explicit TZ handling.

There's a pretty significant difference.  Unix timestamps are
standardized and used widely by most computers and Emacs itself.
Unix timestamps are time zone agnostics.

Org timestamps (time strings, whatever) are used exclusively by
Org mode.  As Org timestamps do not support explicit timezones,
they are not time zone agnostic.  The interpretation of an Org
timestamp depends on the time zone of the local machine, whereas
the interpretation of a Unix timestamp does not depend on the
time zone of the local machine.

>
>>
>> Timestamps do not have timezone information since they describe an
>> exact (well, minus leap seconds)
>> point in time, the number of seconds after the epoch.
>>
>
> A point in time is measured in number of seconds since epoch. However,
> if you want to use local (wall) time to display that point, you have to
> include TZ information when converting that number to a more
> meaningful/usable (for humans) format.

I'm not sure what you mean.  Time zone information is provided by
the local machine OS.  If I pass a Unix timestamp to Emacs/the OS
and tell it to format it in human readable format in the local
time zone (the default behavior), then it will be done, without
my having to attach time zone information anywhere.

> The point 'now' for me is UTC+1100
> and for you (based on your previous post) UTC-0700, so our
> representations in string format of this value will be different. Even
> on a single machine, it is also relevant. For example, if I have two org
> timestamps (your times strings) and I want to calculate the number of
> hours between the two, I need to include TZ information as one timestamp
> might be during daylight savings time and the other outside daylight
> savings time.

Ideally, except Org mode does not support including explicit TZ
information in Org timestamps.  Thus, Org mode can only current
interpret Org timestamps according to some blessed time zone.
Four months ago, that blessed time zone changed from the local
machine's time zone to UTC.

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/)]

[Allen Li]

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 isn't
the topic of the current bug.

I want to emphasize the distinction between timestamps and time
strings.  Timestamps are a
float value, Unix timestamps.  Time strings are Org mode specific,
like <2017-10-30 12:34:56>

Timestamps do not have timezone information since they describe an
exact (well, minus leap seconds)
point in time, the number of seconds after the epoch.

> 3. If the timestamp does not include a time component, default to 0:00:0

This is what Org mode does

> for the local TZ

This is what Org mode used to do, now it interprets it as 00:00:00 UTC.

> 4. org-2ft should not enforce the UTC TZ. I agree this is incorrect.
>
> Rationale is that the user should have ability to fully control how
> their timestamps are represented. However, adding the TZ is probably
> just a pain for the majority of use cases, so defaulting to the local
> (wall) TZ is OK provided you can override this consistently by adding
> explicit TZ values.
>
> However, there is some devil in the details we need to work out. For
> example, should we support both TZ names (like AEDT or Australia/Sydney)
> and POSIX style +11/+11:00/+1100, should we add an option to tell org to
> always add TZ info in timestamps which include time components and if
> so, how complex will this need to be e.g. handle setting a future/past
> timestamp which is in a different (daylight savings) offset and what
> about the additional complexity in dealing with timestamp calculations
> where dates might be in different offsets due to daylight savings -
> while all quite possible, it does add significant complexity and this
> may have adverse impact on performance. Not to say we shouldn't do it,
> just that it will take significant work.
>
> I suspect just the first part won't have major impact - at least no more
> than enforcing UTC in org-2ft.

Org mode does not support TZ in time strings currently.  While I would
like such a feature very much,
adding TZ support isn't the topic of the current bug, just fixing how
time strings are interpreted.

>
> Tim
>
> P.S. when you start to think about it, it is easy to see how Java
> screwed up this stuff so badly!

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/)]

[Allen Li]

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 behavior was introduced fairly recently.

> For org to work correctly, especially when interacting/interfacing with
> other systems, such as external calendars, the use of timestamps must
> handle timezones consistently and accurately. This is the only way that
> any daylight savings calculations will work consistently as different
> timezones have different rules for when daylight savings start/finish
> (and these rules change).
>
> If the tests only support UTC/GMT timezone, they are poor tests and need
> to be adjusted to use whatever the timezone is on the system running the
> tests.
>
> I also wonder if there is some inconsistencies in how timestamps without
> a time component are being handled. It would be good to know if the
> issues Alan has observed exist when a full timestamp is used ie. one
> with HH:MM:SS.s and not just date. If timezones are not been applied
> consistently when choosing the default i.e. 00:00:00.0 with respect to
> timezone offset, you will get inconsistencies when moving between
> displayed (string) and calculated (number/seconds since epoch) values.

I think we first need to agree on how Org mode should handle
time.  What seems most natural to me is:

* Floating point timestamps are Unix timestamps, seconds since Epoch.
* Org format time strings are interpreted in the local machine's time zone.

Let us assume that my timezone is UTC-07.  In that case,
<2017-10-30> should be interpreted as 2017-10-30T00:00:00-0700,
or 2017-10-30T07:00:00+.

<2017-10-30>1509346800.02017-10-30T00:00:00-0700
 2017-10-30T07:00:00+
<2017-10-30 12:34>  1509392040.02017-10-30T12:34:00-0700
 2017-10-30T19:34:00+

Currently, org-2ft returns:

<2017-10-30>1509321600.02017-10-29T17:00:00-0700
 2017-10-30T00:00:00+
<2017-10-30 12:34>  1509366840.02017-10-30T05:34:00-0700
 2017-10-30T12:34:00+

This is because org-2ft calls org-parse-time-string with t for
zone, i.e. parse the time string as though it were UTC.  That
should be apparent from the last column.

Hopefully, we can agree that the former is the desired behavior.
Working on this assumption, org-2ft should be changed to the
original behavior, i.e., to not parse time strings as UTC.

The question then becomes, what breaks if we just naively change
org-2ft?  The new behavior was only added to org-2ft four months
ago, so worst case is reverting every time-related change in the
interim puts us back four months in time-related logic.

But looking through the history, most of the time-related changes
in the interim were to fix regressions caused by the initial
logic change.  If we revert the original "regression", then those
interim changes are also not needed.

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/)]

[Allen Li]

 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
> 97a1a498956da2e1961df5a0506df4cbb98fff52. Some other commits followed
> this one in maint and master.
>
> You may want to check the ML for the initial bug report.

Bisecting on maint shows that this regression happened at
cc5a9bf538a4a7eb1b84d368336c46cead106e01

I tested using this command:

find . -name "*.elc" -delete; emacs -Q --batch --eval "(add-to-list
'load-path default-directory)" --eval "(require 'org)" --eval "(princ
(current-time-string (org-2ft \"<2017-10-31>\")))"

I guess the relevant bug is
http://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00097.html,
but oddly enough, I cannot reproduce that bug at
cc5a9bf538a4a7eb1b84d368336c46cead106e01~1

>From what I can glean from the history,
112c5ba479d52c3c36de5c7aafd14ab6bc075005 is where things started to go
wrong.  UTC timezone was added to tests.  From there, a number of
commits were added to fix regressions.

The problem is that the tests were made to assume UTC timezone and Org
mode was changed to also use UTC timezone to make the tests pass;
however, this means that org.el no longer works for non-UTC time
zones.

That commit's message (112c5ba479d52c3c36de5c7aafd14ab6bc075005) also
seems suspect.  It claims to be removing DST offset by enforcing UTC.
That could only be true for people using GMT.  In GMT during DST,
enforcing UTC would "remove" the DST offset, but that is not true
anywhere else.

Given my chain of reasoning, the commits following
112c5ba479d52c3c36de5c7aafd14ab6bc075005 to fix "regressions" is
really just converting all of Org mode's timestamps to use the
"timezone adjusted" Unix timestamps introduced by
112c5ba479d52c3c36de5c7aafd14ab6bc075005

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/)]

[Allen Li]

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-string
>> suggests that it too is not handling timezones correctly.  In fact,
>> perhaps org-parse-time-string should not take a zone argument, since
>> Org does not support timezones thus the only valid value for zone is
>> nil.  I suspect that org-display-custom-time, another caller that
>> passes t for zone, is also timezone incorrect.
>
> Both changes were introduced to fix some issues with daylight saving
> time, in particular in clock reports. It is not possible to simply
> suggest reverting them without considering the underlying issues.
>
> I agree there are issues to fix. Unfortunately, the solution you suggest
> is not sufficient.

Let me clarify the exact behavior that needs to be fixed.

Assuming today is 2017-10-31, SCHEDULED<"" will match results
that have SCHEDULED=<2017-11-01> depending on your local time zone.

Can you clarify on the issues the UTC timezone fixes?  Because my
understanding at this point is that Org timestamps should be
interpreted as localtime, yet they are being interpreted as UTC time.
I can't see how, e.g.,  if I am in timezone UTC-5, I want all my Org
timestamps <2017-11-01> to be interpreted as <2017-10-31 19:00>.

Assuming that is in fact the behavior we want for some reason, then
, or rather everywhere (float-time) is used in Org mode, should
receive a corresponding time shift.

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/)]

[Allen Li]

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 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>"" compares a UTC time against a local time.
> 2. Either org-2ft should be fixed to be localtime, or  should be
> (float-time) in UTC.
>
> I don't know how Org internals works, but my experience so far has
> been that Emacs and *nix in general is very naive about timezones; a
> naked timestamp is assumed to be localtime if it does not have
> accompanying timezone information.
>
> Thus, it seems to be more correct to change org-2ft to parse times as
> localtime.  However, I don't know if UTC timestamps are assumed by
> other parts of Org internals, in which case fixing  (float-time)
> would be safest.

My initial analysis was wrong because I wasn't thinking clearly.

Just to set a stake in the ground: timestamps are seconds since epoch
and timezone neutral.  Emacs time values are also timezone neutral:
(sec-high sec-low microsec picosec)

(current-time-string (float-time))
"Mon Oct 30 21:21:31 2017" ; right

(current-time-string (org-time-today))
"Mon Oct 30 00:00:00 2017" ; right

(current-time-string (org-2ft "<2017-10-31>"))
"Mon Oct 30 17:00:00 2017" ; wrong

Removing the t for zone fixes it

(defun org-2ft (s)
  "Convert S to a floating point time.
If S is already a number, just return it.  If it is a string, parse
it as a time string and apply `float-time' to it.  If S is nil, just return 0."
  (cond
   ((numberp s) s)
   ((stringp s)
(condition-case nil
(float-time (apply #'encode-time (org-parse-time-string s)))
  (error 0.)))
   (t 0.)))

(current-time-string (org-2ft "<2017-10-31>"))
"Tue Oct 31 00:00:00 2017" ; now right

I will also note that the FIXME comment in org-parse-time-string
suggests that it too is not handling timezones correctly.  In fact,
perhaps org-parse-time-string should not take a zone argument, since
Org does not support timezones thus the only valid value for zone is
nil.  I suspect that org-display-custom-time, another caller that
passes t for zone, is also timezone incorrect.

That is to say, nothing in Org allows passing in a custom timezone,
let alone a UTC timezone; thus, every caller that passes a non-nil
zone to org-parse-time-string is getting an incorrect result.

tl;dr time is hard.

[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/)]

[Allen Li]

(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>"" compares a UTC time against a local time.
2. Either org-2ft should be fixed to be localtime, or  should be
(float-time) in UTC.

I don't know how Org internals works, but my experience so far has
been that Emacs and *nix in general is very naive about timezones; a
naked timestamp is assumed to be localtime if it does not have
accompanying timezone information.

Thus, it seems to be more correct to change org-2ft to parse times as
localtime.  However, I don't know if UTC timestamps are assumed by
other parts of Org internals, in which case fixing  (float-time)
would be safest.

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

[Allen Li]

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.
>
> I cannot reproduce it. Could you provide the error message and a recipe?

1. emacs -Q
2. Evaluate in *scratch* buffer:

(custom-set-variables
 '(org-agenda-files "~/some-nonexistent-file"))

3. Open up any Org file: C-x f ~/tmp.org

4. Error appears in minibuffer: File mode specification error:
(file-error Opening input file No such file or directory
/home/bob/some-nonexistent-file)

5. Type

* asdf

6. Type M-RET, get error org-heading-components: Wrong type argument:
stringp, nil  This is because org.el was loaded partially (I think).

Other symptoms of partial loading: #+STARTUP does not have a face,
some other commands (but not all) result in errors

>
> Regards,
>
> --
> Nicolas Goaziou

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

[Allen Li]

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

[Allen Li]

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 content.

Aborting capture should act transparently like killing a buffer.  It
shouldn't affect the kill ring.  If the user wants to keep the capture
contents, he can trivially run C-x h mark-whole-buffer M-w
kill-ring-save

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

[Allen Li]

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 previous heading regardless
>> of level.
>>
>> Given:
>>
>>* TODO some task
>>** WAITING other task
>>
>> The original code yields:
>>
>>* TODO some task
>>** WAITING other task
>>* WAITING
>>
>> This commit yields:
>>
>>* TODO some task
>>** WAITING other task
>>* TODO
>>
>> * lisp/org.el (org-insert-todo-heading): Use keyword of previous same
>>   level heading
>
> Thank you.
>
> Would you mind adding a test in "test-org.el", to
> `insert-todo-heading-respect-content' test?
>
> Regards,
>
> --
> Nicolas Goaziou

Here's the new patch with tests

---
 lisp/org.el  | 3 +--
 testing/lisp/test-org.el | 7 +++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d6cd77bf9..100fe9a58 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7947,8 +7947,7 @@ unchecked check box."
 (org-insert-heading (or (and (equal arg '(16)) '(16))
  force-heading))
 (save-excursion
-  (org-back-to-heading)
-  (outline-previous-heading)
+  (org-forward-heading-same-level -1)
   (let ((case-fold-search nil)) (looking-at org-todo-line-regexp)))
 (let* ((new-mark-x
  (if (or (equal arg '(4))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 3bc8c7b23..1b9178426 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1415,6 +1415,13 @@
 "* TODO \n"
 (org-test-with-temp-text "* H\n- an item\n- another one"
   (search-forward "an ")
+  (org-insert-todo-heading-respect-content)
+  (buffer-substring-no-properties (line-beginning-position) (point-max)
+  ;; Use the same TODO keyword as current heading.
+  (should
+   (equal
+"* TODO\n"
+(org-test-with-temp-text "* TODO\n** WAITING\n"
   (org-insert-todo-heading-respect-content)
   (buffer-substring-no-properties (line-beginning-position)
(point-max))

-- 
2.15.0.rc0.271.g36b669edcc-goog

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

[Allen Li]

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 is the
> point of using
>
>   ?url=...=...=...
>
> if you cannot access directly to :url, :title and :body from the capture
> template thereafter?

That sounds like a good idea, but the current behavior appears to be
how it was added in 2009 by Carsten.  I'm only documenting the current
behavior, not improving it.

>
> Disclaimer: I'm not using Org Protocol at all so I may be missing
> something.
>
> Regards,
>
> --
> Nicolas Goaziou

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

[Allen Li]

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 commit yields:

   * TODO some task
   ** WAITING other task
   * TODO

* lisp/org.el (org-insert-todo-heading): Use keyword of previous same
  level heading
---
 lisp/org.el | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d6cd77bf9..100fe9a58 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7947,8 +7947,7 @@ unchecked check box."
 (org-insert-heading (or (and (equal arg '(16)) '(16))
  force-heading))
 (save-excursion
-  (org-back-to-heading)
-  (outline-previous-heading)
+  (org-forward-heading-same-level -1)
   (let ((case-fold-search nil)) (looking-at org-todo-line-regexp)))
 (let* ((new-mark-x
  (if (or (equal arg '(4))
-- 
2.15.0.rc0.271.g36b669edcc-goog

[O] org-refile and Archive headings

[Allen Li]

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 :ARCHIVE:...
** New entry...

Would it be desirable to instead append before the Archive heading?

* Some projects
** Some item...
** New entry...
** Archive :ARCHIVE:...

This could be configurable using a magic value for org-reverse-note-order.

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

[Allen Li]

* 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 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 999f3f719..4039e127a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7351,6 +7351,7 @@ gnus |  %:group,
@r{for messages also all email fiel
 eww, w3, w3m |  %:url
 info |  %:file %:node
 calendar |  %:date
+org-protocol |  %:link %:description %:annotation
 @end smallexample

 @noindent
@@ -7592,15 +7593,14 @@
javascript:location.href='org-protocol://store-link?url='+
 @cindex capture protocol
 @cindex protocol, capture

-@cindex capture, %:url placeholder
-@cindex %:url template expansion in capture
-@cindex capture, %:title placeholder
-@cindex %:title template expansion in capture
+@cindex capture, %:link placeholder
+@cindex %:link template expansion in capture
+@cindex capture, %:description placeholder
+@cindex %:description template expansion in capture
+@cindex capture, %:annotation placeholder
+@cindex %:annotation template expansion in capture
 Activating @code{capture} handler pops up a @samp{Capture} buffer and fills
-the capture template associated to the @samp{X} key with them.  The template
-refers to the data through @code{%:url} and @code{%:title} placeholders.
-Moreover, any selected text in the browser is appended to the body of the
-entry.
+the capture template associated to the @samp{X} key with them.

 @example
 emacsclient org-protocol://capture?template=X?url=URL?title=TITLE?body=BODY
@@ -7621,6 +7621,15 @@ The result depends on the capture template
used, which is set in the bookmark
 itself, as in the example above, or in
 @code{org-protocol-default-template-key}.

+The following template placeholders are available:
+
+@example
+%:link  The URL
+%:description   The webpage title
+%:annotationEquivalent to [[%:link][%:description]]
+%i  The selected text
+@end example
+
 @node @code{open-source} protocol
 @subsection @code{open-source} protocol
 @cindex open-source protocol
diff --git a/lisp/org.el b/lisp/org.el
index d6cd77bf9..3bcfae72a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9573,7 +9573,7 @@ sub-tree if optional argument INHERIT is non-nil."
   "Contains the links stored with `org-store-link'.")

 (defvar org-store-link-plist nil
-  "Plist with info about the most recently link created with
`org-store-link'.")
+  "Plist with info about the most recent link created with `org-store-link'.")

 (defun org-store-link-functions ()
   "Return a list of functions that are called to create and store a link.
@@ -9847,7 +9847,8 @@ active region."
  (car org-stored-links)

 (defun org-store-link-props ( plist)
-  "Store link properties, extract names, addresses and dates."
+  "Store link properties.
+The properties are preprocessed by extracting names, addresses and dates."
   (let ((x (plist-get plist :from)))
 (when x
   (let ((adr (mail-extract-address-components x)))
-- 
2.14.2

[O] Org-specific completing-read-function

[Allen Li]

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 unprecedented; both magit and projectile implement
their own completing-read that can be set independent of Emacs's
completing-read-function.

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

[Allen Li]

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 always desire

* TODO some task
** WAITING other task
* TODO

Making C-S-return do this would break backward compatibility, but I
think this behavior is more intuitive.  Thoughts?

Re: [O] capture template placeholders do not work

[Allen Li]

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 (org-protocol-parse-parameters info))
> (parts
>   (cond
>((and (listp info) (symbolp (car info))) info)
>((= (length (car temp-parts)) 1) ;; First parameter is exactly one
> character long
> (org-protocol-assign-parameters temp-parts '(:template :url :title
> :body)))
>(t
> (org-protocol-assign-parameters temp-parts '(:url :title :body)
> (template (or (plist-get parts :template)
>org-protocol-default-template-key))
> (url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get parts
> :url
> (type (and url (if (string-match "^\\([a-z]+\\):" url)
> (match-string 1 url
> (title (or (plist-get parts :title) ""))
> (region (or (plist-get parts :body) ""))
> (orglink (if url
>   (org-make-link-string
>url (if (string-match "[^[:space:]]" title) title url))
> title))
> (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link
> (setq org-stored-links
>   (cons (list url title) org-stored-links))
> (org-store-link-props :type type
>   :link url
>   :description title
>   :annotation orglink
>   :initial region
>   :query parts)
> (raise-frame)
> (funcall 'org-capture nil template)))
>
> From that, we have:
>
> (org-store-link-props :type type
>   :link url
>   :description title
>   :annotation orglink
>   :initial region
>   :query parts)

org-store-link-props basically shoves everything into
org-store-link-plist (with some pre-processing).  The plist keys are
what's used as keywords for %:

The :initlal is special; it gets mapped to %i, and :query is a list
not a string, so you can't use %:query although you can access it from
Emacs Lisp embedded in the template.

I don't have any secret knowledge, I just dug through the source code
and experimented with different inputs.  The code and/or documentation
could be clearer

>
> but that is an internal call.. :link key gets its value from let-bound url
> and :description gets its value from let-bound title.
>
> And further up, url gets assigned value from a plist with key :url:
>
>  (url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get
> parts :url
>
> and title gets assigned value from a plist with key :title.
>
> So that seems to match the documented: "The template refers to the data
> through %:url and %:title placeholders.".
>
> So I am surprised why %:link and %:description worked..
>
> I didn't dig deeper as to where the connection with org-protocol and
> org-capture happens.
> --
>
> Kaushal Modi

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/)]

[Allen Li]

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
> headline and I expect the current tree to get swaped with the preceeding
> in case of M-S-up, instead the line gets moved one up)

It looks like the docs are wrong. M-up/down is
org-move-subtree-up/down and M-S-up/down is org-shiftmetaup/down.

Re: [O] capture template placeholders do not work

[Allen Li]

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 should be %:link and %:description
respectively.

Check out the source code of org-protocol-do-capture.

The valid placeholders are

type
link
description
annotation

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

[Allen Li]

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-return and not M-RET.
>> Is there any particular reason for this?
>
> No idea. Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou

Thanks for the quick fix.

I believe Emacs does intelligent remapping; for example if you type
M-return in GUI Emacs, if there are no bindings for M-return it will
look up the binding for M-RET.  Therefore simply binding M-RET and
removing the M-return binding is "better"/"cleaner".  This is a hugely
trivial nitpick, but I thought I'd point it out

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

[Allen Li]

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

[Allen Li]

* 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 @@ See also `org-tag-persistent-alist' to sidestep
this behavior."
   :group 'org-tags
   :type '(repeat
   (choice
-   (cons   (string:tag "Tag name")
-   (character :tag "Access char"))
+   (cons :tag "Tag with key"
+ (string:tag "Tag name")
+ (character :tag "Access char"))
+   (list :tag "Tag" (string :tag "Tag name"))
(const :tag "Start radio group" (:startgroup))
(const :tag "Start tag group, non distinct" (:startgrouptag))
(const :tag "Group tags delimiter" (:grouptags))
@@ -3607,8 +3609,10 @@ on a per-file basis, insert anywhere in the file:
   :group 'org-tags
   :type '(repeat
   (choice
-   (cons (string:tag "Tag name")
+   (cons :tag "Tag with key"
+ (string:tag "Tag name")
  (character :tag "Access char"))
+   (list :tag "Tag" (string :tag "Tag name"))
(const :tag "Start radio group" (:startgroup))
(const :tag "Start tag group, non distinct" (:startgrouptag))
(const :tag "Group tags delimiter" (:grouptags))
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

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

[Allen Li]

* 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 @@ See also `org-tag-persistent-alist' to sidestep
this behavior."
   :group 'org-tags
   :type '(repeat
   (choice
-   (cons   (string:tag "Tag name")
-   (character :tag "Access char"))
+   (cons :tag "Tag with key"
+ (string:tag "Tag name")
+ (character :tag "Access char"))
+   (list :tag "Tag" (string :tag "Tag name"))
(const :tag "Start radio group" (:startgroup))
(const :tag "Start tag group, non distinct" (:startgrouptag))
(const :tag "Group tags delimiter" (:grouptags))
@@ -3489,8 +3491,10 @@ on a per-file basis, insert anywhere in the file:
   :group 'org-tags
   :type '(repeat
   (choice
-   (cons (string:tag "Tag name")
+   (cons :tag "Tag with key"
+ (string:tag "Tag name")
  (character :tag "Access char"))
+   (list :tag "Tag" (string :tag "Tag name"))
(const :tag "Start radio group" (:startgroup))
(const :tag "Start tag group, non distinct" (:startgrouptag))
(const :tag "Group tags delimiter" (:grouptags))
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

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

[Allen Li]

`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 @
elpa/org-plus-contrib-20170710/)

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

[Allen Li]

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
are created and when they are marked finished.

If one were to create a heading and mark it TODO using C-c C-t, then
the state change would be logged.  In other words, making a heading a
TODO entry is considered a state change from " " to "some todo
keyword".

However, if one were to use C-S-RET, the new TODO heading would not
have a timestamp logged.

I can't think of a situation where the current behavior is desirable,
so I am inclined to think that treating the creation of a TODO heading
as a state change from a normal heading to a TODO heading would be
more convenient.

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

[Allen Li]

Yes, 2906e50177d47 is needed on maint.  However, my understanding is
that on maint we still escape filesystem slashes in the outline path?
If so, org-protect-path will be needed around the file-truename in
2906e50177d4

My workflow recently changed such that I no longer need to set
org-refile-use-outline-path to full-file-path, so my interest in this
bug has dropped accordingly, but it is still a bug on maint that
breaks refiling, so I think the fix should be backported unless there
are plans for a main -> maint merge soon.

On Sun, Jul 2, 2017 at 11:44 PM, Nicolas Goaziou <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
>> the maint branch where it is not possible to refile to the top level
>> of an agenda file when using full-file-path for
>> org-refile-use-outline-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.
>
> Wouldn't 2906e50177d47b4f4a0e75532a0c9dcc9cf72824 be sufficient in your
> case?
>
> If not, what commits are required?
>
> Regards,
>
> --
> Nicolas Goaziou

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

[Allen Li]

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
the maint branch where it is not possible to refile to the top level
of an agenda file when using full-file-path for
org-refile-use-outline-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> wrote:
> 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 <vianchielfa...@gmail.com> writes:
>>
>>> On Mon, May 15, 2017 at 5:54 AM, Sebastian Reuße <s...@wirrsal.net> 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
>>>> `full-file-path'. We now add this since it is convenient and makes the
>>>> behavior more consistent.
>>>> ---
>>>>  lisp/org.el | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/lisp/org.el b/lisp/org.el
>>>> index 97713c523..28277e352 100644
>>>> --- a/lisp/org.el
>>>> +++ b/lisp/org.el
>>>> @@ -11563,6 +11563,8 @@ (defun org-refile-get-targets ( 
>>>> default-buffer)
>>>>  (push (list (file-name-nondirectory f) f nil nil) tgs))
>>>>(when (eq org-refile-use-outline-path 'buffer-name)
>>>>  (push (list (buffer-name (buffer-base-buffer)) f nil nil) 
>>>> tgs))
>>>> +  (when (eq org-refile-use-outline-path 'full-file-path)
>>>> +(push (list (file-truename (buffer-file-name 
>>>> (buffer-base-buffer))) f nil nil) tgs))
>>>>(org-with-wide-buffer
>>>> (goto-char (point-min))
>>>> (setq org-outline-path-cache nil)
>>>> --
>>>> 2.13.0
>>>>
>>>>
>>>
>>> If I'm not mistaken, the full file path needs to be wrapped in
>>> org-protect-slash?
>>
>> Slashes that are part of file paths aren’t escaped anymore, as of
>> 53bcf91a9. The only reason to escape slashes is to indicate they are not
>> part of the outline or file path, but part of the headline instead.
>>
>> In fact it looks like Nicolas removed ‘org-protect-slash’ in 2b44a1a74
>> and inlined it at its only use site.
>>
>> Kind regards,
>>
>> Sebastian
>>
>> --
>> Insane cobra split the wood
>> Trader of the lowland breed
>> Call a jittney, drive away
>> In the slipstream we will stay

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

[Allen Li]

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 <vianchielfa...@gmail.com> writes:
>
>> On Mon, May 15, 2017 at 5:54 AM, Sebastian Reuße <s...@wirrsal.net> 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
>>> `full-file-path'. We now add this since it is convenient and makes the
>>> behavior more consistent.
>>> ---
>>>  lisp/org.el | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/lisp/org.el b/lisp/org.el
>>> index 97713c523..28277e352 100644
>>> --- a/lisp/org.el
>>> +++ b/lisp/org.el
>>> @@ -11563,6 +11563,8 @@ (defun org-refile-get-targets ( 
>>> default-buffer)
>>>  (push (list (file-name-nondirectory f) f nil nil) tgs))
>>>(when (eq org-refile-use-outline-path 'buffer-name)
>>>  (push (list (buffer-name (buffer-base-buffer)) f nil nil) 
>>> tgs))
>>> +  (when (eq org-refile-use-outline-path 'full-file-path)
>>> +(push (list (file-truename (buffer-file-name 
>>> (buffer-base-buffer))) f nil nil) tgs))
>>>(org-with-wide-buffer
>>> (goto-char (point-min))
>>> (setq org-outline-path-cache nil)
>>> --
>>> 2.13.0
>>>
>>>
>>
>> If I'm not mistaken, the full file path needs to be wrapped in
>> org-protect-slash?
>
> Slashes that are part of file paths aren’t escaped anymore, as of
> 53bcf91a9. The only reason to escape slashes is to indicate they are not
> part of the outline or file path, but part of the headline instead.
>
> In fact it looks like Nicolas removed ‘org-protect-slash’ in 2b44a1a74
> and inlined it at its only use site.
>
> Kind regards,
>
> Sebastian
>
> --
> Insane cobra split the wood
> Trader of the lowland breed
> Call a jittney, drive away
> In the slipstream we will stay

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

[Allen Li]

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
> `full-file-path'. We now add this since it is convenient and makes the
> behavior more consistent.
> ---
>  lisp/org.el | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 97713c523..28277e352 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -11563,6 +11563,8 @@ (defun org-refile-get-targets ( 
> default-buffer)
>  (push (list (file-name-nondirectory f) f nil nil) tgs))
>(when (eq org-refile-use-outline-path 'buffer-name)
>  (push (list (buffer-name (buffer-base-buffer)) f nil nil) 
> tgs))
> +  (when (eq org-refile-use-outline-path 'full-file-path)
> +(push (list (file-truename (buffer-file-name 
> (buffer-base-buffer))) f nil nil) tgs))
>(org-with-wide-buffer
> (goto-char (point-min))
> (setq org-outline-path-cache nil)
> --
> 2.13.0
>
>

If I'm not mistaken, the full file path needs to be wrapped in
org-protect-slash?

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

[Allen Li]

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 a/lisp/org-attach.el b/lisp/org-attach.el
index 8093527ae..bfd7106b0 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -459,7 +459,8 @@ The attachment is created as an Emacs buffer."
 (unless (file-exists-p file)
   (error "No such attachment: %s" file))
 (delete-file file)
-(org-attach-commit)))
+(when org-attach-commit
+  (org-attach-commit
 
 (defun org-attach-delete-all ( force)
   "Delete all attachments from the current task.
@@ -475,14 +476,16 @@ A safer way is to open the directory in dired and delete 
from there."
 (y-or-n-p "Are you sure you want to remove all attachments of 
this entry? ")))
   (shell-command (format "rm -fr %s" attach-dir))
   (message "Attachment directory removed")
-  (org-attach-commit)
+  (when org-attach-commit
+(org-attach-commit))
   (org-attach-untag
 
 (defun org-attach-sync ()
   "Synchronize the current tasks with its attachments.
 This can be used after files have been added externally."
   (interactive)
-  (org-attach-commit)
+  (when org-attach-commit
+(org-attach-commit))
   (when (and org-attach-file-list-property (not org-attach-inherited))
 (org-entry-delete (point) org-attach-file-list-property))
   (let ((attach-dir (org-attach-dir)))
-- 
2.13.1



signature.asc
Description: PGP signature

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

[Allen Li]

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 2017-04-22
Package: Org mode version 9.0.8 (9.0.8-elpa @ 
/home/mir/.emacs.d/elpa/org-20170606/)


signature.asc
Description: PGP signature

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

[Allen Li]

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.  I have
> reproduced this on a fresh clone of the Git repo with a minimal
> config.

Nicolas Goaziou writes:

> I can now reproduce it.

> This raises another question, though. What is a reasonable behaviour for
> bulk schedule+log?

Allen Li writes:

> 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 items that are already
>scheduled (and hence rescheduled).
> 3. Don't attempt to add a note and just add timestamps.

Nicolas Goaziou writes:

> It is fixed, with option 3. Global note doesn't sound like a silver
> bullet. Also, 3 was much easier to implement.

I believe that this bug has not been fixed for ‘org-log-redeadline’ as I
have encountered it recently, but I have not done a clean repro of it
yet (although I think such a repro may not be necessary).

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

[Allen Li]

* 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 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index cf9351a9b..78c1a37f4 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4971,7 +4971,11 @@ of what a project is and how to check if it stuck, 
customize the variable
 (setq org-agenda-buffer-name (buffer-name))
 (with-current-buffer org-agenda-buffer-name
   (setq org-agenda-redo-command
-   `(org-agenda-list-stuck-projects ,current-prefix-arg)
+   `(org-agenda-list-stuck-projects ,current-prefix-arg))
+  (let ((inhibit-read-only t))
+(add-text-properties
+ (point-min) (point-max)
+ `(org-redo-cmd ,org-agenda-redo-command))
 
 ;;; Diary integration
 
-- 
2.12.2

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

[Allen Li]

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")
  org-stuck-projects '("project" ("TODO") nil ""))

3. M-x org-agenda RET #

Buffer contents:

List of stuck projects:
  tmp:Stuck:project:

4. r

Buffer contents:

Headlines with TAGS match: project
Press ‘C-u r’ to search again with new search string
  tmp:Stuck:project:
  tmp:Unstuck  :project:
  tmp:TODO thing  :project::

I realize that this is using the stock Org mode that ships with Emacs,
but it's the same behavior as org-20170210, which I believe is the
latest and this repro is easier.

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

[Allen Li]

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
Press ‘C-u r’ to search again with new search string
  Refile: Stuck
:refile::project:
  Refile: Unstuck  
:refile::project:

Emacs  : GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.7)
 of 2017-02-07
Package: Org mode version 9.0.5 (9.0.5-elpa @ ~/.emacs.d/elpa/org-20170210/)

[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/)]

[Allen Li]

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)))
   ((> (length clipboards) 1)
(insert (read-string "Clipboard/kill value: "
 (car clipboards)
 '(clipboards . 1)
 (car clipboards))

It looks like the intention is to put the list of possible clipboard
values into the minibuffer history for read-string, but in practice I
get an error saying the history is empty.

I suspect that the problem is that clipboard is lexically bound, and
since read-string takes a symbol for the history, it cannot get the
lexical value for clipboards from the symbol argument.

Emacs  : GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.7)
 of 2017-02-07
Package: Org mode version 9.0.5 (9.0.5-elpaplus @ 
/home/mir/.emacs.d/elpa/org-plus-contrib-20170210/)

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

[Allen Li]

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 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.9)
 of 2016-09-18
Package: Org mode version 9.0 (9.0-elpa @ /home/mir/.emacs.d/elpa/org-20161102/)

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

[Allen Li]

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 @ ~/.emacs.d/elpa/org-20161102/)

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

[Allen Li]

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.


The file+olp target for `org-capture-templates', when a relative path is
used, the path is resolved relative to `default-dir’, as opposed to
relative to `org-directory’ like file+headline.

Emacs  : GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.9)
 of 2016-09-18
Package: Org mode version 9.0 (9.0-elpa @ /home/mir/.emacs.d/elpa/org-20161102/)

current state:
==
(setq
 org-export-babel-evaluate nil
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-clock-history-length 25
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-clock-into-drawer "CLOCK"
 org-log-done 'time
 org-confirm-shell-link-function 'yes-or-no-p
 org-columns-default-format "%60ITEM %TODO %Effort{:} %CLOCKSUM"
 org-clock-idle-time 10
 org-agenda-sticky t
 org-pretty-entities t
 org-agenda-custom-commands '(("d" "Daily agenda"
   ((agenda "" ((org-agenda-span (quote day
(tags "refile"))
   )
  ("n" "Next actions" tags-todo
   "SCHEDULED=\"\"-BLOCKED=t")
  ("o" "Old tasks" tags "CLOSED<=\"<-1m>\""))
 org-use-sub-superscripts '{}
 org-default-notes-file "~/qualia/agenda/refile.org"
 org-capture-templates '(("n" "Note" entry (file "")
  "* %?\n:LOGBOOK:\n- Captured on %U\n:END:")
 ("t" "Task" entry (file "")
  "* TODO %?\n:LOGBOOK:\n- Captured on %U\n:END:")
 ("j" "Journal" entry
  (file+datetree "agenda/journal.org") "" :clock-in t
  :clock-resume t)
 ("a" "Anison" entry
  (file+olp "agenda/collect.org" "Anison" "Fall 2016")
  "* TODO Download %?\n:LOGBOOK:\n- Captured on 
%U\n:END:")
 ("d" "Diary" entry (file+datetree "log/diary.org") "")
 ("f" "Fitness" entry (file+datetree "log/fitness.org")
  "")
 ("h" "Health" entry (file+datetree "log/health.org") 
""))
 org-agenda-include-diary t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-global-properties '(("Effort_ALL" .
  "0:10 0:30 1:00 2:00 3:00 4:00 5:00 6:00 7:00")
 )
 org-log-redeadline 'note
 org-mode-hook '(org-clock-load
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-refile-targets '((org-agenda-files :maxlevel . 3) (nil :maxlevel . 3))
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-use-speed-commands '(lambda nil
  (and (looking-at org-outline-regexp)
   (looking-back "^**"))
  )
 org-clock-persist 'history
 org-refile-use-outline-path 'file
 org-directory "~/qualia/"
 org-enforce-todo-dependencies t
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-log-refile 'time
 org-agenda-text-search-extra-files '(agenda-archives)
 org-archive-default-command 'org-archive-to-archive-sibling
 org-log-reschedule 'time
 org-refile-allow-creating-parent-nodes 'confirm
 org-todo-keywords '((sequence "TODO(t)" "|" "DONE(d!)" "CANCELED(c@)"))
 org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el")
  ("elisp" . "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-edit-src-content-indentation 0
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-log-into-drawer t
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow 

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/)]

[Allen Li]

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 items that are already
   scheduled (and hence rescheduled).
3. Don't attempt to add a note and just add timestamps.

Then there's the unreasonable option:

4. Prompt for a note for each item.

If I had to pick, I'd go with 2, but any of 1-3 is fine.  In this case,
having bulk scheduling work is more important than whether
org-log-reschedule is being faithfully applied, in my opinion.

Allen


signature.asc
Description: PGP signature

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/)]

[Allen Li]

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...@felesatra.moe> writes:
>
>> 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 @ 
>> //org-mode/lisp/)
>>   Press key for agenda command (unrestricted):
>>   1 entries marked for bulk action
>>   2 entries marked for bulk action
>>   Bulk: [$]arch [A]rch->sib [t]odo [+/-]tag [s]chd [d]eadline [r]efile 
>> [S]catter [f]unction
>>   Scheduled to <2016-03-09 Wed> [2 times]
>>   Skipping removed entry at #> test.org>
>>   Acted on 1 entries, skipped 1 (disappeared before their turn)
>>   Note store
>>
>> Here is the config:
>>
>>   (add-to-list 'load-path (expand-file-name "~//org-mode/lisp"))
>>   (add-to-list 'auto-mode-alist '("\\.\\(org\\  |org_archive\\|txt\\)$" . 
>> org-mode))
>>   (setq org-agenda-files '("/tmp/test.org"))
>>   (require 'org-install)
>>   (require 'org-habit)
>>
>>   (global-set-key "\C-cl" 'org-store-link)
>>   (global-set-key "\C-ca" 'org-agenda)
>>   (global-set-key "\C-cb" 'org-iswitchb)
>>
>>   (setq org-log-reschedule 'note)
>
> I cannot reproduce it with the following "test.org":
>
>  * TODO A
>  * TODO B
>
> Could you also provide the "test.org" you are using? Thank you.
>
>
> Regards,



signature.asc
Description: PGP signature

[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/)]

[Allen Li]

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 @ //org-mode/lisp/)
  Press key for agenda command (unrestricted):
  1 entries marked for bulk action
  2 entries marked for bulk action
  Bulk: [$]arch [A]rch->sib [t]odo [+/-]tag [s]chd [d]eadline [r]efile 
[S]catter [f]unction
  Scheduled to <2016-03-09 Wed> [2 times]
  Skipping removed entry at #
  Acted on 1 entries, skipped 1 (disappeared before their turn)
  Note store

Here is the config:

  (add-to-list 'load-path (expand-file-name "~//org-mode/lisp"))
  (add-to-list 'auto-mode-alist '("\\.\\(org\\  |org_archive\\|txt\\)$" . 
org-mode))
  (setq org-agenda-files '("/tmp/test.org"))
  (require 'org-install)
  (require 'org-habit)

  (global-set-key "\C-cl" 'org-store-link)
  (global-set-key "\C-ca" 'org-agenda)
  (global-set-key "\C-cb" 'org-iswitchb)

  (setq org-log-reschedule 'note)

Emacs  : GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-09 on foutrelis

[O] Asynchronous mobileorg push/pull

[Allen Li]

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 MobileOrg syncing?


signature.asc
Description: PGP signature