lynx-dev INSERTFILE, EDITTEXTAREA border cases (was: another largish patch)

[Klaus Weide]

On Thu, 28 Oct 1999, Kim DeVaughn wrote:

> On Tue, Oct 26, 1999, Klaus Weide (address@hidden) said:
> |
> | * Protect INSERTFILE and EDITTEXTAREA from generating memory access
> |   violations if the inserted file has lines that are too long for
> |   the buffer used.  An alert message is issued and the long lines
> |   are truncated.  Also don't exit if memory allocation fails for
> |   the buffer to hold the whole file, since the only reason for the
> |   failure may be that the file is too huge when otherwise lynx has
> |   enough memory.
> 
> Thanks for adding this, Klaus (it really was on my 2do-list ... just
> hadn't found a round tuit yet :-) ).
> 
> A few observations, however:
> 
>  1. The alert message doesn't show up if the operation was EDITTEXTAREA
>     (DWIMEDIT), but does for the INSERTFILE case.
> 
>  2. The truncation isn't total.  Only a single char at the length
>     boundary gets dropped; additional chars end up being rendered on
>     a subsequent line.
> 
>     Ie, chars 1-1023 are rendered on the target line, char 1024 gets
>     dropped, and chars 1025-nnnn are rendered on the target line plus
>     one.

Well I didn't test it very much - only to the degree that the crashes
I had earlier, when loading a weird file, went away.

You think I write disclaimers TOO MUCH?? :)

I'll look into your points, unless you get around to do it first.
It's obviously not the intended behavior.  (Spilling instead of truncation
may be a reasonable alternative, but anyway such files are sick cases
that won't amount to anything useful when submitted.)

>  3. While lynx is normally "quiet" (something I strongly agree with),
>     in this case, since data can be lost, might not this be a good place
>     to make an exception to that (quiet) behavior, and "beep" the user?
>     Also, issuing the alert message twice might be desirable, to be sure
>     and give the user enough time to read it.

If an ALERTSECS delay isn't enough, there probably should be a confirmation
prompt ("modal" as some folks say these days).

Re beeping - I don't think this "data loss" possibility is sufficiently
more severe than lots of others in other places.  To be consistent
lynx should them beep a lot.  Maybe even for every alert message.
I doubt you want that.

I don't see INSERTFILE & EDITTEXTAREA giving any guarantees about data
integrity anyway - they explicitly mess with the contents, and the
result is on the screen for review.


(In the LAKABOFTIF-with-beeping thing it would be somewhat different - that
would be explicitly configured by the user, as kind of a quite different
user mode.  Anyway it was just an idea.)

   Klaus