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

[Eli Zaretskii]

On Mon, 11 Dec 2000, Josip Rodin wrote:

> > If so, PageDown should work, doesn't it?
> > In any case, I'd expect users to use PageDown and PageUp, not cursor
> > motion, for scrolling, if they are unhappy about SPC.
> 
> But that's what _you_ expect. :) To some users it seems perfectly obvious to
> first try the Down arrow key for scrolling.

Strange, I would expect them to use PageDown and PageUp, not the arrows.  
Arrows typically move by lines, not by pages.

> > > You have to use the left and right arrow keys up to 80 times to
> > > get to a link (and then back to the bottom of the page to scroll). (No,
> > > <tab> isn't very obvious, nor are ^A or ^E.)
> > 
> > I thought TAB and BackTAB were widely used in all GUI programs to step
> > through all the ``interesting spots'', such as fields in a dialog.
> > 
> > What would you suggest as a more obvious way of getting to a link?
> 
> There are two ways: either make {Up,Down} arrow keys to scroll between
> links, like they do in all the console web browsers (and pinfo), or get <TAB>
> more advertised.

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...

> The first idea probably requires lots of work

Actually, it's very easy to change the key binding of the arrow (see 
infomap.c), but I'm afraid some users out there will want the old 
behavior.

> and the
> second idea depends on the /usr/info/dir file somewhat, because it's the
> thing people see on first entry.

The Texinfo distribution cannot have any real influence on what DIR files 
look like on end-user systems.  In addition, I'd expect users to run Info 
like this:
                info emacs

in which case they don't even see the DIR node.

I think the only resonable way to advertise important commands is to 
usurp a couple of screen lines near the bottom and display the commands 
there at all times.

Would that be a good idea?  Can you poll your users?

> > Info is modeled after Emacs, as far as key bindings are concerned.  If
> > we want it to behave radically different, we will probably need a set
> > of entirely different key bindings, activated by a command-line
> > switch, like --vi-keys does.
> 
> Which brings up the question -- why does it have to be modelled after Emacs
> in that aspect?

Because Emacs's Info reader was the first one written; the stand-alone 
version came later, and thus was written to emulate Emacs.

> Emacs users ought to be better off using the info mode

There are people who have the stand-alone Info running on their desktop 
at all times, even though Emacs is also running.  The reason is that
(a) they don't need to switch buffers/frames to read the docs while 
editing, and (b) the stand-alone reader has some nifty features, e.g. 
TAB-completion in index searches, that Emacs doesn't have.

> it would seem better to adjust the info keybindings to be (remotely) similar
> to the keybindings of other CLI applications.

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.

> > > The top status line can span lines which looks somewhat confusing. The
> > > footnotes are displayed both in the bottom window and at the end of the
> > > page in the top window. It's especially hard to read anything in the top
> > > window when the bottom window (with the footnotes) takes three quarters
> > > of the screen.
> > 
> > I'm not sure I understand what do you suggest as a remedy for these
> > problems.
> 
> The top status line should strip off extra characters (perhaps replacing
> "some long thing here" with "some long...") that could get expanded by
> pressing some key or just moving the pointer onto the line.

I don't like invisible parts of displayed text which magically appear and 
disappear.  Users won't have a clue that they need to move cursor there 
in order to see the missing parts.

Hmm... what exactly do we want to fix here?  Do we want to prevent 
line-wrap?  If so, perhaps removing the current file name and node name
from the header line is a better idea?  After all, they are already 
written in 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.

> The bottom footnotes window should never be larger than the top window.

This is easy to arrange.  However...

> 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.

> > > 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?