[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