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

[Klaus Weide]

On Sun, 31 Oct 1999, Vlad Harchev wrote:
> On Sat, 30 Oct 1999, Klaus Weide wrote:
> > Who cares about lines longer than MAX_LINE?  Not so many people.  Part

I didn't mean that it's completely worthless.  Just that whether lynx
can dump lines longer than 1024 characters is unimportant to whether
lynx can dump lines longer than 80 or 100 characters.

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

We are talking about rendered HTML pages here.  If a page needs
a display width of more than MAX_LINE (or even MAX_LINE / 3), someone
is abusing HTML, IMO.

>  OK, I will update -help and 'man' entries.
>  As for references to -crawl'ing I don't understand what you meant.

I meant that, instead of writing "when -dump'ing and -crawl'ing" (as in
the -help message), you could write "when -dump'ing" to save some space.

> IMO, now
> you understand it exactly, could you do this?

I am still not sure I understand it exactly enough.  But I think
you have already made the change.  (Well if others don't understand
what the flag does they should speak up.)

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

Well okay, I guess I won't.

> > > > 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, [...]
>  
> > > 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.

If you want to go to that level of fine tuning, you should also consider
the effects of cache memory, register contention, etc.  IOW, I don't
believe "it's slower" until you can back it up with data.
Anyway, these would be insignificant differences (and it's all hypothetical
in the first place...).

> And seems you forgot about CJK.

No, I didn't.  We treat data as UTF-8 in UTF-8 display mode, we treat
data as CJK characters in CJK display mode, as usual; any problem with
that?

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

Well okay, I guess I won't use it.  


   Klaus