From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: auto-insert help-buffer Date: Thu, 08 Mar 2007 16:48:30 -0500 Message-ID: References: <45D967C4.5060104@easy-emacs.de> <87fy8fu2kv.fsf@stupidchicken.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1173390706 7344 80.91.229.12 (8 Mar 2007 21:51:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2007 21:51:46 +0000 (UTC) Cc: andreas.roehler@easy-emacs.de, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 08 22:51:40 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HPQWS-0005fJ-4w for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2007 22:51:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPQWg-0006Mh-U9 for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2007 16:51:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HPQVN-0005nv-0x for emacs-devel@gnu.org; Thu, 08 Mar 2007 16:50:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HPQVM-0005nZ-L5 for emacs-devel@gnu.org; Thu, 08 Mar 2007 16:50:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HPQVM-0005nU-Bx for emacs-devel@gnu.org; Thu, 08 Mar 2007 16:50:32 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HPQV6-0002IP-Ft for emacs-devel@gnu.org; Thu, 08 Mar 2007 16:50:16 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1HPQTO-0003LT-0P; Thu, 08 Mar 2007 16:48:30 -0500 In-reply-to: <87fy8fu2kv.fsf@stupidchicken.com> (message from Chong Yidong on Thu, 08 Mar 2007 11:23:12 -0500) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67586 Archived-At: We need to look for the solution in terms of what the user wants in the various cases. One possibility is to remove the unwind protect; the other is to check in the mouse-click functions whether the desired window is live or not. Which solution is preferable? Both of them will make users unhappy. The first would mean that typing SPC no longer gets rid of the help window. Clearly bad. The second will avoid the error in these mouse commands, but it won't make the commands actually _work_. So the user will be disappointed. If a user clicks on the help buffer, he wants to operate on it. So _in that case_, that window should not vanish. It should stay around to be operated on. Here's a way to implement it: If the event that was read is a mouse event, and the buffer it's on is the help buffer, it should discard the unwind-protect without restoring the old window config. If the event is not a mouse event, it should do what it does now. It's not perfectly simple, but it is not very complex either. Can you implement that?