Re: LYNX-DEV numbered linx: 2 suggestions

[Philip Webb]

970111 Foteos Macrides wrote:
>Laura Eaves <address@hidden> wrote:
>>I haven't heard a reply to my suggestion that typing a link number
>>should take you to the given link but not enter it.  Then if forms
>>and buttons are numbered, the behavior wouldn't have to be special cased.
>
>Your suggestion is contrary to the logic of the current Lynx API,
-- according to Hill's index of acronyms ( www.hill.com/acronyms ),
   API = Application Programming Interface :
   is that what you meant? & what is its relevance here?
>and meaning of a back command.
-- surely entering a link number is a FORWARD command.
>Lynx keeps track of the HText line number
>positioned at the top of the currently displayed page,
-- don't you mean:  the HText line number of the line positioned ... ?
                                          ^^^^^^^^^^^
   there is no line number at the top of the displayed page.
>and the display_page() function orders hypertext links and form fields
>*within* the displayed page, relative to that line.
>The HYpertext links and form fields associated with
>HText structures are kept in separate structures,
>and coordinated independently in conjunction with individual page displays.
-- this seems to say: the stored rendered text contains a marker of some kind
   to mark the beginning of each line as rendered; the s.r.t. does NOT contain
   the links & form fields, which are stored in two (separate) structures;
    display_page  is a function which gets the s.r.t starting at the top line
   & inserts at (presumably marked) places the appropriate links & fields,
   which it gets from the 2 structures.
   this makes sense as programming: have i got it right?
>When you enter a back command, that means retrieve the HText structure
>for the previous document,
         ^^^^^^^^^^^^^^^^^
-- ms eaves is referring to the SAME document, higher up or lower down,
   possibly on another page-display.
>construct a page display beginning at that saved line number,
>and position the cursor on the saved *relative* link number or form field
>within that display.
-- as things stand, if a new page-display in the same document is called up,
   the cursor [?? surely  hi-lite ] is positioned on the 1st link on the page;
   for ms eaves' proposal, the program would have to know that the page had
   been called up by a number command & react by positioning the hi-lite
   on the numbered link in question.
>If you left that document by entering an *absolute* link number,
>that's equivalent to having left by entering a 'g'oto URL or 'j'ump shortcut.
-- that's a different proposal: coming back after using a numbered link,
   rather than moving the hi-lite to a numbered link in the same document.
>Lynx has no way to relate it back to its page-display procedures,
          ^^^^^^
-- when Lynx returns after visiting (with right-arrow) a hi-lited link,
   it knows which link to restore the hi-lite to: surely all it would need
   would be to change the stored value of the hi-lited link
   (on the displayed page) to the link whose number was given.
   yup, i DO see a problem if the numbered link used is OFF the displayed page,
   when Lynx would need to know which page to display,
   and couldn't obtain that info from the structure containing the links.
>nor does it have a way to treat hypertext links and form fields
>as a single ordinal continuum.
-- SO how big a job would it be to reform the 2 structures
   containing the links & fields to relate them to the page-start markers
   in the stored rendered text (if i'm picturing the program correctly)?
>It's another one of those cases in which what users imagine Lynx is doing
>while using Lynx in fact is not as all what Lynx is doing.  Sorry...
-- (friendly smile) it really isn't enough to keep telling us
   that we are picturing things wrongly WITHOUT explaining more carefully
   what Lynx actually does do: i've tried to reconstruct that above.
   eg what are the names of the source files & structures in question?
   some people might start to learn a bit more about how Lynx is written
   & then be able to share the programming burden a bit more widely.
   
970112 Foteos Macrides wrote:
>Laura Eaves <address@hidden> wrote:
>>I know lynx doesn't change the current link or page info when you type
>>a link number.  From what you say, it's implemented like a goto.
>
>Yes.  When you enter a number, n, it starts scanning the hypertext
>anchors structure pointed to by the currently displayed HText structure,
>and then uses the nth anchor's address equivalently to an address
>you might have entered as a 'g'oto.
-- now we can start to see why Lynx is so FAST!
>I thought the point of treating that as a paging command
>(draw a new page with that link in it) instead of an activation was
>because you imagined that hypertext links and form fields could be handled
>as a single, ordinal array of numbers.
-- it was mr rosmaita who asked for form fields to be added to the numbering,
   which is a 3rd proposal, and it does look from outside that one could
   simply list more numbers: i would have assumed so before reading the above.
>That, and modifying the API to support
>a one, ordinally numbered hypertext link or form field per line feature,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- (pained face) : no, on 2nd thoughts i can't even guess what you mean.
>would be a *major* undertaking, better put off until after a v2.7 release.
-- is it merely history or is there a sound programming reason
   why the links & form fields are stored in separate structures?
   how much would it upset things to add an element (variable?)
   to the structure to record which page the links or fields occur on?
   besides strengthening the usefulness of the numbered-links feature,
   it might help allow Lynx to "goto page n" on request, matching intuition.
-- judging from postings on this thread, this is a piece of Lynx
   which merits some serious attention from code-writers,
   after, if not before, 2-7 is achieved (friendly smile).
-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;