bug#4873: 23.1.50; Some unexpected behaviour during dired confirmation prompt

[Tim Van Holder <tim.vanholder@gmail.com>]

On 1 March 2011 09:25, Glenn Morris <rgm@gnu.org> wrote:
>
> Thanks for the report, sorry for the long delay in replying.
> Please see comments below.
>
> Tim Van Holder wrote:
>
>> Given a dired session in a directory containing files 'a' and 'b':
>> - put cursor on 'a' and press R (rename)
>> - enter 'b' as new name
>>
>> Result: dired prompts with "Overwrite 'b'? [Type yn!q or C-h]".

Small note for completeness: the prompt currently uses
'/full/path/to/b' rather than just 'b'.

>> Unexpected behaviour at this point:
>> - C-g does not work (only 'q' cancels)
>
> I cannot reproduce this in Emacs 23.1 or 23.2, using `-Q'.

With emacs 24.0.50.2 (built from bzr trunk on 2011-02-24) running on
an old debian box with X tunneled to a Cygwin X server, both with and
without -Q, this actually blocks emacs from processing any keyboard
input. Menus still open, mouse events are still triggered (cursor
changes, tooltip is shown), but actual commands (whether from menu,
mouse, or keyboard) fail to work properly. Some have temporary effect
(e.g. F1/C-h show a help buffer, but it disappears almost
immediately).
Only the 4 listed keys (y/n/!/q) are accepted and cause emacs to
resume normal functionality.

For reference, this is what report-emacs-bug currently says:
In GNU Emacs 24.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2011-02-24 on leeloo
Windowing system distributor `The Cygwin/X Project', version 11.0.10904000
configured using `configure  '--with-x''

>> - toolbar goes blank (with a minor frame resize as a result);
>
> I cannot reproduce this in Emacs 23.2 (cannot test 23.1 right now).

I don't see this any more either.

>> - Pressing a key other than those listed results in
>>     "Invalid key - type   for help."
>>   (i.e. the character for ^H (0x08) is shown instead of "C-h")
>
> I see this in 23.1, but not in 23.2.

As described above, it just does nothing for any keys other than the 4
that are explicitly allowed - no errors (also nothing in *Messages*).

> So in summary I either cannot reproduce these issues, or they seem to
> have been fixed. Are you still seeing any of them with `emacs -Q'?
>
>
>> In GNU Emacs 23.1.50.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
>>  of 2009-11-05 on leeloo
>