Re: lynx-dev patch: Textarea editing and charset

[Kim DeVaughn]

On Tue, Oct 12, 1999, Klaus Weide (address@hidden) said:
|
| On Tue, 12 Oct 1999, Kim DeVaughn wrote:
| >
| > The above code is only executed when we need to "clone" new textarea
| > lines, in which case I think it is clearer what's being done the way
| > Marek coded it (taking the value from the previously existing textarea
| > line).
|
| You are only cloning the meta information here, but not any content, at
| that point.

Correct.  Content is never cloned, BTW (unless your definition of "content"
is different than mine).


| > | Normally anchor->input_field->value_cs should already be initialized
| > | to have the same value as current_char_set, but there can be some
| > | situations where that's not the case.  (E.g. if you have just changed
| > | the d.c.s. in the 'O'ptions screen, and the document containing the
| > | form wasn't reloaded as a result of that - probably because it was
| > | not the top one.)
| >
| > If that could happen, it seems that the original textarea lines would
| > have an incorrect value then.
|
| Yes indeed.  And it can happen.  I pointed out the situation I am aware
| of.  It probably isn't a common one (how often to you change d.c.s.?)
| but still, why not put the current right value there, it's gonna be
| a new line filled with now content by the user anyway.

Consider:

User is on a page with a TEXTAREA.  Decides to change the d.c.s.  Then
decides to enter some text into the TEXTAREA.

Initial (original) TEXTAREA lines will still be using the original char
set, but when/if the user adds some *new* TEXTAREA lines, they (and only
they) will use the newly specified d.c.s.

If the additional lines are the result of using an external edit (and/or
an insert-file operation that "overlaps" the old and the new lines), I'm
not at all sure what the result will be (since presumably the editor's
buffer and/or the inserted file are using a single char set, which now
gets mapped onto a multiple-char-set TEXTAREA), except that it will probably
NOT be what the user wants/expects.

Only in the case where the user has entered text in the original TEXTAREA
lines with the original d.c.s, then changes it, and then enters new text
in new TEXTAREA lines (using AUTOGROW lines, or the insert-file operation),
being careful not to touch the original lines, does the end-result have a
chance at being correctly rendered with the two/multiple-d.c.s's.  Note
that the external editor operation (probably) cannot be used, and still
come out with the "correct" result, since the entire TEXTAREA that exists
at the time of editor invocation is sent to the editor.

I think it is at least *consistent* to use the d.c.s. of the previously
existing "pattern" TEXTAREA line, when using it to clone new lines.  Yes,
it is incorrect if the char set gets changed, and the page not reloaded,
but that isn't any worse that the situation with the originally existing
lines, which are then incorrect, also.  And at least using my methodology,
*all* the lines are *consistent*.

The *real* problem is (I suppose) the lack of a reload following a change
of char sets, but I wouldn't want to impose the manditory reloading, of
the page, just to correctly deal with this rather unlikely/infrequent
situation.

Also, I think of a TEXTAREA as a monolithic entity, which implies that
its constituent lines are all using a single char set.  Perhaps that is
an overly restrictive point-of-view.


| > Perhaps we need to think on this some more ...?
|
| I did.  Your comments?

I see that in -dev.11/12 Tom has decided to use  current_char_set  in both
places.  I don't agree with that for the above reasons, but since it's more
of a philosophical issue, than a substantive one (and one that is unlikely
to come up very frequently, if at all), I shan't object any further.


| Oh, and INSERT_FILE should probably be labelled according to
| ASSUME_LOCAL_CHARSET, not d.c.s., when the cloned lines are first
| filled in.

I haven't looked at your "megapatch" yet, but I did see that you did some-
thing for the insert-file case, based on file extensions (though I am not
sure how that can/should determine what char set should be used, ATT).

/kim