[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev line-crossing [tag] strings (was: Re: LYNX: more pleas for the
lynx-dev line-crossing [tag] strings (was: Re: LYNX: more pleas for the L-page addrs)
Tue, 2 Feb 1999 05:47:35 -0800
On Mon, Jan 18, 1999, Klaus Weide (address@hidden) said:
[discussion of l-page rendering]
| > > Some parts of the code rely on link numbers being surrounded by
| > > exactly '[' and ']' - especially the fickle code for removing link
| > > numbers for "hidden links" after the fact. I wouldn't like to have
| > > to make that code more general.
| > How does THIS code work? Does it actually scan for square brackets
| > in the text? Suppose someone has some title or url or whatever within
| > square brackets; does that fool lynx?
| That doesn't happen at arbitrary times, but only directly after the
| "[nnn]" has already been appended to the text structure being built,
| i.e. when the "[nnn]" is (supposedly) at the very end of the current
| text. Even that is complicated enough, since the line may have been
| broken while the "[nnn]" was being output or spaces inserted, and
| because of the way lynx stores the rendered text scanning back is not
| a trivial matter.
I am considering adding a bit of code to prevent [tags] from being [spli
t] across lines, which will greatly simplify fixing everything up after
a TEXTAREA expansion has occurred (see the new patch that I just posted
a short while ago).
Any reason you can think of why *preventing* line-crossers is not a good
- lynx-dev line-crossing [tag] strings (was: Re: LYNX: more pleas for the L-page addrs),
Kim DeVaughn <=