[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Re: 8-bit characters in EDITTEXTAREA

From: Kim DeVaughn
Subject: lynx-dev Re: 8-bit characters in EDITTEXTAREA
Date: Wed, 10 Feb 1999 16:37:45 -0800

On Wed, Feb 10, 1999, Ismael Cordeiro (address@hidden) said:
| On Wed, 10 Feb 1999, Kim DeVaughn wrote:
| > It shouldn't be "8-bit chars" that get replaced with a ".", but only
| > "control chars" (ie, chars with numeric values below a SPACE, in either
| No, they are not control characters, not even 8-bit control characters
| (128-159). They are ISO 8859-1 printable characters (160-255). When I quit
| the text editor back to lynx they are "translated" to dots.

You've probably already seen my response about not using an (unsigned char)
cast, or iscntrl().  A patchlet will be along shortly.

| Anyway, if
| control characters were not allowed, nobody could use CR (13), LF (10) or
| TAB (9).

Each line of text (or anchor's input data, to be more accurate) is stored
internally as a seperate NULL terminated string.  The CR's and LF's that
one uses to move from line to line, do NOT become a part of those strings,
but are instead interpreted by lynx in the same way that a DownArrow key
is ... as a cursor/pointer movement command.

I also had to expand TAB's into SPACES (mod 8), since a TAB in a TEXTAREA
field is also interpreted as a cursor movement command.  Ugly Things
happen to normal cursor movement if TAB chars are actually allowed to
become embedded in the anchor's text strings.

| > Currently it is necessary to do *something* with such chars when they are
| > rendered into the TEXTAREA lines. Leaving them as control chars, causes
| > Bad Things to happen, when lines containing them later get submit'ted,
| > etc.
| Is there any RFC or similar document saying that control characters are not
| allowed in TEXTAREA?

I don't know.  I asked the same question when I started working on this.

What I *do* know is that if they *are* present, the submit'ed data can get
munged in a variety of ways, not to mention causing the cursor movement,
and rendering problems described above.

Whether that is "by spec", or a "lynxism", I do not know.

Now a question for you ...

What reason/requirement do you have for including control (not ALT) chars
in TEXTAREA strings ...?


reply via email to

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