[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: info invisible changes
From: |
Stefan Monnier |
Subject: |
Re: info invisible changes |
Date: |
Wed, 06 Nov 2002 10:11:41 -0500 |
> Hmmm, well it looks _less_ bad: now the text is all in a properly-
> indented, but absurdly narrow column.
>
> 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.
It's also special because it tends to itself not be properly
aligned/filled because each entry can come from a different dir
file (and also from different .texi files (via their .info
and install-info)) so the alignment of text is often strange.
to start with, unless all the dir files have been manually
edited.
In most other menus, the entries are of the form '* blabla::' and
there is thus nothing to hide, really.
> Morever, the format of the menu entries seems regular enough that
> finding the bounds required to fill/reindent; something like
>
> (goto-char START-OF-MENU-ENTRY-TEXT)
> (forward-sentence)
> (while (looking-at ".*\n[ \t]+[^ \t]")
> (forward-sentence))
> ;; point is now at END-OF-MENU-ENTRY-TEXT
I'd use (re-search-forward "^[^ \t]"). I believe that's what I use
in Info-remove-duplicates.
> BTW, on the issue of whether it's OK to modify the buffer contents, I think
> it should be OK; (buffer-file-name) is always nil in the *info* buffer, after
It now indeed is nil. It used to be the case that it sometimes was
nil sometimes not.
> all. I think a lot of this stuff would become _much_ simpler if you could
> must munge the buffer instead of using invisible/display properties (with all
> their associated oddities), perhaps using text properties to store the
> necessary non-displayed info instead of parsing the buffer for it -- of
> course this would perhaps be a bigger change, since you'd have to modify the
> various info-getting functions too, but I don't see why it would be _that_
> big a job (presumably the modified code would support both text-property
> stored info and buffer-parsing, for backward compatibility).
I disagree. Especially since it's all customizable, it's easier and
safer to keep only one buffer-format and change the appearance
via properties.
Stefan
- info invisible changes, Miles Bader, 2002/11/01
- Message not available
- Re: info invisible changes, Miles Bader, 2002/11/04
- Re: info invisible changes, Kim F. Storm, 2002/11/05
- Re: info invisible changes, Miles Bader, 2002/11/06
- Re: info invisible changes, Kim F. Storm, 2002/11/06
- Re: info invisible changes, Miles Bader, 2002/11/06
- Re: info invisible changes,
Stefan Monnier <=
- Re: info invisible changes, Miles Bader, 2002/11/06
- Re: info invisible changes, Richard Stallman, 2002/11/07
- Re: info invisible changes, Kim F. Storm, 2002/11/12
- Re: info invisible changes, Miles Bader, 2002/11/12
- Re: info invisible changes, Kim F. Storm, 2002/11/12
- Re: info invisible changes, Robert J. Chassell, 2002/11/12
- Re: info invisible changes, Kim F. Storm, 2002/11/13
- Re: info invisible changes, Robert J. Chassell, 2002/11/13
- Re: info invisible changes, Richard Stallman, 2002/11/14
- Re: info invisible changes, Kim F. Storm, 2002/11/14