sendmail-program default is determined at compilation time

sendmail-program default is determined at compilation time

[Toby Allsopp]

It seems that the default for sendmail-program is determined at
(Emacs) compilation time, which means that if the situation is
different at run time (e.g. if Emacs was compiled on a different
machine, as is the case for binary packages for e.g. Debian) the
default could be inappropriate.

sendmail-program is defined in paths.el as:

(defcustom sendmail-program
  (cond
    ((file-exists-p "/usr/sbin/sendmail") "/usr/sbin/sendmail")
    ((file-exists-p "/usr/lib/sendmail") "/usr/lib/sendmail")
    ((file-exists-p "/usr/ucblib/sendmail") "/usr/ucblib/sendmail")
    (t "fakemail"))			;In ../etc, to interface to /bin/mail.
  "Program used to send messages."
  :group 'mail
  :type 'file)

My problem is that the default for the Debian emacs-snapshot package
version 20060824-1 is "fakemail" because the machine that builds it
doesn't have sendmail installed.  I, however, do have
/usr/sbin/sendmail, but that isn't taken into account.

Is this the expected behaviour?

Toby.

Re: sendmail-program default is determined at compilation time

[Richard Stallman]

    sendmail-program is defined in paths.el as:

I think that just moving it to sendmail.el would prevent the value
from being chosen at dump time.  Does that work?

Whether to do this requires a little bit of thought.  I think it was
put in paths.el specifically so that the value would be chosen at dump
time.  I think the motive for that was to save time when first loading
sendmail.el.

It is possible that the delay is now insignificant.
Would people please try that change?

Re: sendmail-program default is determined at compilation time

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     sendmail-program is defined in paths.el as:
>
> I think that just moving it to sendmail.el would prevent the value
> from being chosen at dump time.  Does that work?
>
> Whether to do this requires a little bit of thought.  I think it was
> put in paths.el specifically so that the value would be chosen at dump
> time.  I think the motive for that was to save time when first loading
> sendmail.el.
>
> It is possible that the delay is now insignificant.
> Would people please try that change?

The delay is indeed insignificant.

There is one complication: putting sendmail-program in sendmail.el
means that it won't be available unless sendmail.el is loaded (unless
we autoload it, which defeats the purpose of setting its default at
compile time).  I don't know if any other parts of Emacs assume it is
available.

At worst, we could initialize it in startup.el.

Re: sendmail-program default is determined at compilation time

[Richard Stallman]

    There is one complication: putting sendmail-program in sendmail.el
    means that it won't be available unless sendmail.el is loaded (unless
    we autoload it, which defeats the purpose of setting its default at
    compile time).  I don't know if any other parts of Emacs assume it is
    available.

feedmail.el and gnus/message.el use it.  I think it is better to make
them load sendmail.el if they need to, than to make startup.el
initialize the variable.  That way it won't add to the time
for starting Emacs (such delays add up).

Could you please DTRT?

Re: sendmail-program default is determined at compilation time

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     There is one complication: putting sendmail-program in sendmail.el
>     means that it won't be available unless sendmail.el is loaded (unless
>     we autoload it, which defeats the purpose of setting its default at
>     compile time).  I don't know if any other parts of Emacs assume it is
>     available.
>
> feedmail.el and gnus/message.el use it.  I think it is better to make
> them load sendmail.el if they need to, than to make startup.el
> initialize the variable.  That way it won't add to the time
> for starting Emacs (such delays add up).
>
> Could you please DTRT?

It's wrong for feedmail.el and message.el to load sendmail.el, since
they currently go to some lengths to avoid doing exactly that;
however, it's trivial for them to look for sendmail on the fly if
sendmail-program isn't bound.  I've checked in a fix.