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: Fri, 31 Jan 2003 19:22:45 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200302010122.TAA12524@eel.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1044062970 17238 80.91.224.249 (1 Feb 2003 01:29:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 1 Feb 2003 01:29:30 +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 18emTI-0004Tq-00 for ; Sat, 01 Feb 2003 02:29:28 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18emZh-0006ge-00 for ; Sat, 01 Feb 2003 02:36:05 +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 18emSh-0005cO-00 for emacs-devel@quimby.gnus.org; Fri, 31 Jan 2003 20:28:51 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18emQp-000422-00 for emacs-devel@gnu.org; Fri, 31 Jan 2003 20:26:55 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18emQj-0003xE-00 for emacs-devel@gnu.org; Fri, 31 Jan 2003 20:26:51 -0500 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18emM6-0008IQ-00; Fri, 31 Jan 2003 20:22:02 -0500 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id TAA18277; Fri, 31 Jan 2003 19:22:00 -0600 (CST) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id TAA12524; Fri, 31 Jan 2003 19:22:45 -0600 (CST) X-Authentication-Warning: eel.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 Fri, 31 Jan 2003 14:20:14 -0500) Original-cc: eliz@is.elta.co.il Original-cc: kai.grossjohann@uni-duisburg.de 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:11269 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11269 Richard Stallman wrote: In this case, it would be good for RET to get an error. Probably it should take a single menu item to consist of the * line followed by all successive indented lines, including blank lines when further indented lines follow but excluding blank lines that would be at the end of the menu item. Problems occur in situations like: * Sample .emacs File:: --- Indices --- * Concept Index:: I see the problem, but don't worry about it too much. It doesn't have to be perfect, just better. It would be better to make occasional rare mistakes like this than to fail frequently on multi-line menu items. Yes, but I have found worse examples since and the problem cases do not seem to be that rare at all. Two examples among the many I found: Example 1: * Menu: * Interactive Customization:: * Permanent Customization:: * Hooks:: * Styles:: * Advanced Customizations:: ---------- Footnotes ---------- (1) Available in Emacs 20 and later, and XEmacs 19.15 and later. (2) Obviously, you use the key binding interactively, and the function call programmatically! (3) There is however a variable `c-strict-syntax-p' that, when set to non-`nil', will cause an error to be signaled in that case. It's now considered obsolete since it doesn't work well with some of the alignment functions that now returns `nil' instead of zero to be more usable in lists. You should therefore leave `c-strict-syntax-p' set to `nil'. (4) You can try this interactively in a C buffer by typing the text that appears in italics. My comments: The described algorithm would still go "* Advanced Customizations::" at the end of the first line of footnote (2) and, even then, we are lucky that footnote (2) is multi-line. Worse could have happened. Example 2: * Other Commands:: See also *Note Text Filling and Line Breaking::, for commands concerning that bit. My comments: With point after "concerning", the algorithm would still go to "* Other Commands::", even though there is a cross-reference in between. As I said such examples are not rare. I see at least three solutions that would be better than the algorithm you propose: 1. Take over the stand-alone behavior, maybe with an improved error message. Advantage: Never produces confusion, if the error message is sufficiently clear. 2. The second proposal I made, namely do whatever mouse-2 would, otherwise whatever "m RETURN" would do by default, otherwise nothing. Advantage: Always does the obvious thing if there is one. Disadvantage: can look very unnatural, but only in situations where pressing RETURN is very unnatural to begin with, and is completely consistent and predictable. 3. Use Kai's algorithm. The reason why I believe that 2. is relatively better than the solution you propose, is that a surprised user could at least easily figure out what the behavior is, using C-h k or by experimentation. That is not the case with the solution you propose. Take example 1. The user presses RETURN in the described spot (out of curiosity, I can not see any other reason) and sees that (s)he winds up in * Advanced Customizations:: Now the user believes that when (s)he presses RETURN in a footnote (s)he will always go to the last menu item. True for 2., but with the algorithm you propose, (s)he is in for some further surprises. In as far as 3. is concerned, I have not found any example yet where Kai's algorithm goes obviously wrong. Kai's algorithm obviously malfunctions for descriptions containing blank lines. But such cases seem to be more rare than the instances in which the algorithm you describe malfunctions. (Actually, I have not even found a concrete example yet, although I am sure there must be some somewhere.) However, anything we implement should work for all info files. That includes, for instance, files not originally written in texinfo but automatically generated from, say, SGML files. I have no experience whatsoever with these and do not know whether they could have weird indentation and, hence, lead to major malfunctioning of any indentation based algorithm. Of the three above solutions, 1. seems the safest, even though I agree it is not ideal. But there does quite simply not seem to be an ideal solution. Sincerely, Luc.