From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: locate-with-filter Date: Wed, 29 Mar 2006 18:29:59 -0600 (CST) Message-ID: <200603300029.k2U0TxZ11021@raven.dms.auburn.edu> References: <200603160048.k2G0msu23696@raven.dms.auburn.edu> <200603170221.k2H2L1H14401@raven.dms.auburn.edu> <17435.52238.927514.585806@kahikatea.snap.net.nz> <200603181716.k2IHGpN17847@raven.dms.auburn.edu> <17436.56026.490667.58771@kahikatea.snap.net.nz> <200603190455.k2J4tEK25830@raven.dms.auburn.edu> <200603200512.k2K5CFN12390@raven.dms.auburn.edu> <200603290409.k2T49W729435@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1143678979 1704 80.91.229.2 (30 Mar 2006 00:36:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Mar 2006 00:36:19 +0000 (UTC) Cc: nickrob@snap.net.nz, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 30 02:36:13 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FOl8y-000897-DH for ged-emacs-devel@m.gmane.org; Thu, 30 Mar 2006 02:36:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOl8x-0005C1-Tk for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2006 19:36:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FOl8n-0005Bm-Qc for emacs-devel@gnu.org; Wed, 29 Mar 2006 19:35:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FOl8m-0005Ba-1O for emacs-devel@gnu.org; Wed, 29 Mar 2006 19:35:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOl8l-0005BW-Ti for emacs-devel@gnu.org; Wed, 29 Mar 2006 19:35:55 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FOlAo-0001fa-Fk; Wed, 29 Mar 2006 19:38:02 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k2U0ZroV000467; Wed, 29 Mar 2006 18:35:53 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k2U0TxZ11021; Wed, 29 Mar 2006 18:29:59 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Wed, 29 Mar 2006 18:02:28 -0500) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Wed, 29 Mar 2006 18:35:53 -0600 (CST) 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:52215 Archived-At: Richard Stallman wrote: After the changes you made to help-follow, binding `help-follow' to anything else but RET does not work anymore. Why is that? Because after your changes, `help-follow' is a function that just unconditionally gives an error message, even when invoked on a button. Of course, you can bind `help-follow' to any key you want, but when you type that key in a help buffer, all you get is the error message: "No cross-reference here", even when you type it with point on a button. (if (display-mouse-p) "\\[help-follow-mouse] or ") ! "RET on a face name to customize it\n" "or on its sample text for a description of the face.\n\n"))) I don't want to document a bug. If you mean the bug that binding `help-follow' to anything else but RET does not work, then my third patch fixes that bug. But RET might still have to be hard coded in the introductory text for other reasons, explained below, and that is what my first two patches do. I do not know how to fix the problem with "\\[help-follow]" and (presumably) `minor-mode-overriding-map-alist', even after applying my third patch. But RET actually should be hard coded in that doc. "\\[help-follow]" gives the binding of `help-follow' in the local map, that is the binding in effect when _not_ on a button. But the doc in question talks about the behavior of RET _on buttons_, which is determined by the buttons' text properties and has nothing to do with the local map. So "\\help-follow" is an incorrect construct here. After my third patch `M-x help-follow' would indeed work on buttons, so the introductory text would no longer be incorrect. But why encourage the user to type `M-x help-follow', whereas the much more convenient RET binding is available? Note that RET will work on buttons _even_ if the user bound help-follow to another key _and_ bound RET to another command in help buffers. It is implemented by text properties. The help echo on the buttons also hard codes RET, so hard coding RET in the introductory text too would only be consistent. This looks like it is putting back the old code that I replaced. If so, that would bring back the bug I fixed. I do not want to do that. It would be the wrong fix. If this is different from the old code, would you please tell me the difference? `help-follow' in the old code did whatever `push-button' does when invoked with point over a button and did what the current `help-follow-symbol' does when not over a button. Your changes made `help-follow' print an error message everywhere. My patches restore the old behavior when `help-follow' is invoked over a button, but print an error message when invoked anywhere else. The behavior after my patches is _exactly_ the same as the behavior after your changes, as long as help-follow is only bound to RET. But if you bind `help-follow' to some other key, then the present code prints an error message _everywhere_ in an help-buffer, whereas after my patches, the rebound key would behave exactly the same way as RET currently does: follow the button if on a button, otherwise print an error message, Sincerely, Luc.