lynx-dev Re: [-dev.12] experimental text entry fields patch (updated)

[Kim DeVaughn]

On Sat, Jan 09, 1999, Bela Lubkin (address@hidden) said:
|
| Kim DeVaughn wrote:
| >
| > The more I think about it, the more I'm leaning toward having an
| > "editor backup extension" line in the .lynxrc file.  That seems to be
| > the "right thing" to do, and *then* if the user doesn't care about
| > setting the field ... well, I'm not into baby-sitting either.  I've at
| > least tried to make the app well-behaved (plus given someone another
| > opportunity to say "rtfm", somewhere down the road ... :-) ...).
|
| Suppose you make a subdirectory in TMP_SPACE.  Put the file-to-be-edited
| in that subdirectory, chdir*() to it, and spawn the editor.  All editors
| that I know of write their backup files to the same directory as the
| file being edited, or at very worst, to the current directory.  On
| return from the editor, delete *all* files in that subdirectory.

Hmmm.  That's an idea, though it seems a bit overly "complex" at first
glance.  Also, how portable would that be ... I'm thinking specifically
about VMS, about which I know almost nothing?

Certainly worth a "second glance" though, and I'll keep it in mind.


| BTW, let's not forget that this two-step process of "move text area to a
| file", "edit text area which is in a file" was invented only because the
| author of the patch didn't know how to integrate it better.  Eventually
| it should look just like Lynx currently does, except that when you're on
| a text area, you can hit some key to edit it externally.  On return, the
| text should be back in Lynx's normal data structures, visibile on
| screen, and even editable there, within the constraints of Lynx's
| on-screen editing.  (And one reasonable extension might be that if the
| externally-edited text doesn't fit in the on-screen text box defined by
| the HTML, Lynx could expand that box's borders.  At least the vertical
| borders -- we're still shying away from implementing horizontal
| scrolling...)

That's exactly what I'd like to ultimately see, too.  At this point
though, I don't know either the lynx code, nor html well enough to try
and suck the edited text back into the lynx structures, in the proper
format.  Hopefully I will, after a bit more work, or "someone else" will
pick up the ball, and do that, if I'm not able to.

Even so, it still seems like there'll be a problem with backup files~
left laying around, since if you decide to externally edit a text field
that *already* has some text in it, that text will need to be transfered
to a file before the editor is invoked, and then upon exiting the editor,
both the newly edited text file, and its backup~ will exist (independently
of whether the new text gets rendered into the lynx data structs, or not).


Since you brought it up above, I was wondering about the end effect(s)
of what typically happens if one sends back to the site more lines (or
total text size) than was originally intended by the page's text-area
"sizing" parameters.

Do (most) sites generally accept as much data (for some definition of
"within reason") as the user cares to send back without an error occurring?
Do they truncate the data?  Or what?  I realize that it is certainly up to
the site to do with the submitted data as it will, but I'm wondering if
there are any general guidelines that most sites use, which covers this.
Fat chance, I know ...

What I'm getting at though, is *should* lynx allow the user to send an
unlimited amount of text back to the site, or should it apply a hueristic
of some sort to the size of the text returned (eg, not more than N times
the size of the originally specified text area, for some value of N)?

I don't like making arbitrary restrictions, but OTOH, I also don't want to
give a user the a false impression that any amount of text is likely to be
accepted by the site, if that is typically not the case.

/kim