Re: info invisible changes

["Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu>]

> 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