[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev dev.16 patch 1b (partial mode for TRST table)

From: Klaus Weide
Subject: Re: lynx-dev dev.16 patch 1b (partial mode for TRST table)
Date: Mon, 6 Dec 1999 17:09:09 -0600 (CST)

On Mon, 6 Dec 1999, Leonid Pauzner wrote:
> 5-Dec-99 15:46 Klaus Weide wrote:
> > On Sun, 5 Dec 1999, Leonid Pauzner wrote:
> >> The fix:
> >>
> >>  * refresh screen for TRST changes in partial display mode as early as
> >>    possible, it was previously a problem when the table finished below
> >>    the screen bottom.
> > It seems I don't even understand the problem you are trying to fix...
> I mean the following picture:
>         xxxxx screen top line
>         TRST table starts here
>         xxxxx screen bottom line
>         TRST table ends around here.
> My understanding was the table will not be refreshed in partial mode
> until the last moment in mainloop (unless we will scroll before, which
> is not a general case).

(... or you press ^L, or perhaps some other key that causes a refresh.)

Yes, I think your understanding is correct.  It just doesn't bother me
too much, so I'm leaving it to you. :)

> So I add a hack to refresh the screen when TRST
> table ends to see the result earlier.

Ok, I understan now.  (I think.)

> Perhaps you mean first to disable partial mode just when the table
> starts - this is another topic.

No, I didn't mean that.   Originally I thought of disabling partial mode
in some way in order to deal with TRST changes to the HText, but I think
it is much better not do do that.  As I wrote in README.TRST:

                                                             In fact, the
   approach taken keeps Lynx free from a problem that may graphical browsers
   have: they often cannot render a table at all until it is received in full.

> >> --- old/gridtext.c      Wed Dec  1 09:28:20 1999
> >> +++ ./gridtext.c        Sun Dec  5 20:04:54 1999
> >> @@ -4671,6 +4671,12 @@
> >>      if (ncols > 0) {
> >>         lines_changed = HText_insertBlanksInStblLines(me, ncols);
> >>         CTRACE((tfp, "endStblTABLE: changed %d lines, done.\n", 
> >> lines_changed));
> >> +#ifdef DISP_PARTIAL
> >> +       /* allow HTDisplayPartial() to redisplay the changed lines.
> >> +        * There is no harm if we got several stbl in the document, hope 
> >> so.
> >> +        */
> >> +       NumOfLines_partial -= ncols;  /* fake */
>                                  ^^^^^
> >> +#endif  /* DISP_PARTIAL */
> Uh, that should be 'lines_changed' instead of 'ncols', sorry.

But lines_changed isn't right either.  For example you can have

   first    line
   second line
   third    line

where for some reason the "second line" doesn't get adjusted by TRST.
That "second line" would not be counted in lines_changed.  (The variable
is really rather useless, except for debugging and trace messages.)

Even if 'lines_changed' were the right variable for the number of lines
from start to end of the table, subtracting it from NumOfLines_partial
would still be wrong, unless I am still missing something.
NumOfLines_partial is the "number of lines at the moment of last repaint"
(according to the comment in HTFormat.c, and that seems to be correct),
*not* the number of lines at the point when HText_endStblTABLE() is called.
The two are not in synch.

I think what you want is something like
   NumOfLines_partial = MIN(last line before current table, NumOfLines_partial)

That is basically what is already being done in the two '#ifdef DISP_PARTIAL'
sections in HText_insertBlanksInStblLines(), but for
me->last_lineno_last_disp_partial instead of NumOfLines_partial.  So for
what you want, you should just repeat that in a simplified version, for
NumOfLines_partial.  Something like

            if (NumOfLines_partial >= 0) {
                if (NumOfLines_partial >= lineno) {
                    NumOfLines_partial = lineno - 1;

except that it probably needs to be adjusted for the different offset
(NumOfLines_partial counts 1-based, *last_disp_partial fileds count 0-based
I think).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]