Re: project variable patch #2

[Stefan Monnier]

>       * custom.texi (Project Variables): New node.

Since the variables specified inside a file are called "file variables" or
"file-local variables", why not call them "directory variables" or
"directory-local variables"?

This way the name expresses the behavior more directly rather than the
intended/expected use case.

Actually, base on this, we could call the file ".dir-variables.el" (just
like the "File Variables:" section in files).  But I guess "dir-settings.el"
is just as good (after all, it may set more than just variables).

> +      (make-local-variable variable)
> +      (set variable value))))

I recommend (set (make-local-variable variable) value), so as to make the
link between the two statements more immediately obvious.

By the way, how about using major-mode derivation, so that if you add
settings for text-mode, they'll apply to all derivatives of text-mode
(e.g. latex-mode, outline-mode, message-mode, ...).

> +    ;; Special case C and derived modes.  Note that CC-based modes
> +    ;; don't work with derived-mode-p.  FIXME: this is arguably an
> +    ;; Emacs bug.  Perhaps we should be running
> +    ;; hack-local-variables-hook here instead?
> +    (and (boundp 'c-buffer-is-cc-mode)
> +      c-buffer-is-cc-mode
> +      (c-postprocess-file-styles))))

I don't understand what this is referring to.  Could it be fixed by changes
in CC-modes?

> +  (setq project-directory-alist
> +     (cons (cons directory class)
> +           project-directory-alist)))

Aka (push (cons directory class) project-directory-alist)

> +;; There's a few ways we could do this.  We could use VC (with a VC
> +;; extension) and look for the root directory.  Or we could chain
> +;; settings files.  For now we choose a simple approach and let the
> +;; project maintainers be smart.
> +(defun project-find-settings-file (file)
> +  "Find the settings file for FILE.
> +This searches upward in the directory tree.
> +If a settings file is found, the file name is returned.
> +If the file is in a registered project, a cons from
> +`project-directory-alist' is returned.
> +Otherwise this returns nil."
> +  (let ((dir (file-name-directory file))
> +     (result nil))
> +    (while (and (not (string= dir "/"))
> +             (not result))
> +      (cond
> +       ((setq result (assoc dir project-directory-alist))
> +     ;; Nothing else.
> +     nil)
> +       ((file-exists-p (concat dir ".dir-settings.el"))
> +     (setq result (concat dir ".dir-settings.el")))
> +       (t
> +     (setq dir (file-name-directory (directory-file-name dir))))))
> +    result))

Why not use the new function locate-dominating-file ?

> +(defun project-find-file ()
> +  "Set local variables in a buffer based on project settings."

The name suggests it's going to do a sort of `find-file', which seems wrong
considering the docstring.  How 'bout hack-directory-local-variables?


        Stefan