[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev INSERTFILE, EDITTEXTAREA border cases (was: another largish pat
From: |
Klaus Weide |
Subject: |
lynx-dev INSERTFILE, EDITTEXTAREA border cases (was: another largish patch) |
Date: |
Thu, 28 Oct 1999 14:42:15 -0500 (CDT) |
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
- Re: more TRST support (was: Re: lynx-dev another largish patch), (continued)
Re: lynx-dev another largish patch, rjp, 1999/10/27
Re: lynx-dev another largish patch, Kim DeVaughn, 1999/10/27
Re: lynx-dev another largish patch, Kim DeVaughn, 1999/10/28
Re: lynx-dev another largish patch, Henry Nelson, 1999/10/27