lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev patch: Textarea editing and charset


From: Kim DeVaughn
Subject: Re: lynx-dev patch: Textarea editing and charset
Date: Sat, 23 Oct 1999 09:07:47 -0600

On Fri, Oct 15, 1999, Klaus Weide (address@hidden) said:
|
| In *other* cases - the ones you are considering - there are data
| (characters) in the page, at the time of the d.c.s. change, whose
| meaning changes by the re-labelling.  Well, I'd expect the user
| to notice this in most cases.  Or at least, the user normally has
| *a chance* to notice this, and can force a complete reload before
| any really weird confussion happens.

Actually, the case I was mostly considering was when a TEXTAREA was
empty, the user changed the d.c.s w/o a reload, went into an editor,
typed in N lines of text (assuming the newer d.c.s. was in effect),
where N is something greater than the original number of TEXTAREA
lines.

On returning from the editor, the user my well be quite confused if
the 1st (say) 5 lines are using one char set, and the other (say) 5
lines are using the other set.

But it probably isn't worth worrying about any further ... at least
until there is some evidence that there really *is* a problem (ie, a
bug report).


| > 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.
|
| Well that's the simplistic (common-sense?) view that most everybody has
| about textareas except lynx users, I guess.
|
| The Lynx Users Guide says explicitly somewhere that lynx handles a
| TEXTAREA as a series of TEXT input fields.

Yeah ... I do recall reading that.

OTOH, some operations do NOT use that definition in a strict sense (eg,
FASTTAB), and recent discussion about giving just the uppermost line
of a TEXTAREA a [tag]-number when that option is enabled, was (mostly)
positive ...


| > 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.
|
| Maybe consideration of the so-far-only-ASCII case can remove even
| your philosophical disagreement?

Nah, but it isn't a STRONG disagreement :-) .

/kim

reply via email to

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