Theres a hig bug on this issue. Imo this doesn't necessarily make
sense, as escape normally means cancel, get me out of here, and undo
any changes i might have done. Anyway I would recommend against any
change until the hig bug is resolved.

IMO <esc> means "cancel" in sense "interrupt", not in sense "undo" or
"rollback".

Undo/rollback can be part of cancel if this is intuitivelly expected
by user (e.g. rolling back of transaction in the RDBMS is intuitive
expected part of transaction cancelling).

From another hand: when I do search/replace then I don't expect any
undo/rollback effects.  Scenario: begin search/replace, replace what
you want and cancel (interrupt) S&R because no wishes to replace rest
of occurences exists.  Is you expect rolling back all your changes?  I no.

Conclusion: cancel should interrupt current operation.  But undo or
not undo changes that was already made before canceling -- bechvior
should be selected in every case separatelly.  Criteria of this
selecting: user shoult intuitivelly expect this behavior.  Yes, case
#3 exists where no obvious selection exists and this is subject for
another game...

But in this concrete case abour Search dialog, IMO, selection is obvios.

Moreover, rule of thumb of interface desighn is: "always try to work
with this, designed by you, interface".  But...  Too many cases exists
where this rule is violated :-(

Consequence from
http://mail.gnome.org/archives/usability/2003-July/msg00020.html

HIG developers (as I understand) was think about bounding <Esc> to the
"stop" button in the search and/or replace dialogs, but merely forgot
to say this explicitly.

*** Bug 118511 has been marked as a duplicate of this bug. ***

Usability guys: what should I do?

I vote for leaving it until the HIG bug is resolved too.  Until then,
Esc is purposely not bound to Close in any GNOME windows or dialogs,
and I don't see what's any different about this window that would
merit going against that guideline.

*** Bug 112683 has been marked as a duplicate of this bug. ***

*** Bug 124827 has been marked as a duplicate of this bug. ***

*** Bug 131927 has been marked as a duplicate of this bug. ***

Created attachment 23526 [details] [review]
cause Escape key to cancel Find/Replace dialogs

Attached patch fixes this issue, when/if people decide to allow Escape
to close Find/Replace dialogs (patch is from #131927)

*** Bug 139788 has been marked as a duplicate of this bug. ***

Bug made "WONTFIX" based on Calum's comment.

Everybody and their dogs would love this dialog close with esc (as a matter of
fact RedHat ships the above patch). That said it's clear that gedit, as a part
of the desktop, will not accept a behavior that goes against the HIG.

So IMHO this bug should stay open until the HIG bug is resolved and also as a
remainder that a different UI for search may have to be investigated.

The thread awn@bcs.zp.ua points to indicates a human error in the HGI. I suppose
that wil be fixed some time. I suggest gedit 'takes the lead' on this one and
enables ESC to close the search window. It's extremely annoying I can't easily
close that dialog using just the keyboard (well, atleast ESC is much faster than
ATL-F4, and it won't accidently close gedit).

*** Bug 151512 has been marked as a duplicate of this bug. ***

*** Bug 151590 has been marked as a duplicate of this bug. ***

This issue (<esc> not closing the dialog) also affects the 'go to line' dialog,
raised originally in bug 151590 (marked as duplicate).

*** Bug 159472 has been marked as a duplicate of this bug. ***

Since nothing seems to change on the HIG side, as suggested by Jeroen, I have
decided that gedit will 'take the lead' on this problem and so, I have enabled
ESC to close the search/replace dialog and the "go to line" one.

Closing this bug as FIXED.

*** Bug 167717 has been marked as a duplicate of this bug. ***

*** Bug 168598 has been marked as a duplicate of this bug. ***

*** Bug 168601 has been marked as a duplicate of this bug. ***