[Top][All Lists]

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

bug#31782: 26.1; dired-recursive-deletes broken

From: Eli Zaretskii
Subject: bug#31782: 26.1; dired-recursive-deletes broken
Date: Tue, 31 Jul 2018 19:00:44 +0300

> From: Noam Postavsky <address@hidden>
> Date: Mon, 30 Jul 2018 21:39:12 -0400
> Cc: address@hidden, Juri Linkov <address@hidden>
> There are differences in both the interface and implementation which
> make it difficult to merge these, even though the functionality has some
> overlap.  Maybe something could be done later, but for now we'll have to
> settle for taking it as is (modulo the fix for the standard value
> problem).  Here is the backported patch:

LGTM, thanks.

> +;; For backward compatibility check if short y/n answers are preferred.
> +(defcustom read-answer-short 'auto
> +  "Control whether `read-answer' accepts short answers.

This is unnecessarily vague.  How about

  If non-nil, `read-answer' accepts single-character answers.

with all the rest intact?

> I guess assoc-delete-all should be announced in NEWS too?

Yes, please.

> Although it looks like it could be replaced with cl-delete instead.

Such a small and simple function doesn't justify loading cl-seq, IMO.
And we already have a similar function in subr.el.

> -(defcustom read-answer-short (eq (symbol-function 'yes-or-no-p) 'y-or-n-p)
> -  "If non-nil, accept short answers to the question."
> -  :type 'boolean
> +(defcustom read-answer-short 'auto
> +  "Control whether `read-answer' accepts short answers.
> +If t, accept short (single key-press) answers to the question.
> +If nil, require long answers.  If `auto', accept short answers if
> +the function cell of `yes-or-no-p' is set to `y-or-on-p'."
> +  :type '(choice (const :tag "Accept short answers" t)
> +                 (const :tag "Require long answer" nil)
> +                 (const :tag "Guess preference" auto))
>    :version "27.1"

The :version tag should change, right?

> And once backported, we should remove the announcement from 27.1 NEWS,
> since the new function it will already be introduced in 26.2:



reply via email to

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