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

[martin rudalics <rudalics@gmx.at>]

 > Those other-* function also need to allow the user to specify a count,
 > something that we don't have to do here.  So there's no reason to
 > expect consistency here.  (I do think it would be good to allow the
 > user to control the last argument of other-window and other-frame as
 > well, if that's possible, but the solution doesn't have to be
 > identical to what we do with delete-windows-on.)

It would be confusing if it weren't.

 >>   >     • 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.
 >>
 >> That text is all right and yet was incomprehensible for me at first
 >> (and second) reading.  It's probably just me, so ignore that.
 >
 > Maybe we should improve it.  But I cannot tell how, because "a
 > sequence of elements separated by newlines, one for each argument" is
 > very clear for me.  If you can tell what was incomprehensible in that,
 > maybe we will be able to come up with an improvement.

The text is too perfect with two cross references, a footnote and an
example with a hacker idiom.  Not a single redundancy, not a word to
miss.  Probably too terse for me.

martin