Re: files.el: Patch to make project-settings optional/customizable

[Juri Linkov]

> So there are 2 uses .dir-locals.el 3 lines apart in the same 24 lines 
> function.
> The defconst adds 4 lines.  It's hard to keep a straight face and claim
> that the defconst is a good idea.
> (and the 2 uses could be reduced to a single one if we make
> locate-dominating-file return an expanded file name -- which seems to be
> a good idea anyway).
>
> It's kind of painful that this discussion is still going on, it should
> have never occurred in the first place...

I can't believe we have this kind of discussion :(

All packages with similar functionality have defcustom for the file name.

dir-locals.el:

(defcustom dir-locals-file-name ".emacs-locals"
  "File name used by Dir-Locals mode to specify local variables.
This should specify local variables in the normal way.  When Dir-Locals
minor mode is active, these will be inherited by files found in a
directory tree containing such a file at its root.
This may also be a function of no arguments which returns the name to
use, allowing arbitrary per-directory customization of the
per-directory customization file on the basis of `default-directory'."
  :group 'dir-locals
  :type '(choice file function))

dirvars.el:

(defcustom dirvars-file-name ".emacs-dirvars"
  "File base name that is loaded by dirvars."
  :type 'string)

dir-locals.el was created in 2005 and dirvars.el in 2002.
For several years they provided customization without problems.

Our discussion reached the need to make this file name constant.
I'm ok with this conclusion.  So I created defconst because it
explicitly says that the file name should not be modified by the user,
unlike if it was hidden in the function dir-locals-find-file where users
will be the temptation to redefine the whole function without understanding
that the file name have to be constant.

PS: Reading the docstring of dir-locals-file-name in dir-locals.el
seems to indicate that users trying to switch from dir-locals.el
to similar functionality implemented now in files.el will be annoyed
by its limitations but I'll leave this for another discussion where
we will argue with the users of these packages.

-- 
Juri Linkov
http://www.jurta.org/emacs/