On 2018-09-06, at 16:18, Nicolas Goaziou wrote: > Hello, > > Marcin Borkowski 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