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: Divergence in menu appearance between Emacs Info and standalone Info Date: Thu, 5 Jun 2003 10:52:42 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306051552.h55FqgZ27217@eel.dms.auburn.edu> References: <200306051259.h55Cx4W14338@f7.net> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1054830537 10685 80.91.224.249 (5 Jun 2003 16:28:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2003 16:28:57 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jun 05 18:28:55 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Nxb0-0002jM-00 for ; Thu, 05 Jun 2003 18:28:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19Nxt9-0002Uz-00 for ; Thu, 05 Jun 2003 18:46:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NxPM-0006YF-EQ for emacs-devel@quimby.gnus.org; Thu, 05 Jun 2003 12:16:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NxNT-00066U-2R for emacs-devel@gnu.org; Thu, 05 Jun 2003 12:14:11 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NxLn-0005KF-2X for emacs-devel@gnu.org; Thu, 05 Jun 2003 12:12:29 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Nx2l-0000Zj-W4; Thu, 05 Jun 2003 11:52:48 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) h55FqYoc027967; Thu, 5 Jun 2003 10:52:34 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.11.6+Sun/8.11.6) id h55FqgZ27217; Thu, 5 Jun 2003 10:52:42 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: karl@freefriends.org In-reply-to: <200306051259.h55Cx4W14338@f7.net> (karl@freefriends.org) Original-cc: rms@gnu.org 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:14774 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14774 Karl Berry wrote: in this case the differences are in numerous places in the node. It may look very ugly to describe both alternatives. Could you try? It would be better for someone who has actually used or programmed this feature to write at least the first draft. I don't know any of the details. Luc, perhaps you make a first cut at changing info.texi, and then I'll review it? I would be willing to help. But does it make any sense to do this right now? We have not yet decided how either the Emacs or the standalone versions are going to look like. Would the first task at hand not be to worry about those two questions? Otherwise, we might just keep rewriting the manual continuously, as we keep changing our minds. The relevant changes in the Emacs version of Info do not appear in any released Emacs version and should (in my opinion) not appear in any released Emacs version until we have made a decision on how the Emacs version of Info is going to look. It would be very bad to just keep switching the behavior back and forth on the user, in as far as released versions are concerned. CVS users know (or should know) that some features could change back and forth depending on the unexpected problems that they turn out to cause. In other words to me it would seem that the order should be: 1. First decide how the Emacs version is going to look. 2. Decide how the standalone version is going to look. 3. Implement 1 and 2. 4. Rewrite the documentation accordingly. Is there any reason to do things in a different order, unless 3. is scheduled for the extremely vague and extremely distant future? I do not believe implementation of 1. should be put off until then. Implementation of 2. conceivably might, if nobody can find the time. In that case, I would rewrite the manual based on current behavior of the standalone version. Sincerely, Luc.