From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: info invisible changes Date: 12 Nov 2002 11:11:30 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xfzu79jxp.fsf@kfs2.cua.dk> References: <200211011623.gA1GNAL03601@rum.cs.yale.edu> <5xznsnvabl.fsf@kfs2.cua.dk> <200211061511.gA6FBfL02691@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037200737 18265 80.91.224.249 (13 Nov 2002 15:18:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 15:18:57 +0000 (UTC) Cc: monnier+gnu/emacs/pretest@rum.cs.yale.edu, miles@lsi.nec.co.jp, storm@cua.dk, monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org, emacs-pretest-bug@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 18BzCX-000472-00 for ; Wed, 13 Nov 2002 16:13:09 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18BzOU-00066k-00 for ; Wed, 13 Nov 2002 16:25:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BXFW-000282-00; Tue, 12 Nov 2002 04:22:22 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BX5A-00041B-00 for emacs-devel@gnu.org; Tue, 12 Nov 2002 04:11:40 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BX58-0003zm-00 for emacs-devel@gnu.org; Tue, 12 Nov 2002 04:11:39 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BX58-0003zV-00; Tue, 12 Nov 2002 04:11:38 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 78F827C017; Tue, 12 Nov 2002 09:11:36 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9314 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9314 Richard Stallman writes: > > I agree with Stefan that the text should be refilled in the top-level > > dir node -- it's special because it contains much more hidden text than > > a normal node, and looks especially bad without refilling, and also it's > > not connected with a file (it's generated), so it's safe to modify. > > There is no reason to hesitate about refilling the dir node. It is > constructed inside Emacs anyway. Actually, the *info* buffer is now detached from the original info file (it uses insert-file to setup the buffer), so we can modify the *info* quite freely. In any case, with the current implementation in info.el, I simply tried to apply fill-paragraph to the sections of the *info* buffer where I mangle the *note references ... and although it actually does a fair job most of the time, it sometimes fails horribly because the code in fill.el suffers from a number of serious problems: 1) it doesn't test for 'invisible properties, so it happily processes invisible text when deciding the (visible) width of the lines, 2) it doesn't test for 'display properties, so if a part of the buffer text is hidden and visibly replaced with some other text (or an image), the hidden (rather than the visible) text is used for filling, and 3) when the fill code inserts a newline to wrap the text, it may insert that newline in an invisible part of the buffer, so it has no visible effect (i.e. displaying one very long line rather than two normal width lines). Is someone working on fixing fill.el to deal with these text properties? If not, should the code in fill.el be modified in general to deal with these properties, or can it be done by adding another type of filling specifically for this type of mangled text? Please advise! I think that if we fix those problems, a simple call to fill-paragraph at the right place in Info-fontify-node will do a reasonble job of presenting the mangled information in a more readable form. ++kfs