[O] [fr] mark ring forward and backward
idk if this is already possible. in the org mark ring, i want to keep a history of places gone, and go backward and forward in it. is this a coherent request that is not already implemented?
Re: [O] [PATCH] `org-clock--oldest-date` performance
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 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 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 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
Nicolas Goaziou 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 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] [RFC] Moving "manual.org" into core
Achim Gratz writes: > Nicolas Goaziou writes: >> Actually, I have another idea. We could implement a function generating >> the manual, right in Org core. It can be useful for both packaging, like >> the above, and for developers, who can update the manual on the fly. > > That should go into mk/org-fixup.el then. I am not aware that any > packagers have actually picked those helper functions up, so the primary > aim should still be that "make doc" keeps things updated. To be clear, I meant that "make doc" would call `org-generate-manuals'. Isn't it enough? > As I said, all of this is several years old and still working. Probably, but that's a bit complicated.
Re: [O] [RFC] Moving "manual.org" into core
Nicolas Goaziou writes: > Actually, I have another idea. We could implement a function generating > the manual, right in Org core. It can be useful for both packaging, like > the above, and for developers, who can update the manual on the fly. That should go into mk/org-fixup.el then. I am not aware that any packagers have actually picked those helper functions up, so the primary aim should still be that "make doc" keeps things updated. > Assuming the function above is called `org-generate-manuals', and > manual.org is located in doc/, what changes would be needed? I assume > they would be minimal. > >> ORG2HTML=-f org-html-export-to-html > > I think HTML should still be generated from the texi file. I assume > there is some compatibility to preserve among GNU manuals. We could and probably should provide an option for doing it both ways. The intent back when was that sometimes one of the export paths did work while the other didn't, so it was quite useful to have both available. >> ORG2INFO=--eval "(org-texinfo-compile \"./$<\")" > > See above. As I said, all of this is several years old and still working. > What kind of modifications do you have in mind? Nothing, unless we find something missing or wrong. But at least we need to check that it works as intended. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [PATCH] `org-clock--oldest-date` performance
Jack Henahan 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] [RFC] Moving "manual.org" into core
Hello,
Achim Gratz writes:
Thank you for your answer. Some comments follow.
> The lack of complaints is unlikely to mean that everybody tried it and
> found nothing to complain about.
I didn't imply anything like that.
> The export to texi is still relatively slow,
I don't think it is much of a concern, since generating the texi file
only happens once in a while.
>> The first obvious step is to move the file into "doc/" directory. Then
>> I assume we could delete "org.texi" and "org.info" there and generate
>> new ones from the Org file. For example, the following command, called
>> from the "manual.org" file,
>>
>> (let ((org-texinfo-logfiles-extensions
>>(cons "texi" org-texinfo-logfiles-extensions)))
>> (org-texinfo-export-to-info))
>>
>> produces an "org.info" file without an "org.texi". It thus prevents
>> direct editing of "org.texi". I assume this could be called by "make
>> info" target.
>
> Maybe not directly in the way you show it here, but yes.
>
> For the record, the build system extension from years ago involves
> creating a directory orgmanual, then you should symlink orgmanual.org to
> the actual file in contrib/, then put the follwing Makefile there:
>
> TEXI2PDF+=--tidy
> BEXP=$(BATCH) \
> --eval '(add-to-list '"'"'load-path "../lisp")' \
> --eval '(setq org-footnote-auto-adjust nil)'
The second "--eval" is not needed.
> EXTEXI= -l ox-texinfo \
> --eval '(add-to-list '"'"'org-export-snippet-translation-alist
> '"'"'("info" . "texinfo"))'
> EXHTML= -l ox-html \
> $(BTEST_POST) \
> --eval '(add-to-list '"'"'org-export-snippet-translation-alist
> '"'"'("info" . "texinfo"))'
Both EXTEXI and EXHTML are not needed either.
> ORG2TEXI=-f org-texinfo-export-to-texinfo
Actually, I have another idea. We could implement a function generating
the manual, right in Org core. It can be useful for both packaging, like
the above, and for developers, who can update the manual on the fly.
Assuming the function above is called `org-generate-manuals', and
manual.org is located in doc/, what changes would be needed? I assume
they would be minimal.
> ORG2HTML=-f org-html-export-to-html
I think HTML should still be generated from the texi file. I assume
there is some compatibility to preserve among GNU manuals.
> ORG2INFO=--eval "(org-texinfo-compile \"./$<\")"
See above.
> I don't have any preference w.r.t. whether an Org release tarball
> should still contain an org.texi or not, but that's a separate
> decision. I suspect that not delivering it would inconvenience at
> least the Debian folks somewhat since they keep insisting to use their
> own build recipes last I looked. Last but not least we'll have to
> check if we need any modifications for the ELPA distributions.
What kind of modifications do you have in mind?
Regards,
--
Nicolas Goaziou
Re: [O] [RFC] Moving "manual.org" into core
Nicolas Goaziou writes: Hello, "manual.org" was updated a month ago, and, so far, nobody complained about it. So, I think it's a good time to discuss about what could be done next. The first obvious step is to move the file into "doc/" directory. Then I assume we could delete "org.texi" and "org.info" there and generate new ones from the Org file. For example, the following command, called from the "manual.org" file, (let ((org-texinfo-logfiles-extensions (cons "texi" org-texinfo-logfiles-extensions))) (org-texinfo-export-to-info)) produces an "org.info" file without an "org.texi". It thus prevents direct editing of "org.texi". I assume this could be called by "make info" target. So basically, the idea would be to not provide anymore an "org.texi" file. Only "manual.org" and "org.info". Emacs developers already apply fixes to ORG-NEWS, which is a plain Org file, so I guess it would not make their life harder if "manual.org" replaces "org.texi". WDYT? +1 -- Thomas S. Dye http://www.tsdye.com
Re: [O] [RFC] Moving "manual.org" into core
Nicolas Goaziou writes:
> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.
The lack of complaints is unlikely to mean that everybody tried it and
found nothing to complain about. I haven't had much time to do anything
with it so far, but I did at least check that I could use the build
system extension that I created while Tom was working on his version
with it. The export to texi is still relatively slow, but since I have
a much faster machine now it works OK for me. I have not yet tried how
long it would take on my old machine.
> The first obvious step is to move the file into "doc/" directory. Then
> I assume we could delete "org.texi" and "org.info" there and generate
> new ones from the Org file. For example, the following command, called
> from the "manual.org" file,
>
> (let ((org-texinfo-logfiles-extensions
>(cons "texi" org-texinfo-logfiles-extensions)))
> (org-texinfo-export-to-info))
>
> produces an "org.info" file without an "org.texi". It thus prevents
> direct editing of "org.texi". I assume this could be called by "make
> info" target.
Maybe not directly in the way you show it here, but yes.
For the record, the build system extension from years ago involves
creating a directory orgmanual, then you should symlink orgmanual.org to
the actual file in contrib/, then put the follwing Makefile there:
--8<---cut here---start->8---
TEXI2PDF+=--tidy
BEXP=$(BATCH) \
--eval '(add-to-list '"'"'load-path "../lisp")' \
--eval '(setq org-footnote-auto-adjust nil)'
EXTEXI= -l ox-texinfo \
--eval '(add-to-list '"'"'org-export-snippet-translation-alist
'"'"'("info" . "texinfo"))'
EXHTML= -l ox-html \
$(BTEST_POST) \
--eval '(add-to-list '"'"'org-export-snippet-translation-alist
'"'"'("info" . "texinfo"))'
ORG2TEXI=-f org-texinfo-export-to-texinfo
ORG2HTML=-f org-html-export-to-html
ORG2INFO=--eval "(org-texinfo-compile \"./$<\")"
.SUFFIXES: # we don't need default suffix rules
ifeq ($(MAKELEVEL), 0)
$(error This make needs to be started as a sub-make from the toplevel
directory.)
endif
.PHONY: all info html pdf
all:$(ORG_MAKE_DOC)
info: org.info
html: orgmanual org.html
pdf:org.pdf
org.texi: orgmanual.org
$(BEXP) $(EXTEXI) $< $(ORG2TEXI)
org.info: org.texi
$(MAKEINFO) --no-split $< -o $@
# LANG=C # to work around a bug in texi2dvi
org.pdf:LC_ALL=C
org.pdf:LANG=C
org.pdf:org.texi
$(TEXI2PDF) $<
orgmanual: org.texi
$(TEXI2HTML) $< -o $@
org.html: orgmanual.org
$(BEXP) $(EXHTML) $< $(ORG2HTML)
clean:
$(RM) org org.t2d *.pdf *.html *.texi *.info *~ \
*.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs \
*.toc *.tp *.tps *.vr *.vrs *.log *.html *.ps
cleanall: clean
$(RMR) org.t2d orgmanual
--8<---cut here---start->8---
Then add the following to local.mk
--8<---cut here---end--->8---
.PHONY: orgmanual
EXTRADIRS=orgmanual
orgmanual:
$(MAKE) -C $@
manclean:
$(MAKE) -C orgmanual clean
mancleanall:
$(MAKE) -C orgmanual cleanall
clean: manclean
cleanall: mancleanall
--8<---cut here---end--->8---
You can now say "make orgmanual" and have it do the right thing. YOu
could even further extend local.mk so that the "doc" target includes the
new manual by adding this line:
--8<---cut here---end--->8---
doc:orgmanual
--8<---cut here---end--->8---
The whole thing can easily be adapted to work in doc/ if it gets decided
that we should switch to manual.org (or better org.org maybe) as our
primary source file.
> So basically, the idea would be to not provide anymore an "org.texi"
> file. Only "manual.org" and "org.info". Emacs developers already apply
> fixes to ORG-NEWS, which is a plain Org file, so I guess it would not
> make their life harder if "manual.org" replaces "org.texi".
Yes, once the org file is our primary source we should stop provding the
texi file in Git at least. I don't have any preference w.r.t. whether
an Org release tarball should still contain an org.texi or not, but
that's a separate decision. I suspect that not delivering it would
inconvenience at least the Debian folks somewhat since they keep
insisting to use their own build recipes last I looked. Last but not
least we'll have to check if we need any modifications for the ELPA
distributions.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] [PATCH] `org-clock--oldest-date` performance
Jack Henahan writes: Apologies again, didn't update the commit hash properly. I swear this is the last one. :| > Jack Henahan 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 writes: >> >>> Hello, >>> >>> Jack Henahan 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 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 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 writes: > >> Hello, >> >> Jack Henahan 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 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
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 writes: > Hello, > > Jack Henahan 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 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] [RFC] Moving "manual.org" into core
Hello, "manual.org" was updated a month ago, and, so far, nobody complained about it. So, I think it's a good time to discuss about what could be done next. The first obvious step is to move the file into "doc/" directory. Then I assume we could delete "org.texi" and "org.info" there and generate new ones from the Org file. For example, the following command, called from the "manual.org" file, (let ((org-texinfo-logfiles-extensions (cons "texi" org-texinfo-logfiles-extensions))) (org-texinfo-export-to-info)) produces an "org.info" file without an "org.texi". It thus prevents direct editing of "org.texi". I assume this could be called by "make info" target. So basically, the idea would be to not provide anymore an "org.texi" file. Only "manual.org" and "org.info". Emacs developers already apply fixes to ORG-NEWS, which is a plain Org file, so I guess it would not make their life harder if "manual.org" replaces "org.texi". WDYT? Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]
Hello, Allen Li writes: > > * Foo > ** Bar > *** a > *** b > ** Archive :ARCHIVE: > *** a > *** b > *** c > > Expected visibility when using C-c C-k on Foo: > > * Foo > ** Bar > *** a > *** b > ** Archive :ARCHIVE:... > > Actual: > > * Foo > ** Bar > *** a > *** b > ** Archive :ARCHIVE: > *** a > *** b > *** c Fixed. Thank you. Regards, -- Nicolas Goaziou
[O] bug#10289: 24.0.92; Sneaky clobbering of user key binding
Hello, Stefan Monnier writes: > I think a good solution should be along these lines: only add the `k' > binding if the `k' key is currently "unbound" (or more generally does > nothing more than signal an error, since `k' is probably bound to > something like `undefined'). Of course, this care should only > be used if org-calendar-agenda-action-key was not set explicitly by > the user. This will be the default behaviour in Org 9.2. Thank you! Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Keeping outline after reverting buffer
Hi Nicolas, > "N" == Nicolas Goaziou writes: N> Hello, Roland Fehrenbacher writes: >> is there any option or other customization to keep the outline of >> an org buffer (uncollapsed parts of the tree) after the buffer >> has been reverted (org-mode 9.0.1, emacs 25.3.2)? In my case only >> the top headings are displayed after reverting. This is quite >> annoying and time-consuming in a setup, where one constantly >> switches between git branches e.g. N> Org provides two functions to save and restore visibility (and a N> macro that does both, but isn't useful in your case): N> `org-outline-overlay-data' and `org-set-outline-overlay-data'. N> You may want to use them within `before-revert-hook' and N> `after-revert-hook'. this was spot on, Thanks a lot. The following link https://stackoverflow.com/questions/862/org-mode-go-back-from-sparse-tree-to-previous-visibility/44158824#44158824 had a ready-to-use implementation for this. Excellent, makes life a lot easier :) Best, Roland --- http://www.q-leap.com / http://qlustar.com --- HPC / Storage / Cloud Linux Cluster OS ---
Re: [O] `org-clock--oldest-date` performance
Hello, Jack Henahan 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, -- Nicolas Goaziou
Re: [O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]
On Fri, Jan 19, 2018 at 1:35 PM, Nicolas Goaziou wrote: > Hello, > > Allen Li writes: > >> C-c C-k unfolds archived headings. I am using it/interpreting it as a >> subtree variant to S-TAB, which shows the CONTENTS headlines only view >> without unfolding archived headings. > > Could you provide an ECM? * Foo ** Bar *** a *** b ** Archive :ARCHIVE: *** a *** b *** c Expected visibility when using C-c C-k on Foo: * Foo ** Bar *** a *** b ** Archive :ARCHIVE:... Actual: * Foo ** Bar *** a *** b ** Archive :ARCHIVE: *** a *** b *** c > > Thank you. > > Regards, > > -- > Nicolas Goaziou
