From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: info Date: Wed, 29 Jan 2003 13:57:27 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301291957.NAA25981@moose.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1043870191 19545 80.91.224.249 (29 Jan 2003 19:56:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2003 19:56:31 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18dyJu-00054f-00 for ; Wed, 29 Jan 2003 20:56:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18dyPE-0001Pc-00 for ; Wed, 29 Jan 2003 21:01:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18dyLM-0003TR-00 for emacs-devel@quimby.gnus.org; Wed, 29 Jan 2003 14:57:56 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18dyL0-0003S7-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 14:57:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18dyKy-0003Po-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 14:57:33 -0500 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18dyKy-0003PI-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 14:57:32 -0500 Original-Received: from moose.dms.auburn.edu (moose.dms.auburn.edu [131.204.53.3]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id NAA03954; Wed, 29 Jan 2003 13:57:30 -0600 (CST) Original-Received: (from teirllm@localhost) by moose.dms.auburn.edu (8.9.3+Sun/8.9.3) id NAA25981; Wed, 29 Jan 2003 13:57:27 -0600 (CST) X-Authentication-Warning: moose.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: eliz@is.elta.co.il In-reply-to: (message from Eli Zaretskii on Wed, 29 Jan 2003 08:29:48 +0200 (IST)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11197 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11197 Eli Zaretskii wrote: That's not good: RET also follows a cross-reference near point, not only menu items. So it must first find out what is ``the thing'' near point that it should follow, and then do it. You are right here. I forgot about xrefs and the like. I retract my original suggestion. However, you seem to vastly underestimate the differences between stand-alone behavior and Emacs behavior. I'm not sure I like it: what RET does currently in Info is similar to many other programs which support links or references of some kind: if there's no link anywhere in sight, they do nothing, no questions asked. Users generally know that if RET didn't have any effect, point is not on a link. What you suggest deviates significantly from that behavior, and I seriously wonder whether the downsides of the deviation are justified by whatever gains you think we'll have. That may be what RETURN does in stand-alone info. In the Emacs version however, RETURN currently always tries to do something, whether there is something obvious to do or not. The consequences can be extremely confusing. I don't remember all the intricacies of this, but I do remember that it is not always easy to decide what menu item to select. But, that is exactly the problem. The Emacs version makes decisions in cases where trying to make a decision is hopeless, resulting in wild and unpredictable behavior. I hope newbies learn about the `l' key fast, or they are not going to have fun with RETURN. IMHO we should not change what RET does if it cannot find any link nearby. What you seem to be saying is that it should not be changed from its stand-alone behavior. That means a radical change for the Emacs version. I like the behavior of the stand-alone Info better than what Emacs does now and better than what you propose. (But then I'm not objective about this: I worked on these aspects of the stand-alone reader.) I guess we all like it better than what Emacs does now. Also, of course you do not like what I proposed, even I do not like it anymore. The only concrete proposal I made was silly, I completely overlooked something. (Sorry about that.) Changing Emacs behavior to the stand-alone behavior you describe would be acceptable to me. It would also be helpful to users using both if they were made more compatible. Note however, that in as far as the Emacs version is concerned, that constitutes a change. A possible alternative would be to make RETURN do the same thing as mouse-2 if mouse-2 does something (includes xrefs), otherwise the same as m RETURN if that does something (by default), otherwise nothing. If there is an obvious choice, that chooses it. Whenever there is no obvious choice, only users familiar with the way m chooses defaults in the given situation would be tempted to use it anyway. Again however, the stand-alone behavior you describe sounds perfectly acceptable. One last example of actual behavior in the Emacs version. Do: C-h i m emacs m killing. We see: * Menu: * Deletion:: Commands for deleting small amounts of text and blank areas. * Killing by Lines:: How to kill entire lines of text at one time. * Other Kill Commands:: Commands to kill large regions of text and syntactic units such as words and sentences. Place point on syntactic, in the last line of the quote. Which node do you expect to go to if you press RETURN and which one do you actually go to (in the Emacs version). I believe the present Emacs situation definitely needs a change. Sincerely, Luc.