lynx-dev line-crossing [tag] strings (was: Re: LYNX: more pleas for the L-page addrs)

[Kim DeVaughn]

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.

Klaus,

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

/kim
>