lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [dev.15] fixup patch: edit TEXTAREA


From: Jacob Poon
Subject: Re: lynx-dev [dev.15] fixup patch: edit TEXTAREA
Date: Fri, 29 Jan 1999 16:02:30 -0500

On Fri, 29 Jan 1999, Kim DeVaughn wrote:

>  3. Replaces any embedded control chars with something printable (I
>     chose a "." char, since it is less "intrusive" than some other
>     choices, like "*", "+", "#", etc).
> 
>     As with tabs, when some of these chars *are* rendered into the
>     TEXTAREA, strange things may happen.
> 
>     This shouldn't be much of a limitation, since many of these chars
>     perform line-editing or system/job-control functions, when entered
>     directly while one is in the TEXTAREA.  They currently cannot be
>     "escaped" and entered as actual text chars, so far as I can tell.
> 
>     Anyway ... I don't know of any "legitimate" reason for them to be
>     used as TEXTAREA data, so for now, you get "dots" in their place.

I am wondering, if an external editor is used to edit files in TEXTAREA,
will the unprintable characters get filtered out as well?  The reason of
concern is that it is possible that Lynx cannot print the text in
TEXTAREA, but the external reader can (eg: text in TEXTAREA is encoded in
Unicode, and Lynx cannot use the proper font, so external editor is
required to read/write Unicode).  If this patch sends a filtered version
of data when launching external editor, Lynx will destroy the TEXTAREA
contents and makes the filtered texts unreadable on any editor, which
partially defeats the purpose of external editing.

Therefore, my suggestion is this:  Unless specified otherwise, Lynx should
only change the _representations_ of unreadable characters in TEXTAREA,
not the unreadable characters themselves, so that external editors has a
chance of properly handling any TEXTAREA data where Lynx fails to
recognize.

reply via email to

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