lynx-dev
[Top][All Lists]
Advanced

[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: Vlad Harchev
Subject: Re: lynx-dev 'lynx -dont-wrap-pre' switch, SET_SKIP_STACK behaviour
Date: Sun, 31 Oct 1999 13:22:45 +0400 (SAMT)

On Sat, 30 Oct 1999, Klaus Weide wrote:

> 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

  IMO this is more important then fixing *Leaks stuff in psrc. I consider this
as one small step toward ideal lynx. And that MAX_LINE constant will seem much
smaller if UTF display is used since a character takes more bytes (as I
remember, 3 for Cyrillic). 

> 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"?

 Yes, this means that now arbitrary long lines can be reconstructed when
dump'ing and that specifying this switch for interactive use will mark
wrapped lines in <PRE> with '+' as in source view.

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

 OK, I will update -help and 'man' entries.
 As for references to -crawl'ing I don't understand what you meant. IMO, now
you understand it exactly, could you do this?
 
> Does it have an effect on SOURCE modes?

 No, it doesn't.

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

  User will encounter with new behaviour (in interactive session) if
-dont-wrap-pre switch is specified. I see no problems here - just don't use
this switch for interactive sessions.

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

 I didn't start implementing this - so don't worry :)
 
> > 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.

 It's slower than simply reading the previously stored value - some member of
HText structure. And seems you forgot about CJK.

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

 As I said, users will encounter new behaviour in interactive session if
-dont-wrap-pre switch was specified.
 
> 
> >  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*/

 As I remember, the glitches were caused by something else, not by
enabling OPT. But seems I will have to postpone inspecting OPT/OPT1 stuff -
don't have time. Sorry.

> 
>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

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