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: Sun, 19 Mar 2006 14:19:19 -0600 (CST) Message-ID: <200603192019.k2JKJJK06505@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> <17437.48079.38198.589753@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1142799926 7466 80.91.229.2 (19 Mar 2006 20:25:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2006 20:25:26 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 19 21:25:25 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 1FL4Sl-0000rn-Fy for ged-emacs-devel@m.gmane.org; Sun, 19 Mar 2006 21:25:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FL4Sk-0006JP-JT for ged-emacs-devel@m.gmane.org; Sun, 19 Mar 2006 15:25:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FL4SV-0006JA-Lm for emacs-devel@gnu.org; Sun, 19 Mar 2006 15:25:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FL4SS-0006HO-Iu for emacs-devel@gnu.org; Sun, 19 Mar 2006 15:25:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FL4SS-0006HI-7N for emacs-devel@gnu.org; Sun, 19 Mar 2006 15:25:00 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FL4Xn-0008Go-MS; Sun, 19 Mar 2006 15:30:31 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.4+Sun/8.13.3) with ESMTP id k2JKOn29005233; Sun, 19 Mar 2006 14:24:49 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k2JKJJK06505; Sun, 19 Mar 2006 14:19:19 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: nickrob@snap.net.nz In-reply-to: <17437.48079.38198.589753@kahikatea.snap.net.nz> (message from Nick Roberts on Mon, 20 Mar 2006 08:15:11 +1200) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Sun, 19 Mar 2006 14:24:49 -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:51860 Archived-At: Nick Roberts wrote: When looking at the value of any variable e.g auto-mode-alist all explicit links have been deliberately removed because some were inappropriate e.g those for `features'. As I already said, allowing the user to follow such unplanned "links" conveniently (although `C-h f' is not actually that inconvenient for occasional use of the type you describe) is a different functionality from deliberate links intended as guidance to the user. With the alternate change I proposed, you could still follow these links with `C-c C-c' or, you could keep the old behavior by rebinding `help-follow-symbol' to RET. Unlike what I said in the last message that actually arrived on emacs-devel, rebinding `help-follow-symbol' to RET _would_ restore the old behavior _exactly_, even with the "(unless (push-button pos)" removed. I explained why in a follow up message that may or may not still arrive. (It is because the `push-button' binding for RET shadows the `help-follow-symbol' binding whenever that line would make a difference. `push-button' does not shadow `C-c C-c'.) The code that implements author intended links goes through quite some effort to avoid presenting the user with documentation that might be (sometimes very) confusing. The present `help-follow' does not and thereby completely ruins these efforts. Here is one example of the _many_ ways that the present help-follow can confuse the user in ways that it no longer will after Richard's change. If you currently press RET on the unquoted word function or on the word function in "the symbol `function'", you get told that function is a variable with value `help-xref-interned' and if you do the same for pos instead of function, you get told that pos is a variable with _some_ concrete integer value. These are the values that `function' and `pos' are dynamically bound to while the present help-follow is being called. The code called by actual buttons carefully tries to avoid this, as well as various other sources of confusion. At present, to no avail. The present `help-follow' overrides it. The present `help-follow' is meant for experienced Elisp programmers who will not get confused by stuff like this. Sincerely, Luc.