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

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

[Kelly Dean]

Lars Ingebrigtsen wrote:
> 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?

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⌝? 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.

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