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

[Kim DeVaughn]

On Fri, Jan 08, 1999, Michael Warner (address@hidden) said:
|
| If the user defines an editor, could it be assumed that s/he has
| used it before, and would have noticed if it was leaving backup
| files strewn about?  Then again, I guess these'll be written to
| TMP_SPACE, which might make it an "out of sight, out of mind"
| situation.

Yes, that's exactly the problem.  And unless the system has some sort
of cron'd cleanup for the temp area used, the trash backup files will
just accumulate to large numbers, over time, chewing up "inodes", disk
space, "inodes", and generally making the directory hard to deal with
(especially if the temp area is a "common" directory, such as /tmp).

Besides which, leaving such trash lying about is poor programming
practice, IMHO.


| Well, then, assuming lynx specifies the directory and
| filename - couldn't it just do something equivalent to 'rm
| ${TMP}/L12345-1TMP*' when it's done with the file, and catch all
| the extensions?  (It *is* pretty standard for the back-up to be
| written to the same directory as the original, isn't it?)  Or is
| that unavailable to lynx, &/or non-portable, &/or more trouble
| than it's worth, etc?

Heh.  'Twould be nice if it were that simple, but wildecard expansion
is almost always performed by a shell.  To do the equivalent, program-
atically, requires the app to walk thru the directory itself, or use
something that isn't very portable, like wildmat().

I've always thought that it was unfortunate that filesystems weren't
originally *designed* to inherently support "wildcarding", but they
weren't, so here we are ...


| If that doesn't work, then it seems to me that the best that
| could be done would be to flash the user a message saying
| "Spawning external editor - any back-up files generated are YOUR
| problem...", or words to that effect.  If there's a significant
| chance of lynx missing the back-up, I'd think it would be better
| to do nothing than to give users a false sense of "lynx will
| handle it".

Of course that's the easiest thing to do, but not very user-friendly.
Especially since the app *knows* that a cleanup is (often) required,
following editor invocation.


| Trying to do too much baby-sitting of external apps just seems
| like a losing proposition.

True.  But there's a difference between sloppy programming, and hand-
holding, and as I said above, I consider not cleaning up after one's
self (when possible), to be "sloppy".


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

/kim