bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64433: 30.0.50; Fix and improve setting priority of todo-mode items


From: Stephen Berman
Subject: bug#64433: 30.0.50; Fix and improve setting priority of todo-mode items
Date: Mon, 03 Jul 2023 14:23:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Mon, 03 Jul 2023 11:52:36 +0200 Stephen Berman <stephen.berman@gmx.net> 
wrote:

> There are several bugs in setting the priority of todo items in
> todo-mode:
>
> - On typing `#' you are prompted to enter a priority; for example, in a
>   category with 7 items the prompt is this:
>     Set item priority (1-7) (default 1):
>   If you enter a number outside of this range, there is another prompt:
>     Priority must be an integer between 1 and 7.
>      (default 1)
>   This prompt is infelicitous, occupying two lines and lacking a colon
>   to indicate an expected input.
>
> - You can also set the priority by passing a numerical prefix argument,
>   e.g. `C-u 7 #' or simply `7 #' sets the priority to 7 directly without
>   prompting.  However, here out-of-range prefix arguments are accepted
>   and the result is at least in two cases odd: typing `0 #' sets the
>   priority in a category with 7 items 1 by default (1 is always the
>   highest priority).  And typing `8 #' or e.g. `8761 #' sets the
>   priority to 7, which may seem reasonable; however, with a negative
>   prefix, e.g. `-3 #', the priority is also set to 7.
>
> - If, in a category with, say, 7 items, with point on the item with
>   priority 4, you type `#' and at the prompt enter 4, or if you invoke
>   `4 #', then the priority of the item is correctly unchanged, however,
>   the buffer is marked as modified.  Since setting the priority to the
>   item's current priority is useless, doing so is probably
>   unintentional, so it would be better for todo-mode to respond with a
>   prompt for a different priority.  (An exception is moving an item to
>   another category: it is and should remain possibly to move an item
>   from a category in which it has priority 4 to another category and
>   there give it priority 4.)
>
> I have a fix for these bugs and will install it on master when I get a
> bug number.
>
> In addition, I will install a minor improvement in the usability of
> priority setting: making the minibuffer history for priority setting
> consist of the range of item numbers (or in the case of adding a new
> item, the maximum priority number is one more then the last item
> number).  This is useful to quickly invert the default (set by a user
> option); e.g., with the default priority 1, in a category with 37 items,
> typing `M-p' at the prompt to enter the priority will insert 37 in the
> minibuffer (or 38 if a new item is being inserted in the category).

Pushed to master as 14ae2101412, closing bug.

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]