How to avoid y-or-n-p in a program?

How to avoid y-or-n-p in a program?

[Thorsten Jolitz]

Hi List, 

when in a program function A calls another (external) function B that
asks the user a y-or-n-p question, and you want to avoid that and
instead code in function A that the answer is always Y, so that the
prompt never shows up - how do you do that?

-- 
cheers,
Thorsten

Re: How to avoid y-or-n-p in a program?

[Tassilo Horn]

Thorsten Jolitz <tjolitz@gmail.com> writes:

Hi Thorsten,

> when in a program function A calls another (external) function B that
> asks the user a y-or-n-p question, and you want to avoid that and
> instead code in function A that the answer is always Y, so that the
> prompt never shows up - how do you do that?

In very recent emacs versions, you can use `cl-letf' for that purpose:

--8<---------------cut here---------------start------------->8---
(defun b ()
  (if (y-or-n-p "do it?")
      :done
    :not-done))

(defun a ()
  (cl-letf (((symbol-function #'y-or-n-p)
	     (lambda (&rest ignore) t)))
    (b)))

(a) ;; C-x C-e => :done (and no query)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: How to avoid y-or-n-p in a program?

[Juanma Barranquero]

On Wed, Mar 12, 2014 at 5:14 PM, Tassilo Horn <tsdh@gnu.org> wrote:

> In very recent emacs versions, you can use `cl-letf' for that purpose:

In both new and old versions, you can use `left', from the cl package
(though if your code is for 24.3+ is better to use cl-letf from
cl-lib, yeah).

    J

Re: How to avoid y-or-n-p in a program?

[Stefan Monnier]

> when in a program function A calls another (external) function B that
> asks the user a y-or-n-p question, and you want to avoid that and
> instead code in function A that the answer is always Y, so that the
> prompt never shows up - how do you do that?

The recommended way:
- change B so that it doesn't call y-or-n-p unconditionally.
- change A to adjust to the new behavior of B.


        Stefan

Re: How to avoid y-or-n-p in a program?

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Tassilo, Juanma and Stefan, 

>> when in a program function A calls another (external) function B that
>> asks the user a y-or-n-p question, and you want to avoid that and
>> instead code in function A that the answer is always Y, so that the
>> prompt never shows up - how do you do that?
>
> The recommended way:
> - change B so that it doesn't call y-or-n-p unconditionally.
> - change A to adjust to the new behavior of B.

Thanks for your tips, so I have more than one solution. 

Have to figure out the way of least resistance...

-- 
cheers,
Thorsten

Re: How to avoid y-or-n-p in a program?

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> when in a program function A calls another (external) function B that
>> asks the user a y-or-n-p question, and you want to avoid that and
>> instead code in function A that the answer is always Y, so that the
>> prompt never shows up - how do you do that?
>
> The recommended way:
> - change B so that it doesn't call y-or-n-p unconditionally.
> - change A to adjust to the new behavior of B.

Is it generally considered a (kind of) bug when a COMMAND (not a
function) calls y-or-n-p unconditionally (or enforces user input in
other ways)?

Enforcing user interaction (and lack of function arguments) makes
(re)using such commands in programs quite difficult, but maybe they are
not intended for that anyway?

Would the "recommended way" be applied in this case too? Should one
rather patch the called command B instead of looking for a workaround on
the calling side?

-- 
cheers,
Thorsten

Re: How to avoid y-or-n-p in a program?

[Stefan]

> Is it generally considered a (kind of) bug when a COMMAND (not a
> function) calls y-or-n-p unconditionally (or enforces user input in
> other ways)?

Not sure about "generally", but it's a good principle to decompose
a functionality into a "batch-only" part and an interactive wrapper.

So we probably wouldn't consider all such cases as bugs, but if
a particular case is problematic, you should definitely request the
change (which we may sometimes reject, of course, typically if it would
require too many/ugly modifications to the code).


        Stefan

Re: How to avoid y-or-n-p in a program?

[Thorsten Jolitz]

Stefan <monnier@iro.umontreal.ca> writes:

>> Is it generally considered a (kind of) bug when a COMMAND (not a
>> function) calls y-or-n-p unconditionally (or enforces user input in
>> other ways)?
>
> Not sure about "generally", but it's a good principle to decompose
> a functionality into a "batch-only" part and an interactive wrapper.

So rather than adding additional function args to the command and using
something like (when (called-interactively-p) ...) the canonical way
would be to split the command into a function (probably with additional
function args) and a command that calls this function (the interactive
wrapper)?

> So we probably wouldn't consider all such cases as bugs, but if
> a particular case is problematic, you should definitely request the
> change (which we may sometimes reject, of course, typically if it would
> require too many/ugly modifications to the code).

This would be more directed towards Org-mode I think ...
What if a command/function is overly verbose wrt to messages when used
in a program? Is it reasonable to ask for including an optional switch
like this

(defun xyz (args &optional quiet)
  (unless quiet
    (message ...)))

to be able to suppress all the messages in the function call?

-- 
cheers,
Thorsten

Re: How to avoid y-or-n-p in a program?

[Stefan]

> So rather than adding additional function args to the command and using
> something like (when (called-interactively-p) ...) the canonical way
> would be to split the command into a function (probably with additional
> function args) and a command that calls this function (the interactive
> wrapper)?

Yes, when that can be done without too much gymnastics, it's the best option.

> This would be more directed towards Org-mode I think ...
> What if a command/function is overly verbose wrt to messages when used
> in a program? Is it reasonable to ask for including an optional switch
> like this

> (defun xyz (args &optional quiet)
>   (unless quiet
>     (message ...)))

> to be able to suppress all the messages in the function call?

The situation for messages is somewhat similar, although more subtle
because "too many messages" is not as clear cut as "hangs, waiting for
the user to respond".

I think that for messages, the right answer is a more serious redesign
of the messaging system, e.g. such that you can redirect messages
(rather than just silence them), and maybe also do it conditionally on
the "seriousness/urgency" of the message.


        Stefan

Re: How to avoid y-or-n-p in a program?

[Thorsten Jolitz]

Stefan <monnier@iro.umontreal.ca> writes:

>> So rather than adding additional function args to the command and using
>> something like (when (called-interactively-p) ...) the canonical way
>> would be to split the command into a function (probably with additional
>> function args) and a command that calls this function (the interactive
>> wrapper)?
>
> Yes, when that can be done without too much gymnastics, it's the best
> option.
>
>> This would be more directed towards Org-mode I think ...
>> What if a command/function is overly verbose wrt to messages when used
>> in a program? Is it reasonable to ask for including an optional switch
>> like this
>
>> (defun xyz (args &optional quiet)
>>   (unless quiet
>>     (message ...)))
>
>> to be able to suppress all the messages in the function call?
>
> The situation for messages is somewhat similar, although more subtle
> because "too many messages" is not as clear cut as "hangs, waiting for
> the user to respond".
>
> I think that for messages, the right answer is a more serious redesign
> of the messaging system, e.g. such that you can redirect messages
> (rather than just silence them), and maybe also do it conditionally on
> the "seriousness/urgency" of the message.

I remember that this was discussed not so long ago and seems to be
something that would really benefit Emacs as a whole. 

PS

BTW, just recently I asked if there is a logging system for PicoLisp,
and someone implemented a quite useful one with only 45 lines of code or
so (http://beneroth.ch/pil/log.l).

-- 
cheers,
Thorsten