[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: |
Sun, 31 Oct 1999 20:21:34 -0600 (CST) |
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
- 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, 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 <=