bug#34749: 26.1; `delete-windows-on': (1) doc, (2) bug, (3) bug, (4) candidates

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 08 Mar 2019 19:52:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 34749@debbugs.gnu.org
> 
>  > I think we should simply try letting the user provide all possible
>  > values of the FRAME argument in interactive invocations, by using
>  > different forms of 'C-u'.
> 
> I have no idea how to do that.

Maybe we are having a misunderstanding.  Because all I meant is to
have each of the possible values of FRAME be expressible with some
form of prefix-arg.  There are several such forms available:

 . just C-u
 . C-u with a numeric argument
 . repeated C-u C-u ...

We currently only use the second of these, and with a single numeric
argument of zero.  What I had in mind is to use the other forms, and
perhaps also other numeric arguments, to allow users in interactive
invocation access to all possible values of FRAME.

>  > That'd be too radical, IMO.  I'd rather we described the exceptional
>  > cases, because I think they would be rare.  Can you enumerate those
>  > exceptions?
> 
> The doc-string should hopefully tell these details now.

I'm not sure it covers the use case described by Drew.  Maybe I'm
missing something.

>  > I think it would be better to rework the interpretation of the prefix
>  > arg so it makes sense.
> 
> The fact that 'delete-windows-on' is the only function (together with
> its 'quit-window-on' clone) with the inverted meaning of the
> FRAME/ALL-FRAMES argument makes me doubt that such an interpretation
> would make sense.

Do you still think that, after reading my explanation above?

> And when trying to read the documentation on 'interactive' I nowhere
> detected where the "\nP" convention is described (which apparently
> turns a function's last (?)  argument into the prefix argument).
> Can someone enlighten me?

It's described in this passage from "Using Interactive":

   There are three possibilities for the argument ARG-DESCRIPTOR:

   [...]
   • It may be a string; its contents are a sequence of elements
     separated by newlines, one for each argument(1).  Each element
     consists of a code character (*note Interactive Codes::) optionally
     followed by a prompt (which some code characters use and some
     ignore).  Here is an example:

          (interactive "P\nbFrobnicate buffer: ")

     The code letter ‘P’ sets the command’s first argument to the raw
     command prefix (*note Prefix Command Arguments::).  ‘bFrobnicate
     buffer: ’ prompts the user with ‘Frobnicate buffer: ’ to enter the
     name of an existing buffer, which becomes the second and final
     argument.