Re: general intuitiveness and user-friendliness of GNU Info [was Re: Bug#78504: info: Impossible to scroll just a single line]

[Eli Zaretskii]

On Tue, 12 Dec 2000, Josip Rodin wrote:

> > TAB is advertised in the help screen popped by `?', but I guess some 
> > people won't have the patience to read the first few lines...
> 
> But it's only on the second page of the help screen ;) Just kidding

Yes, the competition for the first places there is tough ;-)

> A quick inquiry among my fellow Debian developers showed that there's a bit
> of discontent with info.

Nothing new here.  Several past discussions, including here, clearly
show that at least some of the discontent is based on ignorance: there
are several nifty features in Info that many users don't know about.
I wonder how we should go about advertising them more, because I
really think they are extremely useful; I myself use those features
all the time.

> There's nothing as quickly accessible reference index in info docs, at least
> "apropos and man somehow makes it easier."

Here's one example of ignorance: didn't they hear about "info --apropos"?

> "I'd be happy with a little util to unfold my entire info tree into a
> serialized doc for egrepping."

Here's another example: don't they know about "info --subnodes"?  (I
don't recommend anyone to do "info --subnodes emacs | egrep", but if
they are sure they want that, they can have it right now.)

> (So searching through a whole hierarchy of info documents would be a useful
> addition.)

That would be "info --apropos", mentioned above.  Could be quite slow
if you have lost of Info docs installed, but it's there.

> "the fact that FSF has been killing man pages in favour of info should be
> treated as treasonous"

Suggest users who say this to try "info --usage": this is intended to
show what a typical man page displays.  If there are suggestions for
improving this feature, which is new in Texinfo 4.0, I'd be glad to
hear them.

> > We can have the cake and eat it, too: let's define a new set of key 
> > bindings, suitable for those who are used to those other applications.  
> > Can you, or someone else, come up with a suggestion for this set?  
> > infomap.c is a place to start, I think.
> 
> I'll see what I can do.

Thank you.

> Additinally, what's the purpose of "Subfile: foo.info-2.gz" in the mode
> line? It doesn't seem very useful to me...

Emacs emulation again, I presume.  We could turn it off by default and
have an option to turn it on again, if that will help.  But what would
we want to do with the real estate this frees on the mode line?

> > > Three ideas for the second point:
> > >   * the new window for footnotes shouldn't be created at all, or
> > >   * the top window shouldn't contain the footnotes
> > 
> > This is only relevant when the Info file was created with 
> > "--footnote-style=end".  Is this how Debian generates Info files?  The 
> > files I have on my system are mostly generated with the `separate' style,
> > which puts each footnote on a separate node.  Then they do not appear 
> > in the main window.
> 
> I haven't changed the .deb makeinfo in any way; I noticed this behaviour
> with "info grub overview".

Yes, by default the footnotes are put at the end of their nodes.  I
think we should change the default, but it couldn't be done in v4.0,
because the non-default style uses a feature (@anchor) which were
introduced with Texinfo 4.0 and which older Info readers didn't
support.  Perhaps in the next version.

Maybe you should consider using --footnote-style=separate when
packaging Debian, if all Info viewers you support know about @anchor.

> > > If necessary to scroll it, that should be possible. Somehow :)
> > 
> > Exactly.  I expect users to have grave difficulties discovering the M-C-v 
> > key.  I don't know what to do about that.
> 
> Indeed! Perhaps also bind it to Ctrl+Tab or something like that?

Something to take care of in the additional set of key bindings,
perhaps?  How do other text-mode browsers handle scrolling the other
window in the split-window configuration?

> > > > > When you press ? for help the bottom window doesn't disappear.
> > > > 
> > > > Why should it?
> > > 
> > > Because the footnote is off-topic, you want to read the help screen now 
> > > that
> > > you pressed ?.
> > 
> > How do we know that the user wants help for the main window, not for the 
> > footnote?
> 
> Is the help screen for footnotes different from the one for the main window?

No, it's exactly the same.  But that's not what I meant.

What I meant to point out is that, when a user presses `?', she
probably wants to find something that pertains to what she currently
reads, and so what she reads should be still displayed for the user to
consult while she reads the help (switching between buffers is another
task that is not natural for anyone but Emacs users).  Since we don't
know whether the user reads the main text or the footnote, we don't
know which window to leave displayed and which one to close.