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

[martin rudalics]

> 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