Re: lynx-dev disappearing empty lines (was: THANKS AND QUESTION)

[Klaus Weide]

On Mon, 4 Dec 2000, Vlad Harchev wrote:
> On Tue, 4 Jan 2000, Klaus Weide wrote:
> > 
>  Of course this case was made possible by the addition of psrcmode
> and/or -dump-with-backspaces (since there was no modes in which 
> LY_SOFT_NEWLINE was emitted in the text, that contained LY_*START_CHAR). 
> -dump-with-backspaces mode and psrcmode make such case possible.
>  
> > If data[0], can be LY_*START_CHAR, then so can presumably data[1], and
> > possibly more.   Without knowing that that can never actually happen,
> > the added test looks like a partial ad hoc fix up, not a real solution.
> 
>  As I understand GridText.c and SGML.c, LY_BOLD_START_CHAR can't be nested.
>  So LY_UNDERLINE_START_CHAR can't be nested too. 

I don't know that for sure, but I'll believe you. :)

>  I'm not sure whether
>  LY_U*START_CHAR can immedeately follow LY_B*START_CHAR and vice versa (please
> answer).

Yes they can.  At least one of those two cases does occur as a matter
of course, for links that are within emphasised regions (i.e. what
would normally be shown as COLOR:5 with non-lss-color).

But - why are you asking me?  You are the one who added psrcmode and
-dump-with-backspaces which "made this possible".  If there is some
reason why, under these new circumstances, LY_BOLD_START_CHAR and
LY_UNDERLINE_START_CHAR cannot occur in combination, you should be the
one to know - if anyone.  If you don't, then better assume that you
cannot rely on it.

Me, I don't even understand why LY_SOFT_NEWLINE should have anything
to do with -dump-with-backspaces.

> So, there is a chance that data[2] also should be compared against
> LY_SOFT_NEWLINE.

You'd better prepare for that, unless you know it can't happen.

> > IMO the code that adds LY_SOFT_NEWLINE to a line should make sure that
> > it gets put at the beginning of a line, maybe by re-ordering before
> > LY_*START_CHARs if necessary, so that no fixups are necessary in other
> > code that later has to process the lines.
> 
>  I agree that this is a cleaner way, but I'm not sure whether it would be easy
> to make swappings with CJK texts, etc (in other words, making these fixups is
> much easier for me). 

If you restrict yourself to permuting sequences of SpecialAttrChars
(or a more restricted set, like LY_{B,U}*START_CHAR, LY_SOFT_NEWLINE)
then CJK texts shouldn't matter at all.  That sounds just like an
excuse. :)

E.g. current line contents (B=bold_start, U=underl_start)

  [0][1][2]
   B  U  0

Now someone attempts to append "+"(=LY_SOFT_NEWLINE),

just scan current line content from end to start, if you find any
non-specialchars something must be wrong, abort any reordering
attempt; otherwise shift bunch-o existing specialchars by one,
insert + in [0], continue as usual.

> If you think it's easy to do this swapping, could you 
> please do the swapping yourself?

Not easier *for me*, since I'm not familiar with all those cases where
LY_SOFT_NEWLINE can be added, I mean all the new cases you added.
Sure the logic is easy, it's not easy to know exactly where it belongs.

>  Please answer whether you'll implement swapping.

I'll just repeat, like Tom :)
Vlad, please send patches.

  Klaus