[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Lynx-dev] An old bug: textareas screw up form field numbering
From: |
Luke, Shellworld Support |
Subject: |
[Lynx-dev] An old bug: textareas screw up form field numbering |
Date: |
Sat, 26 Mar 2022 07:47:55 +0000 (UTC) |
This one has been around for a long time. I just ran into it again when
filling out a forum comment form, and thought I would mention it.
If links and formfields are numbered, and you have something like this:
[90]_____
[91]_____
[92]_____
[93]_____
Email: [94]_____
Where 90 through 93 represent a textarea.
Then you edit the text area with an external editor such as nano.
When you come back, you may get something like this:
[90]My entered text___
[91]Here._____________
[92]__________________
[93]I entered some____
[94]extra lines, you__
[95]See, and now we___
[96]have a problem.___
Email: [94]_____
I'm sure you can see the problem: we now have two lines 94. In fact, if
you press ctrl+v then type 94, you will get the one in the textarea, not
the original one as you might expect. There is in fact no numbered way to
reach the email field.
I can only think of one solution to this: that used by links. Links, at
least the version I used to use (may have been links2), gave but a single
field number to the textarea. Thus, no matter how large the textarea got,
it was always represented by one field number, at or above its first line.
I have very rarely needed to address single lines in a textarea in a way
that requires them each to have their own line number; anything like that
I can do in an editor, and probably better.
I don't know whether my usage is the norm, but personally I wish this
behavior could be changed to the Links style.
Luke
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Lynx-dev] An old bug: textareas screw up form field numbering,
Luke, Shellworld Support <=