bug#19068: Mail file vars aren't derived from customized message-directory

[Ivan Shmakov]

>>>>> Kelly Dean <kelly@prtime.org> writes:
>>>>> Lars Ingebrigtsen wrote:

        [Cc: 19068@, as the discussion still seems relevant to the bug.]

 >> That's the wrong way to set variables that have other variables that
 >> depend on them.

 >> Instead say

 >> (setq message-directory "~/mail/") (require 'message)

 > And what if you happened to previously require something that already
 > required message?  Do you want to require users to always put all
 > their «setq»s before all their «require»s, just in case?

        As long as we speak about ~/.emacs, my free advice to the users
        would be to ‘setq’ first, and ‘require’ never.

        That is: if the user needs an explicit ‘require’ there, it’s
        quite likely that something is already broken.  Normally, all
        the Emacs packages’ “entry points” are autoloaded, and enabling
        a particular function should be just a matter of setting up a
        specific hook, or adding an entry to a specific alist, etc.

        In the worst case, the user may need to add an ‘autoload’ form
        to his or her own ~/.emacs, if one’s somehow missing from the
        package’s own .el (or loaddefs.el, or the user’s own private
        analogue thereof.)

 > Or what if you were already using message mode with the default
 > directory settings, but then you decided to change it and customize
 > message-directory using Emacs's customization feature, and read the
 > help page that says ⌜Directory from which all other mail file
 > variables are derived⌝?

        I agree that the docstring for this variable is misleading, – it
        is /not/ the usual semantics for a variable to change when some
        other variable (however related) is changed, – neither in
        Emacs Lisp, nor in the majority of the programming languages
        I know.  (One notable exception being Make.)

        That’s contrary to, say, Gnus “group parameters,” which are
        reconsidered something like every time the group is accessed.
        I guess it’s possible to reimplement message-directory and its
        “dependent” variables in a similar manner, but I doubt it’d
        worth the effort.

 > Would you not expect that when you change a top-level directory, the
 > directories under it remain under it?  After all, that's the way «mv»
 > behaves.

        To continue with the analogy, if you $ dir=~/mail in the shell,
        and then $ mv ~/mail ~/othername, would you expect for ${dir} to
        still refer to the same directory, – now known as ~/othername?

-- 
FSF associate member #7257  np. Omega — Bruce Dickinson … 3013 B6A0 230E 334A