Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour

[Vlad Harchev]

On Thu, 28 Oct 1999, Klaus Weide wrote:

> On Thu, 28 Oct 1999, Vlad Harchev wrote:
> 
> >  Hello, Klaus!
> > 
> >  I'm thinking on cleaning up some code I've written. I'd like to know your
> > opinion on some topics.
> > 
> >  May be you remember the '-dont-wrap-pre' hack I posted monthes ago. You 
> > said
> > that the functionality it provides could be done more reliably by restoring 
> > the old behaviour (achieved by emitting LY_SOFT_NEWLINE rather than 
> > phisically
> > preventing wraps in lines). I think using old behaviour (via 
> > LY_SOFT_NEWLINE)
> > will be better (it will also cause '+' to be prepended on the wrapped lines 
> > to
> > indicate that they are wrapped - but I think that this should be
> > controllable with commandline switch as it is now). Do you have any
> > strong objections to this (or may be you have any other suggestions)? 
> 
> I have never played wiht -dont-wrap-pre, so my response is just theoretical.
> And I don't remember now what I wrote before about it...

 It allows to get the non-wrapped text in PRE if -dump'ing or -crawl'ing if
that commandline switch was specified. But due to the way it was implemented, 
it will wrap too if there are more than MAX_LINE (1024 by default) characters
on some line. Now  I think that simply emitting LY_SOFT_NEWLINE will remove 
that restriction. I think that it's worth to emit LY_SOFT_NEWLINE if not 
 dumping too (ie in interactive session if and only if -dont-wrap-pre was
specified on command line). 
 
> I don't like the '+' prefixing convention in SOURCE very much, although
> it does the job.  But something appended to the previous line (esp. a
> backslash) would be more obviously.

 Yes, this will be better. And in the ideal case, it should be possible to
specify the character that will denote splitted lines (it can be utf-8
character since very funny character can be chosen then), and it should be
possible to specify color attributes of that character. But implementing this
will require maintaining the pointer to the begining of the previous character
in the line (since the last character can be utf8 character). IMO the
efforts on implementing general approach doesn't worth it currently.

> I don't like to see this '+' extend to non-SOURCE view.  For now I know that
> in SOURCE view, a '+' I see may not really be a '+'.  I don't expect to
> see characters with this "meaning" (just a technical indication of something,
> not part of data) in normal view.
>
> > May be 
> > this should be discussed on lynx-dev?
> 
> Yes, please let furhter discussion take place on lynx-dev.
> 
> >  As for SET_SKIP_STACK, I think the code at the end of HTML_end_element
> > shouldn't emit stylechanges (on lss-lynx) if me->skip_stack > 0 at the entry
> > to this function. At least avoiding emission of colorstylechanges fixes one
> > bug (I can send you an html file) - since in case of tags that can't be
> > nested (like 'a'), the call to FastTrim* will truncate the string being 
> > hashed
> > to the empty string (this will leave to the total style leaking in that 
> > line).
> > Hint: if -force-empty-hrefless-a  is activated, such situation will happen
> > very often. What do you think?
> 
> That is something I always wanted to look into; or rather, expected someone
> else to look into. :)  I am quite sure it can't be right as it is.
> 
> Historically, IIRC, SET_SKIP_STACK came first, style code came later
> (and ignored it).  If it had been the other way around, I would have
> felt obliged to make sure SET_SKIP_STACK doesn't break the previous
> code.
> 
> I am not familiar with FastTrim* stuff, it hasn't been obvious (or
> documented in comments - I didn't look hard though) how it works and
> what it does, so I never dug into it.  (Not that the state before your
> changes was much clearer...)

 It does the same as TrimColorStyle, but much faster. But as I understand, you
are not opposed to not emitting colorstyle changes if me->skip_stack was >0 on
entry to HTML_end_element. I have the patch ready for this.
 BTW, looking at the code, it seems that me->skip_stack can be negative. Is it
correct?
 
> >  Seems I have some time for lynx hacking and much fewer time - for cleaning 
> > up
> > the code :)
> 
> Please give at least the OPT / OPT1 stuff in SGML.c another look.
> It's an old idea of yours after all, and currently half-finished.
> (And maybe by some incidental fix I made the problem you saw went away...)

 It's finished as I remember, but not enabled by default. Seems it was working
correctly. If it works correctly, should I remove old, slow code (that was
before my changes)? 

>   Klaus
> 

 Best regards,
  -Vlad