From: Marcin Borkowski <mbork@mbork.pl>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Org-Mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: How about lifting the limit of 35 tasks in org-clock-history?
Date: Tue, 02 Oct 2018 08:12:56 +0200 [thread overview]
Message-ID: <875zykzxjr.fsf@mbork.pl> (raw)
In-Reply-To: <87zhwuu2u7.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]
On 2018-09-06, at 16:18, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I decided to put a warning about this in the docstring in my patch. My
>> assumption was that this is enough. If a user wants to change the
>> default, he will most probably see the docstring and will have to
>> actively ignore the warning.
>
> I don't think this is enough. As you put it, it instills doubt without
> explaining anything. Why 35? Why "may not work"? What "may not work"?
Agreed. I attach a patch with a more verbose docstring.
It is perhaps still not ideal - in particular, the warning is not
visible in the Customize interface - but I do not think this is a big
deal. My line of thinking is that:
- if a user wants to change this setting, they will either look up the
docstring and understand the limitation (btw, even the built-in way
works for org-clock-history-length as high as 76 or so, provided you
have a really high frame), or
- use Customize, which is potentially a trouble - but in that case,
I would assume that the user fiddles with org-clock-history-length
because they clock in many tasks, and then they will see that the list
in the *Clock Task Select* buffer is too long anyway, and dial the
setting down.
An alternative could be to change the hard-coded 35 in the code into yet
another variable, say, org-clock-history-max-length, and set it to 35.
Still, if a user wants to increase org-clock-history-length beyond 35
(or whatever this could be changed to), it is IMHO the /current/
behavior which is really confusing, and introducing a cap on the cap
would only make things worse.
WDYT?
--
Marcin Borkowski
http://mbork.pl
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Lift-the-artificial-limit-on-the-clock-history-lengt.patch --]
[-- Type: text/x-patch; size=1.41KiB, Size: 1443 bytes --]
From bd5c4b7f3afe6a906b91e7f0bd33e2842fcf8656 Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <mbork@mbork.pl>
Date: Fri, 31 Aug 2018 07:53:42 +0200
Subject: [PATCH] Lift the artificial limit on the clock history length.
The default limit of 35 was hard-coded, and was especially annoying
when using an alternative way of selecting from history,
e.g. https://github.com/unhammer/org-mru-clock.
---
lisp/org-clock.el | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 9819fcff2..71ed99f69 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -156,7 +156,10 @@ state to switch it to."
(symbol :tag "Function")))
(defcustom org-clock-history-length 5
- "Number of clock tasks to remember in history."
+ "Number of clock tasks to remember in history.
+Clocking in using history works best if this is at most 35, in
+which case all digits and capital letters are used up by the
+*Clock Task Select* buffer."
:group 'org-clock
:type 'integer)
@@ -534,7 +537,7 @@ cannot be translated."
(defun org-clock-history-push (&optional pos buffer)
"Push a marker to the clock history."
- (setq org-clock-history-length (max 1 (min 35 org-clock-history-length)))
+ (setq org-clock-history-length (max 1 org-clock-history-length))
(let ((m (move-marker (make-marker)
(or pos (point)) (org-base-buffer
(or buffer (current-buffer)))))
--
2.19.0
next prev parent reply other threads:[~2018-10-02 6:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 5:56 How about lifting the limit of 35 tasks in org-clock-history? Marcin Borkowski
2018-09-02 12:45 ` Nicolas Goaziou
2018-09-02 14:50 ` Marcin Borkowski
2018-09-06 14:11 ` Marcin Borkowski
2018-09-06 14:18 ` Nicolas Goaziou
2018-09-08 15:28 ` Marcin Borkowski
2018-10-02 6:12 ` Marcin Borkowski [this message]
2018-10-03 10:51 ` Nicolas Goaziou
2018-10-03 12:19 ` Marcin Borkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zykzxjr.fsf@mbork.pl \
--to=mbork@mbork.pl \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).