Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection

[Klaus Weide]

On Sun, 5 Dec 1999, Leonid Pauzner wrote:
> 5-Dec-99 06:14 Klaus Weide wrote:
> > On Sun, 5 Dec 1999, Leonid Pauzner wrote:
> >> 4-Dec-99 09:10 Klaus Weide wrote:
> >> >       HTReadProgress(bytes, 0);
> >> > -     HTDisplayPartial();
> >> > +     if (NumOfLines_partial >= 0 && HTMainText && HTMainAnchor &&
> >> > +         bytes != HTMainAnchor->content_length)
> >> > +         HTDisplayPartial();
> >>
> >> >       if (HTCheckForInterrupt()) {
> >> >           _HTProgress (TRANSFER_INTERRUPTED);

> > I admit I haven't kept up with all the recent patches for partial mode.
> > Well I briefly scanned tha patches, they looked like very worthwhile
> > improvements, but I haven't tried to really understand them.  I'll wait
> > for dev.17 for that, I think.
> No, I mean pre-dev16 changes that are already in dev16 at www.slcc.edu
> (my post-dev16 changes are irrelevant in this case).

Ok, I was still going by the comment that used to be in HTFormat.c
but is gone now.  The one that said that -1 is a special value for
NumOfLines_partial.

> > The tests may be excessive or even wrong, but were the best I could
> > think of without changing HTFileCopy to take an anchor as an additional
> > parameter (maybe that should be done instead).  Relying on the global
> > HTMainText/HTMainAnchor isn't nice, but seemed no worse than what the rest
> > of display_partial code is doing - i.e. the assumption that HTMainText
> > describes the right document (the one we are *currently* loading for).
> dev16 can say this for sure: we enable 'display_partial' when
> HText_new() already started, and disable 'display_partial' right after
> HTDisplayPartial() in HTFinishDisplayPartial() called few lines below
> from the same function. No untested intermediate levels.

Ok thanks, now I know, it wasn't clear to me before.

I admit I never really understood display_partial.  Bits and pieces, enough
to change things in GridText.c, but not the big picture.  It seems it's
getting easier.

> >> Also, display_page() were hacked by you to redisplay only those lines
> >> which were not displayed in partial mode yet so the next repaint from
> >> mainloop will not make any harm.
> 
> > That doesn't prevent all redisplaying.  In particular I was thinking

> HTDisplayPartial() does. You assume the complete file will fit into one
> screen and assume very strict timing conditions when your fix can be in
> effect.

No, I don't assume that - why do you think so?

It seems to me that every file with size <= INPUT_BUFFER_SIZE (4K) will
benefit, at least, if the complete file will *not* fit into one screen
(otherwise there is no screen update anyway, because of

        if (((Newline_partial + display_lines) > NumOfLines_partial)
                /* current page not complete... */

- right?).

> In the case of TRST mode you may want partial redisplay in more
> situation, not less.

I'm not sure I want it...

> E.g. call HText_padeDisplay() when TRST table
> started on (or above) the current screen but finished below the screen.

I can press ^L.  That should force an update.

> But this will add a next level of complexity... add HTDisplayPartial()
> call in HTML.c or (better) TRSTable.c when TRST mode is closed.
....

> I use Lynx remotely every day, I have not seen a problem here, perhaps
> display optimized by ncurses (obsolete 1.9.9e one). [And I have not
> using utf-8 display in any way. Also, lynx utf-8 display staff
> completely out of my understanding, say, few lines right on the top of
> HText_new()].

I think you mean this stuff:

            self->had_utf8 = HTMainText->has_utf8;

Well, I'm not sure that is all as it should be...  Hmm, it doesn't seem
to make a lot of sense, now that I look again:
        if (something) {
            self->had_utf8 = HTMainText->has_utf8;
        } else {
            self->had_utf8 = HTMainText->has_utf8;
        }

I'll have to look at it again.


> >> Instead, that may be a good idea to add a true content_length to
> >> HTReadProgress() call which may be useful for large files.
> 
> I mean in HTReadProgress() in HTFileCopy() from the patch cited above :)

I'm not sure what you mean.

> > HTReadProgress() is simply counting wrong (that isn't new).  The
> > functions in HTFormat.c don't know anything about the boundary between
> > HTTP header and body.  But content_length (for HTTP) counts only body
> > bytes.  Proper counting for HTTP resources would have to zero the
> > counter at that boundary, the only good place to do that would be in
> > HTMIME.c.  But you may still want to take the initial packet(s) into
> > account for the bytes/sec, and then it gets more complicated.
> 
> Well, I grep WWW for HTReadProgress() just now. There are many calls for
> bytes = 0 but all calls with bytes > 0 are in a proper places only. So
> we can initialize bytes/sec counter with the first call for (bytes > 0),
> not (bytes == 0) in HTReadProgress() implementation in HTAlert.c. That's
> easy fix.

Sorry, you lost me.  I don't even understand whether you are talking about
changing, HTReadProgress itself, or some places where it is being called,
or both.

   Klaus