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

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

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

Allen Li writes: > On Wed, Nov 1, 2017 at 5:09 PM, Tim Cross 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

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 5:09 PM, Tim Cross 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

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

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

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] ``make test'' failure

Hello, Nick Dokos writes: > I get one failure in test-org-publish/resolve-external-link. > Bisecting fingers this commit: > > , > | $ git bisect good > | 007bbddbccfd06ab9c97d51bf833a068cb1b07a2 is the first bad commit > | commit 007bbddbccfd06ab9c97d51bf833a068cb1b07a2 >

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

Hello, Allen Li writes: > I guess the relevant bug is > http://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00097.html, FWIW, this is not the initial bug. > From what I can glean from the history, > 112c5ba479d52c3c36de5c7aafd14ab6bc075005 is where things

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 wrote: > > Allen Li writes: > >> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross 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 6:09 AM, Tim Cross wrote: > > Allen Li writes: > >> 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

Re: [O] macro replacement in code block?

On Wed, Nov 1, 2017 at 1:32 PM David Rogoff wrote: > Thanks so much. It sort of works but with a bit of work-around: > Great! > 2) for export, I had to move the > > ,#+MACRO: SEC_FOO > > lines out of the code block. If I didn’t and tried to eval that block, I > got the

[O] Issue with workaround (referring to sonarqube badges in github README.org)

I use org-mode syntax for my github README file, because I'm more familiar with it, and because I use org-mode. I ran into a problem when trying to use SonarQube status badges from SonarCloud: the badge images didn't show up, instead the URL to the REST API call generating the badge was shown[1].

Re: [O] macro replacement in code block?

Thanks so much. It sort of works but with a bit of work-around: 1) tangle works fine 2) for export, I had to move the > ,#+MACRO: SEC_FOO lines out of the code block. If I didn’t and tried to eval that block, I got the error No org-babel-execute function for org! But I think this will

[O] Multi-line noweb expansion in elisp insert form (Was Re: macro replacement in code block?)

Hello all, While trying to come up with a solution for this problem[1], I ended up with a new problem :) On Wed, Nov 1, 2017 at 11:51 AM Kaushal Modi wrote: > I still don't have a fully working solution (see below). Hopefully someone > can help figure out the reason for

Re: [O] macro replacement in code block?

On Wed, Nov 1, 2017 at 11:51 AM Kaushal Modi wrote: > I still don't have a fully working solution (see below). Hopefully someone > can help figure out the reason for "Invalid read syntax: #" error. > OK, I found a workaround. Below solution works: 1. Eval the

Re: [O] macro replacement in code block?

On Tue, Oct 31, 2017 at 11:21 PM David Rogoff wrote: > Thanks - I’ll have to look into noweb. I’m not familiar with it. > This turned out to be much complicated than I expected.. I still don't have a fully working solution (see below). Hopefully someone can help figure

Re: [O] Footnotes-per-element?

THanks for this; it may be a workable solution. The trick is, I didn't generate the footnotes myself -- I have concatenated a bunch of html -> orgmode pandoc outputs. Still an elisp find-and-replace might do what I need. I was just hoping for a quick switch to flip for localized footnotes.

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 writes: > 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

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

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 3. If the timestamp does not include a time component, default to 0:00:0 for the local TZ 4. org-2ft should not enforce the UTC TZ. I agree this is

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