Re: lynx-dev LYNX: need for "re-try to get it"

[Foteos Macrides]

Laura Eaves <address@hidden> wrote:
>> From: Bela Lubkin <address@hidden>
>> Date: Fri, 8 May 1998 04:31:32 -0700
>>...
>> David Combs wrote:
>> > Often when I type in eg "12" (numbered links) to go somewhere,
>> > it just waits -- or maybe comes back failing to find it,
>> > eg that all ports are taken.
>> > 
>> > In either case, it speeds up things, it turns out, for me
>> > to "z" it, and try again, which often works, right quick.
>> > 
>> > Now, if I am "at" that link, it's easy to re-try it; I
>> > just hit <return> or L, and I'm off.
>> > 
>> > However, when I have typed in a number, eg 12, I have to
>> > remember what number I typed in, and do it again.
>> > 
>> > Now, if I hit the up-arrow (not caret) key over to the
>> > right of the keyboard, and do it after a "g", it
>> > spits-out the last TYPED-IN (or on cmd line) address.
>> > 
>> > Maybe it would be nice if that "12", or at least the
>> > addr it mapped to, was pushed onto that stack too?
> > Then IT would be there when I hit that up-arrow.
>> > 
>> > ----
>> > 
>> > Or maybe there is already a key-cmd to re-try the prior thing,
>> > and I just don't know about it?
>>
>> What if 12<Return> did:
>>
>>   - follow link 12
>>   - remember that you were on link 12
>>
>> i.e. as if you had typed 12g<Return>12<Return>?
>>
>> I think this could be done by adding a:
>>
>>                 curdoc.link = newdoc.link;
>>
>> into the code for DO_LINK_STUFF in LYMainLoop.c.  But I haven't tried
>> it.
>>...
>
>Actaully it's a little more difficult than that -- mods in mainloop and getfile
>-- to treat 12<return> as 12g<return><return>
>There was discussion on this last year --  I believe the
>consensus was to keep the old semantics of "12" for several reasons:
>       1. If a link is invisible (no text in the anchor) so that
>       you can't select the link using the arrow keys, you could
>       still select it by typing its number.
>       2. 123g was hard to implement.
>Since Klaus and Fote managed to implement 123g, however, and since
>invisible links are no longer numbered in 2.7.2 and 2.8, (but are accessible
>from the list page), can anyone thiank of another reason besides backward
>compatibility to keep the old semantics?
>--le
>
>PS: Actually now that I look at the options, Klaus did implement
>a -hiddenlinks=option switch that allows hidden links to be numbered
>as before.  The 3 options are merge, listonly, ignore.
>So #1 above is still an issue in 2.8.

        The code set that was released as v2.7.2 considered that consensus
misguided and didn't go along with it (it was just my personal code set,
not intended to become an "official release").  My logic was that entering
a number for a link should be equivalent to navigating to it and activating
it, and the failure to make it current is a bug in the "oops, I forgot to
do that" category, which could be easily fixed.  Note that I'm fixated on that
logic, and when I use the mouse support in the W32 binary to activate a link,
similarly find it frustrating that the link isn't being made current for that
page in conjunction with the activation.

        You're correct that it would be tricky at this point to revive that
logic in v2.8.  Even if you don't set the option to number blank links, for
the List menu it is set temporarily, and so you'd have to change that logic
as well.

                                Fote
-- 
Foteos Macrides