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

[Leonid Pauzner]

9-Jan-99 19:00 Kim DeVaughn wrote:
> 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
Agree. Currently Lynx shows up lines according their actual number,
not a suggested "window" size, so we want to check the number of lines again.

> | 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).

I wonder why you discuss backup/tempfile problem here,
IMHO it should be done by expanding an editor like in the "mailto:"; case,
we need an equivalent of  print_wwwfile_to_fd() from GridText.c,
something like  print_current_textarea_to_fd()
and  restore_current_textarea_from_fd()

Do you mean "backup" for original textarea content from HTTP server?
When user decide s/he lost an original content too much
we can suggest to reload the document with CTRL-R.