Re: time.el and display-time-mail-function

[Jason Bastek]

>>> "RMS" == Richard M Stallman <address@hidden> writes:

  RMS>     where display-time-mail-function is a user-definable
  RMS>     function, which seems like the perfect thing for my
  RMS>     situation.  The problem is the "or" -- if my
  RMS>     display-time-mail-function returns nil (to indicate that
  RMS>     there is no new mail), instead of stopping there, it will
  RMS>     continue with the standard mail-spool-file check.

  RMS> Why do you think that is undesirable?

My reasoning is as follows:

The purpose of this function display-time-update is (essentially) to
determine whether there is new mail.  It provides the user with a
customizable function, display-time-mail-function.  So I would think
that, if I go to the trouble of defining this function, I want the
semantics to be:

   my function returns t    => there is new mail
   my function returns nil  => there is no new mail

But because of the "or", the semantics are:

   my function returns t    => there is new mail
   my function returns nil  => try other ways of checking for new mail

And in my case, the other way of checking for new mail returns an
incorrect answer.  This is because my environment variable MAIL now
points to a directory, not a file, and the code ends up calling
file-attributes on this directory, and looking at the size in bytes to
see if it's >0.  For a directory, the size in bytes will always be >0,
therefore the code will always report that there is new mail.

I notice that there is a newer version of time.el with some code to do
the directory-based check, which is nice, and will probably fix my
problem.  But the code still uses "or", so it will run into the same
problem if MAIL is pointing to a directory rather than a file (and the
other mail-checking methods return nil).

  RMS> If there's no mail in the other place, but there is mail
  RMS> in the standard place, the current code will say you have mail.
  RMS> Why is that a problem?

I think this is explained above -- the current code assumes that
mail-spool-file points to a mail file to be checked.  But in my case
(and the case of anyone else whose system is using maildir rather than
mbox), there is no such file, there's only a directory.  So because of
the "or", failures to find new mail using user-defined methods will
always fall back on the checking of mail-spool-file for non-zeroness.
This will result in a false positive.

This can be worked around in several ways (undefining the env var
MAIL, setting display-time-mail-file to t, etc), but I see those as
hacks around the problem of the "or".  Changing it to a "cond" seems
to do the more correct thing.

If people are relying on the "or" behavior because they have several
mail drops, perhaps time.el should be redesigned to allow for this
(have a user-definable list of mail files to check).  But as it stands
it's definitely broken for me.

-Jason