lynx-dev
[Top][All Lists]
Advanced

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

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


From: Vlad Harchev
Subject: Re: lynx-dev disappearing empty lines (was: THANKS AND QUESTION)
Date: Mon, 4 Dec 2000 21:57:30 +0400 (SAMT)

On Tue, 4 Jan 2000, Klaus Weide wrote:

> On Mon, 4 Dec 2000, Vlad Harchev wrote:
> > On Tue, 4 Jan 2000, Klaus Weide wrote:
> > > 
>[...] 
> >  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).

 OK.

> 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.

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

 Oops, I was wrong. Read "-dont-wrap-pre mode" instead of "-with-backspaces".  
 (remember, specifying this flag will force lynx to emit LY_SOFT_NEWLINE even
in normal display mode, not in psrc view or when dumping).

> > 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. :)

  Oh, you are right :-) 

> 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.

  I'll try to do permuting.
  
>   Klaus
> 

 Best regards,
  -Vlad


reply via email to

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