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

[Leonid Pauzner]

18-Oct-99 15:24 Klaus Weide wrote:

> I haven't tries it so far (just looked through your diff).

>> One problem found: this page should be updated every time, even when we
>> choose it from the history page. Unfortunately, anchor->no_cache isn't 
>> enough.
>> Currently worked out in getfile()...
>> Klaus, please look for proper no_cache solution -
>> try to follow LYNXMESSAGES:/ link from the history page,
>> 'd'ownload it, etc.

> 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.
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.

> The fact that there is no obvious way for it probably means it isn't
> such a good idea...

Yes, rules in LoadDocument() for getting a decision on using of existing HText
seems suboptimal in this case.

> 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: 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).

On the contrast, VLINKS have no repetitive URLs.

> (The VLINKS page is different: following links from there acts just like
> a normal forward link.  LYNXMESSAGES: should probably be reachable from
> the VLINKS page now, I see no reason why it shouldn't.  As well is being
> bookmarkable if one chooses so.)

> Note that "always updated" would also apply when you come back to the
> page with Left Arrow.  It even applies when you are on the LYNXMESSAGES:
^^^^^^^^^^^^^^^^^^^^^
and this will contradict lynx principles, you right.
> page, and type 'G'oto + invalid URL from there (not a http: URL which
> returns an error response).  It even applies if you 'P'rint from the
> LYNXMESSAGES: page (say you want to mail the messages to someone), when
> you come back to the LYNXMESSAGES: it will be different from what you
> just printed (if something you did from the 'P'rint Menu caused a
> statusline message that gets tracked).  I would find these effects
> more confusing than helpful.
> (As I said, I haven't tested it, but the behavior described would occur
> as far as I can see.)
> And a RELOAD ob the LYNXMESSAGES: page should work now as expected
> if one wants to force that (it doesn't with the current tempfile
> solution).

> 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.
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.

> The pages recognized in LYwouldPush() so far all all of the "file:"
> type, but that doesn't mean it has to stay that way.  In this case,
> just checking strncmp(docurl,"LYNXMESSAGES:",11) should be enough.
> (Don't check the title at all, it's not necessary - it's just a
> crutch that can fail in some charset situations, no need to introduce
> that possibility.)

> Doesn't this approach make more sense?
> If you disagree and really want special _always_-the-latest behavior
> I won't insist that it's wrong, but I feel it is inconsistent with
> other UI pages' behavior.  It reminds a bit of Web page authors that
> feel _their_ pages are so importan that they never must be cached... :)

> 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.

>    Klaus

Thank you for you analysis.