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

[Klaus Weide]

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

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.

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

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

  Klaus