Re: info-mode needs history navigation.

[Kevin A. Burton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eli Zaretskii <address@hidden> writes:

> On 3 Nov 2001, Kevin A. Burton wrote:
> 
> > 1. remove Info-last and create two new functions and bindings including
> >    Info-history-forwards and Info-history-backwards
> > 
> >     - PROS: elegant and straight forward.
> > 
> >     - CONS: breaks backwards compatibility and requires users to learn new 
> > key
> >       bindings.
> > 
> > 2. Keep Info-last and write a new function which handles forward 
> > navigation.  I
> >    don't know what to call this new function (any suggestions?).
> > 
> >     - PROS: keeps backwards compatibility, preserves key bindings.
> > 
> >     - CONS: leaves us in an ackward position because the alternative nav
> >       function (Info-first) is little confusing.
> > 
> > 3. Keep Info-last but this will be an alias for Info-history-backwards and
> >    pursue case 1.
> > 
> >     - PROS: elegant and straight forward.  Keeps backwards compatibility,
> >       preserves key bindings.
> > 
> >     - CONS: ???
> > 
> > I think this pretty much sums it up... I would prefer ot implement use case
> > 3...
> 
> I'm afraid I don't really see the big difference. ;-)
> i
> The real issue is this: Info currently maintains the visited places in
> stack-like fashion.  So if you press `l', the last place is popped off the
> stack, and is thereafter gone.  So you cannot implement Info-history-forward;
> you need to change the way visited places are stored.

Yes... I know.  Info-last would either be removed or rewritten.

We can't live with the stack being damaged.

> When this is done, it doesn't make any sense to keep the old stack-based
> approach and the new one.  We simply rebind `l' to the new command, and be
> done with that.  Voila--users don't need to learn anything new, if they don't
> want to: `l' works as before; while those who do want a new feature will use
> the new Info-history-forward command.
> 
> Am I missing something?

I think so... did you read my proposal?  I think I just said everything *you*
said and put it into case 3.

So we are in agreement that case 3 is the solution.

Kevin

- -- 
Kevin A. Burton ( address@hidden, address@hidden, address@hidden )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - address@hidden,  Web - http://relativity.yi.org/

The gears of the digital revolution are turning faster than the wheels of
justice.  -- Andrew Pollack
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE75aisAwM6xb2dfE0RAjRlAJ9QZGiyGvnJtIOQRmrgP7N4SRggDwCgz/iJ
2poxnBb67owAqOhBGX1zDvY=
=CGym
-----END PGP SIGNATURE-----