From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: Tue, 16 Mar 2004 09:02:38 +0200 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87ish5jmup.fsf@mail.jurta.org> 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 1079421003 15538 80.91.224.253 (16 Mar 2004 07:10:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Mar 2004 07:10:03 +0000 (UTC) Cc: emacs-devel@gnu.org, karl@freefriends.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 16 08:09:56 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 1B38i4-0001dW-00 for ; Tue, 16 Mar 2004 08:09:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B38i4-0000de-00 for ; Tue, 16 Mar 2004 08:09:56 +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 1B38dp-00067Q-3l for emacs-devel@quimby.gnus.org; Tue, 16 Mar 2004 02:05:33 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B38cz-0005yP-PW for emacs-devel@gnu.org; Tue, 16 Mar 2004 02:04:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B38cS-0005pg-MX for emacs-devel@gnu.org; Tue, 16 Mar 2004 02:04:40 -0500 Original-Received: from [66.33.219.4] (helo=spork.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B38cR-0005oW-QU for emacs-devel@gnu.org; Tue, 16 Mar 2004 02:04:07 -0500 Original-Received: from mail.jurta.org (80-235-32-155-dsl.mus.estpak.ee [80.235.32.155]) by spork.dreamhost.com (Postfix) with ESMTP id 83CB011DDB9; Mon, 15 Mar 2004 23:03:56 -0800 (PST) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "15 Mar 2004 08:27:31 -0500") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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:20523 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20523 Stefan Monnier writes: >> 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. The Emacs Info browser can be compared to Web browsers where links can be opened in a new window/tab either by the New Window command (usually bound to C-n) with an initial content of the current page - this is very similar to Emacs's clone-buffer (M-n), or by pressing Ctrl key while clicking on a link - this is similar to Emacs's C-u prefix. But AFAIK none of Web browsers provide this functionality (pressing Ctrl key) for other commands (like Back, Forward, Home). Perhaps, clone-buffer (M-n) should be a primary method for forking a new Info buffer. It's as simple as using C-u prefix. >> 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. There are some references in Emacs manuals that refer to the middle of a big Info node but use neither anchors nor reference names. We should decide which is the preferred method of reference and change them for all such cases in Emacs manuals. -- Juri Linkov http://www.jurta.org/emacs/