[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: |
Sat, 30 Oct 1999 10:32:52 -0500 (CDT) |
On Fri, 29 Oct 1999, Vlad Harchev wrote:
> On Thu, 28 Oct 1999, Klaus Weide wrote:
>
> > 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.
Who cares about lines longer than MAX_LINE? Not so many people. Part
of this isn't about "long lines" (>= display width, or ca. 80) but
about "very long lines" (>= MAX_LINE), the description should make
it clear. I'm a bit confused:
* Functionality of dont-wrap-pre improved and extened. Now it's possible to
avoid wrapping the document being dumped completely (size of the non-wrapped
line before the patch was limited by MAX_LINE = 1024 by default). Specifying
-dont-wrap-pre with interactive session enables wrapped lines (in PRE) to
be marked as in source view - with '+' in normal view.
Does this mean that -dont_wrap_pre has two quite different effects,
whether in non-interactive or interactive mode? One is about "very
long lines", the other about "long lines"?
The -help and man entries would also need updating.
(I think you could drop the reference to -crawl'ing from the -help
info to make it a bit shorter.)
Does it have an effect on SOURCE modes?
> 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).
The appearance of LY_SOFT_NEWLINE gotta cause some problems... So far
LY_SOFT_NEWLINE onlty had to be anticipated in SOURCE modes.
> > 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.
Forget about UTF-8 for this in the short term, it'll just cause
unnecessary headaches... Actually it's more or less impossible to have
an UTF-8 character in the last column, in the current approach (with
UTF-8 unaware curses). There are enough reasonable 7-bit characters to
choose from ('\\', '$', ...) to make everyone but the most demanding
happy...
> 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.
You don't need to do that with UTF-8, it's a nice encoding in that you
can just scan backwards until you hit a byte with (c & 0xC0) != 0x80.
> > 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.
It seems you have ingnored this point... (unexpected new meaning of
characters that appear on screen).
> BTW, looking at the code, it seems that me->skip_stack can be negative. Is it
> correct?
It should never be negative, that's just a bit of defensive pprogramming
in cases something goes wrong.
> > 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)?
There's still this comment:
#define OPT 0 /* don't make it 1 otherwise something wrong will be with
TagSoup parser mode - I was unable to undestand why it works incorrectly -HV*/
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, 1999/10/28
- 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 <=
- 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