Hello, David Caldwell <ddcows2...@yahoo.com> writes:
> This bug is a replacement of bug #22735(24.3; org-set-effort *without* > numeric prefix - still forces me to use nth allowed). After more > experimentation, I got a better understanding of the functionality and > now consider that bug 22735 to be invalid as written. I now think > it's a more fundamental issue of not handling an Effort_ALL with more > than 10 entries. The problems manifest in both interactive > org-set-effort and in column view when editing values via direct index > selection. > Problems: 1) interactive org-set-effort 1) can not enter an index >> 10 2) method of entering a raw value is arcane and unvalidated > - by prefixing the entered value by '-', you can enter one of > the Effort_ALL string directly - e.g. Effort_ALL 0 1h 2h 4h > 1d 2d 3d 4d 1w 2w 3w 4w - 'C-c C-x e -4w RET' sets Effort to > '4w' - however, a value of '-foobar' sets Effort to 'foobar' > 3) Note: org-set-effort with numerical prefix works properly for > indices > 10 2) column view - editing values 1) 1-9,0 - can not > enter an index > 10 - lower priority than 1.1 above since > column view edit 'e' allows direct entry of Effort_ALL strings (with > validation) 2) Note: S-left/right, n, p work properly for indices >> 10Proposed solution: - interactive org-set-effort and column view > direct index selection - input multiple characters followed by RET > - if input is a valid index, use the corresponding value from > Effort_ALL - else if input is a valid Effort_ALL value, use it - > else beep and display [No Match] (like column view edit when an > invalid value is entered) I've changed `org-set-effort' to use `completing-read' for allowed values instead of relying on position in list. The prefix argument now means "increment". This is simpler and less exotic. WDYT? Regards, -- Nicolas Goaziou 0x80A93738