Re: feature request for stand-alone info

[Gavin Smith]

On Fri, May 12, 2017 at 01:52:25PM +0200, Benno Schulenberg wrote:
> 
> Hi,
> 
> As 'info' is a document reader, I kind of expect it to behave
> like 'less': when I type the arrow keys, the text scrolls.
> 
> So I would like to request a setting, 'movement-always-scrolls',
> that makes 'info' behave for forward movements as if the cursor
> is on the last line of the screen, and for backwards movements
> as if the cursor is on the top line of the screen, no matter where
> the cursor actually is, while keeping the cursor in the exact same
> spot on the screen (when line length allows it).

Please, no more scrolling settings. There are too many already and
they interact in ways that are hard to remember.

I looked for some combination of existing settings that would
achieve this. Unfortunately, I don't think there is one.

I thought the 'scroll-behaviour' variable would achieve this, but that
variable doesn't seem to be used for the 'up-line' and 'down-line'
commands which scroll by single lines.

This would be easy to change, but there is also the mouse wheel 
scrolling which is also confined to a single node.

There is the 'cursor-movement-scrolls' variable which links the
setting of 'scroll-behaviour' to the cursor movement commands. (Badly 
named as cursor movement can always scroll within a single node.)
Maybe another variable could link this setting to 'up-line' and 
'down-line'? ('all-scrolling-scrolls' or 'up-and-down-line-really-scroll'
- I can't think of a good name right now).

Another idea: add commands which are just like 'up-line' and 'down-line' 
which are affected by the value of 'scroll-behaviour'.  
('up-line-scrolling' and 'down-line-scrolling'?) Users could use these
in .infokey as they wish.

That would give the ability to scroll up and down by one line and by 
screen-fulls and move between nodes in doing so, but perhaps this is
not general enough, because it wouldn't allow anything in between (for 
example, to scroll up and down by 4 lines at a time.) So maybe we
should link this in with the 'scroll-forward-page-only-set-window'
and 'scroll-backward-page-only-set-window' commands.  We could add
a variable like 'starting-window-size' (it's not the window size, but
the word "window" appeared in the name of these scrolling commands
for some reason) so that setting starting-window-size=4 in .infokey
would have the same effect as running

C-u 4 M-x scroll-forward-page-only-set-window

after starting Info. Maybe it could be called 'scrolling-window' 
instead, and the value of this variable would be updated every time a
'scroll-forward-page-only-set-window' or 
'scroll-backward-page-only-set-window' command was given. Then you
would get the behaviour you want by setting 'scrolling-window' to 1
and binding Up and Down to 'scroll-backward' and 'scroll-forward',
and eschewing 'up-line' and 'down-line'.  The problem with _this_ is 
that there would then be no commands to scroll up and down by an entire
screen-full. Do we then add extra commands 'scroll-forward-page'
and 'scroll-backward-page' that always scroll by an entire screen-full?
Or do we have _two_ variables giving scrolling steps, one for large, 
screen-sized steps, and one for smallish steps? (Note that the
'scroll-step' variable does something different: that controls the 
amount of scrolling when a cursor movement command moves the cursor 
outside of the displayed part of a node.)

If we do add more variables and/or commands to customize scrolling and 
cursor movement, let's get them right so we don't have to add even more 
in the future.

In my opinion, the ability in Info to move the cursor independently
of scrolling the node is unnecessary and confusing. When a user tries
typing Down at the start of a node and the cursor moves down one line,
that is fairly useless: they probably wanted either to scroll the node
or to move to the next link. I expect that it is too late to change 
this, however.