unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
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
Subject: Re: info invisible changes
Date: 12 Nov 2002 11:11:30 +0100	[thread overview]
Message-ID: <5xfzu79jxp.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <E189oGu-0007su-00@fencepost.gnu.org>

Richard Stallman <rms@gnu.org> 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

  reply	other threads:[~2002-11-12 10:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-01  8:04 info invisible changes Miles Bader
     [not found] ` <200211011623.gA1GNAL03601@rum.cs.yale.edu>
2002-11-05  4:08   ` Miles Bader
2002-11-05 18:49     ` Stefan Monnier
2002-11-07  4:49       ` Richard Stallman
2002-11-05 23:57     ` Kim F. Storm
2002-11-06  9:51       ` Miles Bader
2002-11-06 12:46         ` Kim F. Storm
2002-11-06 12:30           ` Miles Bader
2002-11-06 15:11         ` Stefan Monnier
2002-11-06 16:32           ` Miles Bader
2002-11-07 15:08           ` Richard Stallman
2002-11-12 10:11             ` Kim F. Storm [this message]
2002-11-12  9:22               ` Miles Bader
2002-11-12 10:59                 ` Kim F. Storm
2002-11-12 17:28                   ` Robert J. Chassell
2002-11-13 14:37                     ` Kim F. Storm
2002-11-13 18:20                       ` Robert J. Chassell
2002-11-14 12:17                         ` Richard Stallman
2002-11-14 21:38                           ` Kim F. Storm
2002-11-12 18:49               ` Stefan Monnier
2002-11-13 23:31                 ` Kim F. Storm
2002-11-14  0:39                 ` Kim F. Storm
2002-11-14  4:09               ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2002-11-14 13:57 Karl Berry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5xfzu79jxp.fsf@kfs2.cua.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=miles@lsi.nec.co.jp \
    --cc=monnier+gnu/emacs/pretest@rum.cs.yale.edu \
    --cc=monnier+gnu/emacs@rum.cs.yale.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).