Re: Which package would be suitable for password.el?
>>>> "Gerd" == Gerd Boerrigter
<Gerd.Boerrigter(a)gmx.net> writes:
Gerd> Simon Josefsson <jas(a)extundo.com> writes:
> Steve Youngs <sryoungs(a)bigpond.net.au> writes:
>> > So it overrides XEmacs core elisp code, even though the
core
>> > code is buggy (see other discussion regarding run-at-time).
>> No it doesn't. It by-passes buggy package code. The
XEmacs
>> `run-at-time' exists in the fsf-compat package.
Gerd> Out of curiosity: Why not fix the code in fsf-compat?
Go right ahead. I'm sure patches would be welcome. :-)
Gerd> Wouldn't that eliminate the code duplication and be the
Gerd> right thing to do?
Being very literal-minded, no. fsf-compat is by definition a
collection of deprecated hacks. If compatibility in the functionality
were considered important, the XEmacs core would get synched.
Rephrasing your question to conform to XEmacs practice, wouldn't
sanctifying the API and making its implementation work right be the
right thing to do? I don't know, it's worth discussion.
But expect some resistance. As in several other cases, in the case of
the GNU timer functions, XEmacs had internal timers ("itimers") and a
well-developed API before GNU did. The purpose of the XEmacs API was
to free us from emulating the buggy and unreliable code that was
previously used. IIRC the XEmacs itimer API is better designed, too.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.