Re: lynx-dev Re: [patch] LYNXMESSAGES:/ without temp-files

[Klaus Weide]

On Tue, 19 Oct 1999, Leonid Pauzner wrote:

> 18-Oct-99 15:24 Klaus Weide wrote:
> > I have to ask, why?  I think nothing special should be done in this
> > respect, other than what anchor->no_cache already does.
> 
> In fact, anchor->no_cache = TRUE have no effect so far: when I visit
> LYNXMESSAGES:/ next time I saw the old output unless I press ^R to reload.

Hmm, I would have to gdb it to see why that happens.  From looking
at the code, it seems it *should* work as you did it.

> This somehow different from LYNXKEYMAP:/ or LYNXCOOKIES:/ because the latters
> have a hot key and called from the mainloop() where LYforce_no_cache is set.
> LINXMESSAGES:/ tracked in getfile() so LYforce_no_cache/LYoverride_no_cache
> should be set there for automatical update.

> > I don't agree that the "page should be updated every time, even when we
> > choose it from the history page".  That's just the idea of the history
> > page, to give you back the version that you last looked at (if it is still
> > there), not the most up-to-date version.  I think there should be as little
> > exceptions from this as possible...

> I mean the case where several entries of LYNXMESSAGES: happens to be in the
> history stack: 

My idea was to prevent that from 'normally' happening; I think that would
be more in line with other generated pages, and though it would be enough
(together with anchor->no_cache) to prevent stale statusline pages
in normal cases.

> there is a single HText for a single URL
> (I saw the most recent copy when I follow such link,
> but got a NULL file when I occasionaly 'd'ownload
> an earlier link from the history page - that was a surprize for me).

I don't understand what situation you are describing - was that with
the "statusline messages" page or other pages?  If the former, was it
with the old or with the new code (or an intermediate test version)?
What do you mean by "NULL file"?  (I would also set SOURCE_CACHE off
to make sure that doesn't interfere - it probably doesn't, but just in
case...)

> > What the code does for other similar pages: prevent that they get
> > pushed on the history list "unless forced", by returning FALSE from
> > LYwouldPush().  I think that would be the most straightforward way,
> > with no LYforce_*/LYoverride_* in getfile.
> 
> And if you start playing with LYwouldPush() you exclude such pages
> from the history stack so you could not return to it with left arrow
> nor 'd'onload that page if you deside to do that.

True...
But, for the "statusline messages" page:
- there are no links from it, so there are fewer situations where
  one would expect to return to the page;
- one reaches the "statusline messages" page normally *from* the
  History Page, so there already (and always) is a link for 'd'ownload
  right at the top.

> One certain problem with menu pages currently under LYwouldPush()
> was found when one person introduce a context help from most of
> internal pages: we could not return back to the internal page
> after visiting help - not a nice thing.

A more general solution for this problem would be to used the 'force_push'
flag in situations where that is wanted.   Unfortunately it is currently
LYMainLoop.c that is responsible for LYpush-ing, so it would have to
look at the link's URL in order to decide.

Also LYMainLoop.c could set ForcePush in more cases of key commands -
I am thinking of KEYMAP, INFO, HELP, HISTORY itself - if we decide that
that gives better behavior.

But it's a general problem that "should be looked into"; not every
kind of special URL should have to have special code scattered all over
the place just to get specific updating behavior...

> > I wouldn't take LYNXKEYMAP: as the UI page to exactly copy here, I think
> > that one really does have some special requirements (always try to show
> > the key mappings in place NOW).  Similarly LYNXCOOKIE: needs special
> > treatment, since actions can be performed on the Cookie Jar page that
> > _should_ be reflected immediately (without returning to a previous
> > page).
> 
> Perhaps these two pages were excluded from VLINKS page because
> they will not be updated if follow as URL, not a hot key.

Maybe also for the general idea that VLINKS shouldn't be cluttered by
internal pages (Henry's point).

The LYNXKEYMAP: page does get regenerated, but does depend on
prev_lynx_edit_mode to generate the right output, and prev_lynx_edit_mode
only gets set right by the LYK_KEYMAP code in LYMainLoop.c.

The LYNXCOOKIE: url type is not justt used for loading the Cookie Jar
page itself, but also for triggering actions *from* that page, so
it's really a special kind of thing (comparable to <LYNXCFG://reload/>
in effect but not in implementation).

   Klaus