Re: [O] wish: facility to wash org link descriptions

[Jack Henahan]

https://orgmode.org/manual/Adding-hyperlink-types.html#Adding-hyperlink-types

Adding a custom hyperlink type (or overriding the existing one for mail 
messages) seems like your best bet.

Jack

> On Mar 2, 2018, at 07:16, Gregor Zattler  wrote:
> 
> Hi org-mode developers,
> 
> it would be nice if there was a facility to wash (= shorten) org
> link descriptions.  From the users perspective this could be a
> list of regular expressions with corresponding short forms.
> 
> Use case:
> 
> I want to automatically shorten org link descriptions,
> especially if linking to emails.  Some of this emails are from a
> request tracker and have extraordinary long From: and Subject:
> suffixes which add up to 49 characters in the link description.
> I would like to radically shorten this boilerplate.
> 
> Even with "normal" To: and Subject:, the default formatting of
> such links prefixes the correspondents name with "from " or "to ".
> While it's fine with me to distinguish emails from me from
> emails to emails to me, I would not need the "from ").
> 
> 
> Ciao; Gregor
> -- 
> -... --- .-. . -.. ..--.. ...-.-
> 
> 

Re: [O] when/how are org-mode settings loaded

[Jack Henahan]

Could you post your config? I expect the issue is that you don’t (require 'org) 
or set up the auto-mode-alist in your init file. This would also be the case 
if, for instance, you defer loading the package with use-package, as well. 
Invoking the agenda will load org, so the next org file you open will do what 
you expect.

Do org files open in Fundamental mode when you don’t invoke the agenda first?

> On Feb 8, 2018, at 03:42, Julius Dittmar  wrote:
> 
> Hi,
> 
> I'm an emacs-newbe, so please bear with me. I must be doing something
> wrong and I have no idea where to look.
> 
> If my emacs-starting sequence is
> 
> 1. call emacs with no arguments (and a config file adding various
> org-mode settings)
> 2. launch org-mode agenda once
> 3. open a file with .org suffix
> 
> then highlighting and keybindings for that file are as I expect them and
> in sync with the org-mode settings in the config file.
> 
> If I omit step 2, then highlighting in the file does not work.
> 
> Even if I then call agenda and later, either by choosing an agenda item
> or directly, go back to that file buffer, highlighting still does not
> work there.
> 
> Any pointers as to what might cause such behaviour? Or perhaps a faster
> work-around than generating the whole (over-full) agenda?
> 
> Thanks in advance,
> 
> Julius
> 
> PS: GNU Emacs 24.3.1, org-mode release_9.1.6-159-g8554aa9
> 

Re: [O] Specifying the tangle filename based on the source filename?

[Jack Henahan]

I do something similar, and I use a snippet like this

#+begin_src emacs-lisp
  (defun the-in-the-org-lib-p ()
(and (f-this-file)
 (f-child-of? (f-this-file) the-org-lib-directory)))

  (defun the-org-lib-hook ()
(if (the-in-the-org-lib-p)
(progn
  (setq-local org-babel-default-header-args:emacs-lisp
  `((:tangle . ,(f-expand (f-swap-ext (f-filename 
(f-this-file)) "el") the-lib-directory))
(:noweb . "yes"))

(add-hook 'org-mode-hook 'the-org-lib-hook)
#+end_src

`the-org-lib-directory' points to where all my Org config sources are,
while `the-lib-directory' points to where the tangled files go. My Org
files then have a structure like

org/whatever.org

* Configuring Whatever Features
** Requirements :noexport:
#+begin_src emacs-lisp
  ;; -*- lexical-binding: t; -*-
  ;;; whatever.el --- Whatever functionality
 
  (require 'whatever)
#+end_src
** Some Subfeature
Explain how we use the feature
#+begin_src emacs-lisp
  (my-configuration 'stuff)
#+end_src

** Provides :noexport:
#+begin_src emacs-lisp
  (provide 'whatever)

  ;;; whatever.el ends here
#+end_src

I have some additional configuration to tangle my lib files on save, and
to regenerate the top-level documentation so that (in theory) the README
is always up to date with the configuration. The :noexport: tags remove
the noise of require and provides when I export.

Diego Zamboni  writes:

> Hi,
>
> I’ve been converting many of my configuration files to org-mode to better 
> document them (examples:
> https://github.com/zzamboni/dot_emacs/blob/master/init.org, 
> https://github.com/zzamboni/dot_elvish/blob/master/rc.org). Usually I
> have a line like the following at the top of each org file:
>
> #+PROPERTY: header-args:emacs-lisp :tangle init.el
>
> So that all the code blocks in the file are, by default, tangled to the 
> corresponding config file. I was wondering if it might be
> possible to avoid hardcoding the output file (“init.el” in this example) and 
> instead derive it from the source filename (“init.org” in
> this case). I’ve looked a bit through the manual and although I found the 
> {{{input-file}}} macro, I couldn’t get it to work.
>
> Thanks for any help,
> —Diego

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

I wasn't altogether certain that it could never be nil, and my eyes seem
to have skipped over the expression you called out so I missed that case
in my testing. I have reworked the patch as you suggest. Now the
behavior should be entirely unchanged except in the `untilnow' case
where we use the new date, no extra nils.

Revised patch attached.

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> Jack Henahan <jhena...@me.com> writes:
>
>> Functionally, this means that today `org-clock-special-range` produces a
>> range from the current time until the current time if `start` ends up
>> nil for whatever reason
>
> That's not true. Currently, `org-clock-special-range' never returns
> a nil start time. This is where I don't understand your patch:
>
>> -(`untilnow org-clock--oldest-date)
>> +(`untilnow nil)
>>  (_ (encode-time 0 m h d month y
>> (end (pcase key
>>(`interactive (org-read-date nil t nil "Range end? "))
>> @@ -2283,8 +2251,12 @@ have priority."
>>(`interactive "(Range interactively set)")
>>(`untilnow "now"
>>(if (not as-strings) (list start end text)
> ^
>   this can now be nil
>> -(let ((f (cdr org-time-stamp-formats)))
>> -  (list (format-time-string f start)
>> +(let ((f (cdr org-time-stamp-formats))
>> +  (safe-start
>> +   (if (not start)
>> +   (encode-time 0 0 0 0 0 -5)
>> + start)))
>> +  (list (format-time-string f safe-start)
>>  (format-time-string f end)
>>  text))
>
> Why not replacing `org-clock--oldest-date' with (encode-time
> 0 0 0 0 0 -5) in the let binding above?
>
> Regards,
>From a0792b3900812b6a2385794f30ba7c057bc9fcf7 Mon Sep 17 00:00:00 2001
From: Jack Henahan <jhena...@me.com>
Date: Sun, 21 Jan 2018 10:40:22 -0500
Subject: [PATCH] org-clock.el: Improve `untilnow' range behavior and 
 performance

* org-clock.el:
(org-clock-special-range): Set `untilnow' to use the year -5,
rather than the earliest representable date.
(org-clock--oldest-date): Remove.

The `untilnow' range relied on the constant `org-clock--oldest-date`
to find the earliest representable date, which caused delays when
loading `org-clock' on systems where `most-negative-fixnum' is large.
This change removes that constant in favor of a simpler hack to
produce a range between the current time and before the dawn of human
civilization. If this breaks your workflow, please report to the Time
Police.
---
 lisp/org-clock.el | 35 ++-
 1 file changed, 2 insertions(+), 33 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 496c4310a..d580ffa43 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -468,38 +468,6 @@ to add an effort property.")
 (defvar org-clock-stored-resume-clock nil
   "Clock to resume, saved by `org-clock-load'")
 
-(defconst org-clock--oldest-date
-  (let* ((dichotomy
-	  (lambda (min max pred)
-	(if (funcall pred min) min
-	  (cl-incf min)
-	  (while (> (- max min) 1)
-		(let ((mean (+ (ash min -1) (ash max -1) (logand min max 1
-		  (if (funcall pred mean) (setq max mean) (setq min mean)
-	max))
-	 (high
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31.  Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
-  (string-match-p
-   "10\\.6\\.[[:digit:]]"
-   (shell-command-to-string
-"sw_vers -productVersion"))
-  (<= m -1034058203135))
-   (ignore-errors (decode-time (list m 0)))
-	 (low
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m) (ignore-errors (decode-time (list high m)))
-(list high low))
-  "Internal time for oldest date representable on the system.")
-
 ;;; The clock for measuring work time.
 
 (defvar org-mode-line-string "")
@@ -2260,7 +2228,8 @@ have priority."
 ;; Format start and end times according to AS-STRINGS.
 (let* ((start (pcase key
 		(`interactive (org-read-date nil t nil "Range start? "))
-		(`untilnow org-clock--oldest-date)
+;; In theory, all clocks started after the dawn of humanity
+		(`untilnow (encode-time 0 0 0 0 0 -5))
 		(_ (encode-time 0 m h d month y
 	   (end (pcase key
 		  (`interactive (org-read-date nil t nil "Range end? "))
-- 
2.15.1

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

I've sent off for the FSF form so I can get that process started, and
I've amended my patch according to the guidelines (attached).

Jack Henahan <jhena...@me.com> writes:

> I tested that `org-clock-display` and the clocktable work as expected
> when `org-clock-display-default-range` is set to `untilnow`.
> `org-clock-sum-custom` also appears to function as intended. If I'm
> reading things correctly, the `untilnow` case is the only one that ought
> to be affected, since it's the only one that used
> `org-clock--oldest-date`. The behavior of `org-clock-special-range`
> ought to be unchanged in all cases except where this symbol is
> explicitly used, or the start time is nil for some other reason.
>
> Functionally, this means that today `org-clock-special-range` produces a
> range from the current time until the current time if `start` ends up
> nil for whatever reason, but with this patch it will instead produce a
> range from the year -5 until now. The -5 hack is entirely for
> the benefit of `format-time-string`, since otherwise it just gives the
> current time if its second argument is nil.
>
>> Jack Henahan <jhena...@me.com> writes:
>>
>>> Apologies again, didn't update the commit hash properly. I swear this is
>>> the last one. :|
>>
>> Thank you. However, I'm surprised that `org-clock-special-range' callers
>> handle a nil start date. Have you tested it?
>>
>> If that's true, we don't need the -5 hack at all. Returning an empty
>> string might be enough.
>From a4add4ef44c4f445b4c029a0f0a7ef6f3d5d606b Mon Sep 17 00:00:00 2001
From: Jack Henahan <jhena...@me.com>
Date: Sat, 20 Jan 2018 12:07:11 -0500
Subject: [PATCH] org-clock.el: Improve `untilnow' range behavior and
 performance

* org-clock.el:
(org-clock-special-range): Set `untilnow' to use the year -5,
rather than the earliest representable date.
(org-clock--oldest-date): Remove.

The `untilnow' range relied on the constant `org-clock--oldest-date`
to find the earliest representable date, which caused delays when
loading `org-clock' on systems where `most-negative-fixnum' is large.
This change removes that constant in favor of a simpler hack to
produce a range between the current time and before the dawn of human
civilization. If this breaks your workflow, please report to the Time
Police.
---
 lisp/org-clock.el | 42 +++---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 496c4310a..519b1563b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -468,38 +468,6 @@ to add an effort property.")
 (defvar org-clock-stored-resume-clock nil
   "Clock to resume, saved by `org-clock-load'")
 
-(defconst org-clock--oldest-date
-  (let* ((dichotomy
-	  (lambda (min max pred)
-	(if (funcall pred min) min
-	  (cl-incf min)
-	  (while (> (- max min) 1)
-		(let ((mean (+ (ash min -1) (ash max -1) (logand min max 1
-		  (if (funcall pred mean) (setq max mean) (setq min mean)
-	max))
-	 (high
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31.  Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
-  (string-match-p
-   "10\\.6\\.[[:digit:]]"
-   (shell-command-to-string
-"sw_vers -productVersion"))
-  (<= m -1034058203135))
-   (ignore-errors (decode-time (list m 0)))
-	 (low
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m) (ignore-errors (decode-time (list high m)))
-(list high low))
-  "Internal time for oldest date representable on the system.")
-
 ;;; The clock for measuring work time.
 
 (defvar org-mode-line-string "")
@@ -2260,7 +2228,7 @@ have priority."
 ;; Format start and end times according to AS-STRINGS.
 (let* ((start (pcase key
 		(`interactive (org-read-date nil t nil "Range start? "))
-		(`untilnow org-clock--oldest-date)
+		(`untilnow nil)
 		(_ (encode-time 0 m h d month y
 	   (end (pcase key
 		  (`interactive (org-read-date nil t nil "Range end? "))
@@ -2283,8 +2251,12 @@ have priority."
 	  (`interactive "(Range interactively set)")
 	  (`untilnow "now"
   (if (not as-strings) (list start end text)
-	(let ((f (cdr org-time-stamp-formats)))
-	  (list (format-time-string f start)
+	(let ((f (cdr org-time-stamp-formats))
+  (safe-start
+	   (if (not start)
+		   (encode-time 0 0 0 0 0 -5)
+		 start)))
+	  (list (format-time-string f safe-start)
 		(format-time-string f end)
 		text))
 
-- 
2.15.1

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

I tested that `org-clock-display` and the clocktable work as expected
when `org-clock-display-default-range` is set to `untilnow`.
`org-clock-sum-custom` also appears to function as intended. If I'm
reading things correctly, the `untilnow` case is the only one that ought
to be affected, since it's the only one that used
`org-clock--oldest-date`. The behavior of `org-clock-special-range`
ought to be unchanged in all cases except where this symbol is
explicitly used, or the start time is nil for some other reason.

Functionally, this means that today `org-clock-special-range` produces a
range from the current time until the current time if `start` ends up
nil for whatever reason, but with this patch it will instead produce a
range from the year -5 until now. The -5 hack is entirely for
the benefit of `format-time-string`, since otherwise it just gives the
current time if its second argument is nil.

> Jack Henahan <jhena...@me.com> writes:
>
>> Apologies again, didn't update the commit hash properly. I swear this is
>> the last one. :|
>
> Thank you. However, I'm surprised that `org-clock-special-range' callers
> handle a nil start date. Have you tested it?
>
> If that's true, we don't need the -5 hack at all. Returning an empty
> string might be enough.

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

Jack Henahan <jhena...@me.com> writes:

Apologies again, didn't update the commit hash properly. I swear this is
the last one. :|

> Jack Henahan <jhena...@me.com> writes:
>
> Modified patch attached to use my list mail rather than my work one.
>
>> To that end, I've attached a patch for review which removes
>> `org-clock--oldest-date`, replacing its only use with `nil`, and
>> altering the logic where it's actually used to account for this case and
>> give a sensible-ish value of the year -5 for the start time in
>> `org-special-range`. Before the dawn of humanity seemed like a
>> reasonable limit, but I'm taking suggestions. :D
>>
>> I'm not certain if this hits the "modify 15 lines" threshold since it's
>> mainly deletion, but I'll start getting the paperwork in order and write
>> a Changelog entry.
>>
>> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>>
>>> Hello,
>>>
>>> Jack Henahan <jhena...@me.com> writes:
>>>
>>>> I've run into a performance issue in `org-clock` which I've narrowed
>>>> down to being caused by the calculation in the defconst for
>>>> `org-clock--oldest-date`. In particular, invoking `org-clock-in` or
>>>> eagerly loading `org-clock` on init incurs a 21(!) second delay while
>>>> calculating the constant. If I inline the value (`(-1034058236842
>>>> -45726)`, in my case), the delay vanishes.
>>>>
>>>> So, context out of the way (just in case someone else already knows an
>>>> easier fix), I'd like to spend some spare cycles finding a better way to
>>>> go about the functionality this is meant to provide. If I've read the
>>>> source correctly, it's meant to provide a view of all the clocks by
>>>> showing all clocks between some time way in the past until now.
>>>
>>> A correct fix would be to remove `org-clock--oldest-date', which is used
>>> only in one place, and replace it with nil. Then all
>>> `org-clock-special-range' callers need to be updated to handle this nil
>>> start value.
>>>
>>> Regards,
>From 29969da1e47032f0b3691ba1dd14bd836488990d Mon Sep 17 00:00:00 2001
From: Jack Henahan <jhena...@me.com>
Date: Sat, 20 Jan 2018 12:07:11 -0500
Subject: [PATCH] Set `untilnow` to use the year -5, rather than the
 earliest representable date.

---
 lisp/org-clock.el | 42 +++---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 496c4310a..519b1563b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -468,38 +468,6 @@ to add an effort property.")
 (defvar org-clock-stored-resume-clock nil
   "Clock to resume, saved by `org-clock-load'")
 
-(defconst org-clock--oldest-date
-  (let* ((dichotomy
-	  (lambda (min max pred)
-	(if (funcall pred min) min
-	  (cl-incf min)
-	  (while (> (- max min) 1)
-		(let ((mean (+ (ash min -1) (ash max -1) (logand min max 1
-		  (if (funcall pred mean) (setq max mean) (setq min mean)
-	max))
-	 (high
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31.  Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
-  (string-match-p
-   "10\\.6\\.[[:digit:]]"
-   (shell-command-to-string
-"sw_vers -productVersion"))
-  (<= m -1034058203135))
-   (ignore-errors (decode-time (list m 0)))
-	 (low
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m) (ignore-errors (decode-time (list high m)))
-(list high low))
-  "Internal time for oldest date representable on the system.")
-
 ;;; The clock for measuring work time.
 
 (defvar org-mode-line-string "")
@@ -2260,7 +2228,7 @@ have priority."
 ;; Format start and end times according to AS-STRINGS.
 (let* ((start (pcase key
 		(`interactive (org-read-date nil t nil "Range start? "))
-		(`untilnow org-clock--oldest-date)
+		(`untilnow nil)
 		(_ (encode-time 0 m h d month y
 	   (end (pcase key
 		  (`interactive (org-read-date nil t nil "Range end? "))
@@ -2283,8 +2251,12 @@ have priority."
 	  (`interactive "(Range interactively set)")
 	  (`untilnow "now"
   (if (not as-strings) (list start end text)
-	(let ((f (cdr org-time-stamp-formats)))
-	  (list (format-time-string f start)
+	(let ((f (cdr org-time-stamp-formats))
+  (safe-start
+	   (if (not start)
+		   (encode-time 0 0 0 0 0 -5)
+		 start)))
+	  (list (format-time-string f safe-start)
 		(format-time-string f end)
 		text))
 
-- 
2.15.1

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

Jack Henahan <jhena...@me.com> writes:

Modified patch attached to use my list mail rather than my work one.

> To that end, I've attached a patch for review which removes
> `org-clock--oldest-date`, replacing its only use with `nil`, and
> altering the logic where it's actually used to account for this case and
> give a sensible-ish value of the year -5 for the start time in
> `org-special-range`. Before the dawn of humanity seemed like a
> reasonable limit, but I'm taking suggestions. :D
>
> I'm not certain if this hits the "modify 15 lines" threshold since it's
> mainly deletion, but I'll start getting the paperwork in order and write
> a Changelog entry.
>
> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> Jack Henahan <jhena...@me.com> writes:
>>
>>> I've run into a performance issue in `org-clock` which I've narrowed
>>> down to being caused by the calculation in the defconst for
>>> `org-clock--oldest-date`. In particular, invoking `org-clock-in` or
>>> eagerly loading `org-clock` on init incurs a 21(!) second delay while
>>> calculating the constant. If I inline the value (`(-1034058236842
>>> -45726)`, in my case), the delay vanishes.
>>>
>>> So, context out of the way (just in case someone else already knows an
>>> easier fix), I'd like to spend some spare cycles finding a better way to
>>> go about the functionality this is meant to provide. If I've read the
>>> source correctly, it's meant to provide a view of all the clocks by
>>> showing all clocks between some time way in the past until now.
>>
>> A correct fix would be to remove `org-clock--oldest-date', which is used
>> only in one place, and replace it with nil. Then all
>> `org-clock-special-range' callers need to be updated to handle this nil
>> start value.
>>
>> Regards,
>From ba4f38b8337c83330f303e10e3fbf1a251a58fea Mon Sep 17 00:00:00 2001
From: Jack Henahan <jhena...@me.com>
Date: Sat, 20 Jan 2018 11:35:33 -0500
Subject: [PATCH] Set `untilnow` to use the year -5, rather than the
 earliest representable date.

---
 lisp/org-clock.el | 42 +++---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 496c4310a..519b1563b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -468,38 +468,6 @@ to add an effort property.")
 (defvar org-clock-stored-resume-clock nil
   "Clock to resume, saved by `org-clock-load'")
 
-(defconst org-clock--oldest-date
-  (let* ((dichotomy
-	  (lambda (min max pred)
-	(if (funcall pred min) min
-	  (cl-incf min)
-	  (while (> (- max min) 1)
-		(let ((mean (+ (ash min -1) (ash max -1) (logand min max 1
-		  (if (funcall pred mean) (setq max mean) (setq min mean)
-	max))
-	 (high
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31.  Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
-  (string-match-p
-   "10\\.6\\.[[:digit:]]"
-   (shell-command-to-string
-"sw_vers -productVersion"))
-  (<= m -1034058203135))
-   (ignore-errors (decode-time (list m 0)))
-	 (low
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m) (ignore-errors (decode-time (list high m)))
-(list high low))
-  "Internal time for oldest date representable on the system.")
-
 ;;; The clock for measuring work time.
 
 (defvar org-mode-line-string "")
@@ -2260,7 +2228,7 @@ have priority."
 ;; Format start and end times according to AS-STRINGS.
 (let* ((start (pcase key
 		(`interactive (org-read-date nil t nil "Range start? "))
-		(`untilnow org-clock--oldest-date)
+		(`untilnow nil)
 		(_ (encode-time 0 m h d month y
 	   (end (pcase key
 		  (`interactive (org-read-date nil t nil "Range end? "))
@@ -2283,8 +2251,12 @@ have priority."
 	  (`interactive "(Range interactively set)")
 	  (`untilnow "now"
   (if (not as-strings) (list start end text)
-	(let ((f (cdr org-time-stamp-formats)))
-	  (list (format-time-string f start)
+	(let ((f (cdr org-time-stamp-formats))
+  (safe-start
+	   (if (not start)
+		   (encode-time 0 0 0 0 0 -5)
+		 start)))
+	  (list (format-time-string f safe-start)
 		(format-time-string f end)
 		text))
 
-- 
2.15.1

Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

To that end, I've attached a patch for review which removes
`org-clock--oldest-date`, replacing its only use with `nil`, and
altering the logic where it's actually used to account for this case and
give a sensible-ish value of the year -5 for the start time in
`org-special-range`. Before the dawn of humanity seemed like a
reasonable limit, but I'm taking suggestions. :D

I'm not certain if this hits the "modify 15 lines" threshold since it's
mainly deletion, but I'll start getting the paperwork in order and write
a Changelog entry.

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> Jack Henahan <jhena...@me.com> writes:
>
>> I've run into a performance issue in `org-clock` which I've narrowed
>> down to being caused by the calculation in the defconst for
>> `org-clock--oldest-date`. In particular, invoking `org-clock-in` or
>> eagerly loading `org-clock` on init incurs a 21(!) second delay while
>> calculating the constant. If I inline the value (`(-1034058236842
>> -45726)`, in my case), the delay vanishes.
>>
>> So, context out of the way (just in case someone else already knows an
>> easier fix), I'd like to spend some spare cycles finding a better way to
>> go about the functionality this is meant to provide. If I've read the
>> source correctly, it's meant to provide a view of all the clocks by
>> showing all clocks between some time way in the past until now.
>
> A correct fix would be to remove `org-clock--oldest-date', which is used
> only in one place, and replace it with nil. Then all
> `org-clock-special-range' callers need to be updated to handle this nil
> start value.
>
> Regards,
>From ba4f38b8337c83330f303e10e3fbf1a251a58fea Mon Sep 17 00:00:00 2001
From: Jack Henahan <jack.hena...@uvmhealth.org>
Date: Sat, 20 Jan 2018 11:35:33 -0500
Subject: [PATCH] Set `untilnow` to use the year -5, rather than the
 earliest representable date.

---
 lisp/org-clock.el | 42 +++---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 496c4310a..519b1563b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -468,38 +468,6 @@ to add an effort property.")
 (defvar org-clock-stored-resume-clock nil
   "Clock to resume, saved by `org-clock-load'")
 
-(defconst org-clock--oldest-date
-  (let* ((dichotomy
-	  (lambda (min max pred)
-	(if (funcall pred min) min
-	  (cl-incf min)
-	  (while (> (- max min) 1)
-		(let ((mean (+ (ash min -1) (ash max -1) (logand min max 1
-		  (if (funcall pred mean) (setq max mean) (setq min mean)
-	max))
-	 (high
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31.  Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
-  (string-match-p
-   "10\\.6\\.[[:digit:]]"
-   (shell-command-to-string
-"sw_vers -productVersion"))
-  (<= m -1034058203135))
-   (ignore-errors (decode-time (list m 0)))
-	 (low
-	  (funcall dichotomy
-		   most-negative-fixnum
-		   0
-		   (lambda (m) (ignore-errors (decode-time (list high m)))
-(list high low))
-  "Internal time for oldest date representable on the system.")
-
 ;;; The clock for measuring work time.
 
 (defvar org-mode-line-string "")
@@ -2260,7 +2228,7 @@ have priority."
 ;; Format start and end times according to AS-STRINGS.
 (let* ((start (pcase key
 		(`interactive (org-read-date nil t nil "Range start? "))
-		(`untilnow org-clock--oldest-date)
+		(`untilnow nil)
 		(_ (encode-time 0 m h d month y
 	   (end (pcase key
 		  (`interactive (org-read-date nil t nil "Range end? "))
@@ -2283,8 +2251,12 @@ have priority."
 	  (`interactive "(Range interactively set)")
 	  (`untilnow "now"
   (if (not as-strings) (list start end text)
-	(let ((f (cdr org-time-stamp-formats)))
-	  (list (format-time-string f start)
+	(let ((f (cdr org-time-stamp-formats))
+  (safe-start
+	   (if (not start)
+		   (encode-time 0 0 0 0 0 -5)
+		 start)))
+	  (list (format-time-string f safe-start)
 		(format-time-string f end)
 		text))
 
-- 
2.15.1

[O] `org-clock--oldest-date` performance

[Jack Henahan]

Hiya,

I've run into a performance issue in `org-clock` which I've narrowed
down to being caused by the calculation in the defconst for
`org-clock--oldest-date`. In particular, invoking `org-clock-in` or
eagerly loading `org-clock` on init incurs a 21(!) second delay while
calculating the constant. If I inline the value (`(-1034058236842
-45726)`, in my case), the delay vanishes.

So, context out of the way (just in case someone else already knows an
easier fix), I'd like to spend some spare cycles finding a better way to
go about the functionality this is meant to provide. If I've read the
source correctly, it's meant to provide a view of all the clocks by
showing all clocks between some time way in the past until now.

I've read GNU Emacs bug #27706 [1] and attempted to reproduce to ensure
that it's not just the libc issue again, but none of the apparently
problematic examples cause any sort of hang.

This leads me to believe that it's the `dichotomy` algorithm getting a
bit out of control when `most-negative-fixnum` is -2^61.

Right now I'm just `el-patch`ing the defconst and
`org-clock-special-range`, but a more permanent solution would be
desirable.

I'll be looking at it this weekend to see if I can figure something out,
but I thought it likely that someone who understands `org-clock` better
than I might be able to chime in, or at least see if I'm the only one
hitting this issue.

Thanks,
==
Jack Henahan
Org mode version 9.1.6 (release_9.1.6-369-g3604f2) on macOS 10.13.2