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


reply via email to

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