[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection
From: |
Klaus Weide |
Subject: |
Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection |
Date: |
Sun, 5 Dec 1999 15:28:34 -0600 (CST) |
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
- lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection (long), Klaus Weide, 1999/12/04
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection (long), Leonid Pauzner, 1999/12/04
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection, Klaus Weide, 1999/12/05
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection, Leonid Pauzner, 1999/12/05
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection,
Klaus Weide <=
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection, Leonid Pauzner, 1999/12/05
- Re: lynx-dev dev.16 patch 3 - HTMIME.c, HTTP.c redirection, Klaus Weide, 1999/12/06
- lynx-dev flickering upon first bookmark display Re: dev.16 patch 3 - HTMIME.c, HTTP.c redirection, mattack, 1999/12/05
- Re: lynx-dev flickering upon first bookmark display, Klaus Weide, 1999/12/07
- Re: lynx-dev flickering upon first bookmark display, mattack, 1999/12/07
- Re: lynx-dev flickering upon first bookmark display, Leonid Pauzner, 1999/12/08
- lynx-dev Can't open output file!, Harrison Johnson, 1999/12/08
- Re: lynx-dev Can't open output file!, Lloyd G. Rasmussen, 1999/12/09
- Re: lynx-dev flickering upon first bookmark display, Klaus Weide, 1999/12/08
- Re: lynx-dev flickering upon first bookmark display, David Combs, 1999/12/09