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

[Michael Warner]

On Fri, Jan 08, 1999, Kim DeVaughn <address@hidden> wrote:

        [...]

> One other thing I've added is a bit of code to unlink()
> leftover emacs style backup files~ . I'm wondering how best to
> handle that problem, in general.
>
> Probably the best way would be to have one's backup file
> "extension" defined in the .lynxrc file (though that probably
> means another line in the options menu).
>
> Alternatively, several common backup extensions could be tried,
> in addition to the trailing tilde form (.bak, .BAK, etc)>
>
> Or, I could just leave the garbage laying around, and tell
> the user to write a "wrapper" shell-script/etc to cleanup the
> extraneous files, but I really don't like doing something
> like that.  And yes, I know that the "make backup" function
> of the editor could be turned off, but remembering to do that
> each time would be a real PITA (besides which, I'm sure most
> users wouldn't know that they needed to).  I'd also like some
> feedback on this issue.

NOTA BENE:  I'm not a programmer or anything, so this may well be
            just noise from a naïve user, but ...

Trying to clean up after an arbitrary user-defined editor on an
extension-by-extension basis would be a major can o' worms, I'd
think.  You could guess at common extensions, but I doubt you
could get them all, and then there are the user-configurable ones
that could be anything at all.

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.

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?

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

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

-- 
Michael Warner          "You're cute when you're stupid"
<address@hidden>                                -- R.A. Miller