[Lynx-dev] UTF-8 editing, link and form field numbering

[Thorsten Glaser]

While we’re on that topic…

I recall having complained here about lynx converting, for instance,
‘…’ (U+2026) to “...” (three times U+002E) in input fields before
submitting a form.

Now, after losing a few karma points on that site, I have more infor-
mation about this problem:

I usually use an external editor¹ (^Xe) to compose textboxen larger
than one or two lines worth of content, or when editing. This works
pretty well, but on http://www.symlink.ch/ (using an ancient ver-
sion of slashcode) it still did the conversion.

¹) http://mirbsd.de/jupp – I think it’s quite a good one ☺

When that page had a discussion about the use of Unicode right-to-
left and left-to-right overrides, I tried to paste my results into
the textbox both in Lynx and Opera. When using lynx, I got multiple
relatively unrelated characters for it, when using Opera, I got the
&#xxx; values for it. Turns out that slashcode sends out the header
| Content-Type: text/html; charset=ISO-8859-1
and you thusly cannot enter UTF-8 characters into input fields (or
rather, lynx autoconverts, otherwise, I’d get problems with words
like “Straße”, where the UTF-8 eszett gets converted to %DF or so
I think. I was told the only way to enter Unicode on (old) slashcode
is to use the HTML input version (whereas I always use “code”) and
enter them as entities.

So that bug isn’t one of Lynx̲’ since other sites with multiline input
fields (e.g. the FreeWRT bug tracker, using trac) work (with an ex-
ternal editor – the internal one still has these issues).

There are other bugs left though:

I’m working with “links and form fields are numbered”. Now suppose
there were a page like this:

================================================================== cut
…
[10]somelink

[11]____________________________________________________________
[12]____________________________________________________________
[13]____________________________________________________________
[14]submit
…
================================================================== cut

Now I hit 11, return, another return (textfields need activation), ^Xe,
edit and come back. I have entered 5 lines in the external editor.

================================================================== cut
…
[10]somelink

[11]first_______________________________________________________
[12]second______________________________________________________
[13]third_______________________________________________________
[14]fourth______________________________________________________
[15]fifth_______________________________________________________
[14]submit
…
================================================================== cut

As you can see, the “submit” button is still marked with [14] although
it should have been a [16] (and 14<return> indeed goes to the fourth
line, not to the button).

Another bug with form field numbering is, that if you have an input
field like this one:
  <input type=text size=13 name="Kunde" ID="Text1"><br>                         
                                 
You get the following:
   [9]__________                                                                
                                 
Basically, the [9] are three characters, and the text field’s size
is reduced by these (probably due to layout considerations, but as
HTML is flowing and line-breaking freely anyway, I don’t endorse
these). Now this gets bad if the input field size is, say, 4. That
example is actually from the webpage where my employer asks us to
enter our working hours (i.e. start and end), and I don't like having
only one or two “underscores” for a full 24-hour value to enter.

I think this bug also is the cause for the already-reported misdrawing
of the option screen:
  General Preferences
  User mode                        : [5][(3)__Advanced____]
  Editor                           : [6]jupp____________________________________
_
  Type of Search                   : [7][(1)__Case insensitive]

There’s probably another off-by-one somewhere. (That was 80x24 uxterm.)

Tom, I guess you don’t use link and/or form field numbering yourself,
as these bugs have been existing for quite a while; may I ask you to
check on them some time?

Thanks in advance!

//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
                                         -- Henry Nelson, March 1999