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

[Ivan Shmakov <ivan@siamics.net>]

>>>>> 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