lynx-dev tempfile gripes (was REUSE_TEMPFILES)

[Klaus Weide]

Let's make it clear please that these are different topics.

On Sat, 17 Jul 1999, Henry Nelson wrote:

> > Actually, my suggested change isn't good, it would still leave the
> > older versions hanging around...  (only until Lynx exits, I hope).
> [...]
> > being appended, but multiple files piling up.  (like what you
> 
> On single-user systems, not so bad maybe, but on limited-resource,
> multi-user systems, the leaving of all these files until Lynx exits
> can put a strain on the system.  

We were talking about a bug, a problem caused by a change that hasn't
settled down yet, for DOS.

You are now talking about something else:

> Might be worthwhile to simply erase
> the temp files Lynx creates when calling the Option Menu, Information
> Page, compile time options, etc, or not even create them in the first
> place.  The very systems which require _seconds_ to create these pages,
> are most likely to be the systems still in the MB era.  Any modern
> machine will create these pages within not even a flicker of the
> screen, and writing them to disk probably takes the most time.
>
> I hit the 'o' key, and I get:
> -rw-------   1 henry        8424 Jul 17 12:15 L2330-1TMP.html
> That file stays around until I either exit Lynx, or, of all
> things, I hit the 'o' key again, in which case I get
> -rw-------   1 henry        8424 Jul 17 12:31 L2330-7TMP.html
> I immediately hit 'u', and then 'o', and what do I have but:
> -rw-------   1 henry        8424 Jul 17 12:35 L2330-8TMP.html
> 
> IMO, these files should be erased as soon as Lynx moves off
> of the Option Menu, not wait to erase it just before creating
> the Option Menu again, or until exiting.

There are about three different ways used in the lynx code for
generating internal 'user-interface pages' (discussed a while ago
with Leonid).  One of them is creatign a temp file and then reading
it in using all the existing code for loading local files.

All those pages that are implemented as temp files share the same
basic mechanism.  There are advantages in treating such pages as,
more or less, just another local .html file.  One is that you
can leave the page 'forward', and later come 'back' to it with
a series of PREV_DOC or from the HISTORY list, and it will still
be there even if it was pushed out of the cache of rendered docs
by the intermediate browsing (and doesn't have to be regenerated).

This makes more sense for some pages than for others.  E.g. since
the HISTORY page is 'normally' not pushed on the history stack (as
we have just established in another thread), that advantage does
('normally') not apply for it.  It's different for e.g. LIST,
Visited Links.  Since the HISTORY code uses the same mechanism,
you still get the same behavior.

But the advantage *does* apply to the (forms) 'O'ptions page, at
least in some situations.  You can 'g'oto another page from there
as from any other page, and the "Options Menu" will then appear
in the history stack and can be returned to later.  If that seems
too obscure to deserve consideration, think of invoking HELP from
within the Options page, which has the same effect.


> BTW, this is exactly the logic I was questioning WRT the temp
> files left when uncompressing a file.  

A different case, temp files for a different purpose.  Therefore
it is not 'the same logic'.

> At the time I thought
> Klaus's solution was good, but then I asked myself "do you
> really want to put `rm` anywhere in .mailcap"?  I said no, and

Yes, you shouldn't use it in a general .mailcap shared between lynx
and other applications.  You can use it in VIEWERs used only by
lynx.

> have decided to continue to have Lynx erase files _it_ creates
> as soon as it is done with them 

It's your choice to use lynx patched as you like it...

> (so what if it pulls the rug
> out from under something working in the background  -- that
> something should not be using Lynx's personal files, unless
> Lynx specifically relenquishes all control, i.e., passes a copy
> to the other app).

'That something' doesn't know whether a file handed to it is Lynx's
'personal' file - unless you use only viewer commands that are
hand-crafted for lynx (and in that case, you might just as well put
the rm in there).  There's no protocol for handing over 'ownership' of
a file between lynx and an arbitrary shell command that can be
invoked, perhaps indirectly, as a viewer.


   Klaus