From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: 15 Mar 2004 08:27:31 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200403120124.i2C1OsS22697@raven.dms.auburn.edu> <87znai8zuk.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079361213 19849 80.91.224.253 (15 Mar 2004 14:33:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Mar 2004 14:33:33 +0000 (UTC) Cc: emacs-devel@gnu.org, Luc Teirlinck , karl@freefriends.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 15 15:33:26 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B2t9i-0003y1-00 for ; Mon, 15 Mar 2004 15:33:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B2t9i-0001dm-00 for ; Mon, 15 Mar 2004 15:33:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B2sdq-00017W-Bx for emacs-devel@quimby.gnus.org; Mon, 15 Mar 2004 09:00:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B2sbw-0000ob-Qs for emacs-devel@gnu.org; Mon, 15 Mar 2004 08:58:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B2sbJ-0000dz-HU for emacs-devel@gnu.org; Mon, 15 Mar 2004 08:58:25 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B2s8K-0004vs-PA for emacs-devel@gnu.org; Mon, 15 Mar 2004 08:27:56 -0500 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 53F2F20FFD; Mon, 15 Mar 2004 08:27:51 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 996438C8E4; Mon, 15 Mar 2004 08:27:50 -0500 (EST) Original-To: Juri Linkov In-Reply-To: <87znai8zuk.fsf@mail.jurta.org> Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.001, requis 5, BAYES_40 -0.00) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20503 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20503 >> There was a patch by Juri Linkov discussed in December that added >> FORK arguments to several Info functions, > I added FORK argument not to all Info navigation functions. > Now I will add it to all of them. I think this is the wrong approach. We want a generic way to do "a fork" without having to change each and every command where it might make sense. And I now regret having abuse the C-u prefix for that. It should be some other fork-specific prefix instead so the command can still use C-u for its own purpose. > Since then I improved the info.el further. I will submit the latest > version soon. Please submit "one feature" at a time, so that if one of them is controversial it will not prevent others from being applied. > IIRC, the "controversial" feature you refer to was guessing the target > place within an Info node from the reference name. While I agree that > this is an unreliable feature, it's still better than simply placing > the point at the beginning of a big Info node. Another alternative is > to use anchors, but it places responsibility on authors of Info > manuals to define correct reference points. If using anchors is > accepted solution then at least all Emacs manuals should be revised > to find all such references that refer to big Info nodes and to make > anchors for them. I think your solution is at least as good as the current situation, and sometimes much better. Stefan