[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
> I think that it is probably fine like it is, except that it's not nfs
> safe without libnfslock. It could probably be rewritten some to call
> on our liblockfile, rather than doing it internally the way it does.
Does xemacs implement maillock itself? Emacs 20 doesn't, so emacs
20's maillock *would* be using liblockfile and so should be nfs safe.
The only problem that I've seen with emacs 20's movemail support of
maillock() (though I still don't feel qualified to be certain) is that
it appears to call maillock("full/path/to/spool", foo) rather than
maillock("username", foo).
Have you heard from James LewisMoss recently? I posted a propsal for
some immediate changes to the various emacsen which would move us
closer to supporting simultaneous install. I think Mark's OK with it,
but James hasn't said anything, and neither has anyone else...
My fear is everyone will only start screaming *after* I implement and
upload something :<
> If it ain't broke, don't fix it. I'm not motivated to do this
> today... It works like it is, for me. Someone who needs the nfs safe
> version ought to tackle it. I don't imagine it will take more than an
> afternoon of hacking.
Well, I think we really need to get everything nfs safe -- silent
failures suck, and loss of mail sucks even more.
> I wonder, would it be a good idea to put `movemail' into another
> general package, so that other programs can use it? I think that it's
> generally useful enough for that.
It might make sense to put movemail in emacsen-common. But that's
only good idea if xemacs, emacs19, and emacs20 expect the identical
semantics out of movemail...
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
