[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour
From: |
Klaus Weide |
Subject: |
Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour |
Date: |
Thu, 28 Oct 1999 14:00:19 -0500 (CDT) |
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
- lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, Vlad Harchev, 1999/10/28
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour,
Klaus Weide <=
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, Vlad Harchev, 1999/10/29
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, David Combs, 1999/10/29
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, Klaus Weide, 1999/10/30
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, Vlad Harchev, 1999/10/31
- Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour, Klaus Weide, 1999/10/31