lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev TAB character in text input fields of html forms


From: Kim DeVaughn
Subject: Re: lynx-dev TAB character in text input fields of html forms
Date: Thu, 17 Aug 2000 01:31:10 -0600

On Wed, Aug 16, 2000, Doug Kaufman (address@hidden) said:
|
| I don't see a way to enter a tab, either in a text entry field or in
| a TEXTAREA field. The latter does allow an external editor, but even
| when I enter tab from within vim, and confirm a tab (rather than a
| series of spaces), it is converted to spaces when the text is put back
| into lynx.

Correct.

The reason for that is that when I was adding the TEXTAREA external
editor code, I did a lot of testing as to the effects of allowing
TAB's (as well as other control chars) to be passed into the TEXTAREA
field.

When they (TAB's) were allowed in as literal embedded chars, lynx would
not render them as such.  Also, the display would get quite "confused"
as to the cursor's rendered position vs. the internally used position
value.  This "confusion" was further exacerbated if one "cursored over"
the embedded TAB, with differing visible results depending on whether
one was moving over the TAB from the right ("forward"), or from the
left ("backwards").

Allowing other control chars into the embedded text, would produce
various other forms of "confusion" ... some of which were rather
bizarre in their visually observable effects, when one would "cursor
around" in the TEXTAREA field(s).

Note that chars such as LF and CR are NOT actually rendered into the
TEXTAREA either ... each line of a TEXTAREA is really an independent
field, and when one hits RETURN/etc, no character is inserted ... one
is just moved to the next sequential field in the TEXTAREA.  Etc.

Therefore, after the experimentation (as well as looking at the code),
I concluded that lynx just isn't designed to handle TAB's and control
chars in a TEXTAREA.  Whether it *should* do so, is a question that I
didn't address ... what I *did* do was to insure that TAB's coming in
from the editor were converted to spaces (modulo 8), and that control
chars were converted to "splats" (later changed to dots, which is a more
common representation of control chars in on-screen binary editors, dumps,
etc).

If someone wants to fix the underlying rendering mechanism to properly
and predictably render TAB's (and cntl chars ?) in a TEXTAREA, I'll be
happy to remove or alter such filtering.


| I wonder if it might not be easier to fix the server that
| expects the tab.

Other than as a "hack", I can't think of any reason why a server should
*require* a TAB ... a SPACE should be treated equally as a separator
character.  IMNSHO.

/kim

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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