Re: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes)

[Vlad Harchev]

On Sat, 17 Apr 1999, Leonid Pauzner wrote:

> 15-Apr-99 03:50 Klaus Weide wrote:
> > (only commenting on the uncaching-related part of this; I haven't read
> 
> >> >    I found another bug: if there is something on the cache stack (say 
> >> > doc A
> >> > -current doc and doc B), and we go to 'O' and change something, only
> >> > appearance of 'A' is changed, the appearance of B is not changed - the 
> >> > cahced
> >> > version is used. IMO it will be better to uncache everything in the 
> >> > stack.
> >> > This is best tested with 'links are/not numbered' - since rendered 
> >> > versions
> >> > differ a lot.
> >>
> >> That was a very expensive solution before SOURCE_CACHE
> >> but now this can be done nicely by adding more parameters to the function
> >> above and avoid using of HTuncache_current_document() calls.
> >> Until we keep a compatibility with SOURCE_CACHE:NONE this is a little 
> >> messy.
> 
> > If the behavior is changed from "only reload top document after
> > relevant option change" to "reload all affected documents after option
> > change", then please make this optional/configurable.  The current
> > behavior is maybe sometimes unexpected, but I generally prefer it over
> > the alternative.  I know where the ^R key is if I need it, and would
> > like to avoid unnecessary reloading.
> 
> I got a point of Klaus: currently with HTrerase_document()
> we lost a forms content (if any), so it is potentially a bad thing -
> user could not visit his history stack in certain situations.
> 
> A better thing would be to store forms data somehow and restore it
> after reparsing. Still wait a volunteer.
 
 I also wait for a volunteer :).
 May be Klaus approach is the best. In this case volunteer has to hack lynx 
 to store the state of the current document when something is changed in
'options' page.
 
 Best regards,
  -Vlad