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: Info enhancements (was: Re: HTML as info format) Date: Tue, 02 Dec 2003 12:18:09 +0200 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87r7znmske.fsf_-_@mail.jurta.org> References: <200310280126.h9S1Q9N16202@f7.net> <20031028105102.GA7330@dirtyweb.penguinpowered.com> <20031030104238.GA11503@dirtyweb.penguinpowered.com> <87vfps2x9r.fsf@ID-87814.user.dfncis.de> <878ymfdsx9.fsf@mail.jurta.org> <87smk4zuvv.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 1070366942 30774 80.91.224.253 (2 Dec 2003 12:09:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2003 12:09:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Dec 02 13:08:53 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AR9Km-0004By-00 for ; Tue, 02 Dec 2003 13:08:52 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AR9Kl-0004kz-01 for ; Tue, 02 Dec 2003 13:08:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AR9yI-00015F-9r for emacs-devel@quimby.gnus.org; Tue, 02 Dec 2003 07:49:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AR8dy-0003ax-Gx for emacs-devel@gnu.org; Tue, 02 Dec 2003 06:24:38 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AR8dN-0003VX-QV for emacs-devel@gnu.org; Tue, 02 Dec 2003 06:24:33 -0500 Original-Received: from [64.246.52.22] (helo=ns5.tangramltd.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AR8dF-0003Uj-CW for emacs-devel@gnu.org; Tue, 02 Dec 2003 06:23:53 -0500 Original-Received: from 80-235-33-206-dsl.mus.estpak.ee ([80.235.33.206] helo=mail.jurta.org) by ns5.tangramltd.com with esmtp (Exim 4.20) id 1AR7fh-0003Db-1V; Tue, 02 Dec 2003 12:22:21 +0200 Original-To: Eli Zaretskii In-reply-to: <87smk4zuvv.fsf@mail.jurta.org> (message from Juri Linkov on Mon, 01 Dec 2003 12:38:15 +0200) User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns5.tangramltd.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jurta.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:18273 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18273 Eli Zaretskii writes: > [I have no idea why mailman sent me this message from 2 weeks ago.] >> From: Juri Linkov >> Date: Mon, 17 Nov 2003 15:29:54 +0200 >> >> Current Info format can't make a link to another part of the same >> Info node. > > I think you miss the @anchor directive, introduced in Texinfo 4.x. > >> The same problem appears in the Glossary node of the Emacs manual, >> where links to the same node are marked by the "(q.v.)". > > Arguably, we could modify the Glossary by using anchors in the online > formats. Yes, using anchors might be a more clean solution, but it has one drawback: it will generate too many excessive references in the tag table for its Info file. And these references will be mixed up with node names, e.g. in the completion list of `Info-goto-node'. Maybe this is not too bad to jump directly to the glossary term definition by `Info-goto-node', but seems that its disadvantages outweigh a little convenience it provides. I solved this problem by using reference names for finding correct position within an Info node by calling the function `Info-find-index-name' with reference name after selecting an Info node. For example, instead of the text "is shared by an indirect buffer (q.v.@:)" the text "is shared by an @ref{Glossary,indirect buffer}" could be used. But I just noticed one problem with using it in the Glossary node. If some glossary term coincides with the node name then Info jumps to this node instead of finding a term in the some Glossary node. It's because the function `Info-follow-reference' always selects the first occurrence of the "*Note:" text within one Info node. For example, if Glossary node has two following references: *Note Input Methods::. *Note input method: Glossary. it will always jump to the first reference even if point was on second before calling the `Info-follow-reference' function. I hope this should be fixed somehow in this function. >> There are other problems with the current Info format. For example, >> currently there is no way to hide the address part of the link without >> corrupting the paragraph formatting. > > IMHO, the current way to hide the address of the link is still > experimental and needs further work. I already fixed some its deficiencies, so now it looks quite good. It don't cause too long lines, but still don't fix too short lines. But I think too short lines is not a big problem. Long lines were much worse, because they became partially invisible when truncated. >> After hiding the address part of >> the link lines become either too short or too long. For example, lines: >> >> See *Note Customizing Indentation: (ccmode)Customizing Indentation, for >> more information on customizing indentation for C and related modes, >> >> in Info the first line becomes too short: >> >> See Customizing Indentation for >> more information on customizing indentation for C and related modes, > > Doing this in some other way, like physically erasing the text we now > hide and then re-filling the paragraph, would solve this. In any > case, this problem is not relevant to Info format per se, it is due to > the way the Emacs Info reader renders an Info document. The proper refilling in the Emacs Info reader is impossible because Info file format loses some information about formatting presented in a source Texinfo file, like @*, @w{...}, etc. -- http://www.jurta.org/emacs/