From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: project variable patch #2 Date: Sun, 09 Sep 2007 22:52:53 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189395265 25925 80.91.229.12 (10 Sep 2007 03:34:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 Sep 2007 03:34:25 +0000 (UTC) Cc: Emacs Hackers To: tromey@redhat.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 10 13:34:12 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IUgtF-0000iB-MO for ged-emacs-devel@m.gmane.org; Mon, 10 Sep 2007 12:53:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUZOj-00088w-0m for ged-emacs-devel@m.gmane.org; Sun, 09 Sep 2007 22:53:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUZOg-00088q-6G for emacs-devel@gnu.org; Sun, 09 Sep 2007 22:53:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUZOc-00085L-N9 for emacs-devel@gnu.org; Sun, 09 Sep 2007 22:53:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUZOc-00085I-Jy for emacs-devel@gnu.org; Sun, 09 Sep 2007 22:53:06 -0400 Original-Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUZOb-0004yF-3J for emacs-devel@gnu.org; Sun, 09 Sep 2007 22:53:06 -0400 Original-Received: from pastel.home ([70.55.141.227]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070910025253.DXFV8273.tomts20-srv.bellnexxia.net@pastel.home> for ; Sun, 9 Sep 2007 22:52:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C1D508075; Sun, 9 Sep 2007 22:52:53 -0400 (EDT) In-Reply-To: (Tom Tromey's message of "Sun\, 09 Sep 2007 17\:16\:58 -0600") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:78404 Archived-At: > * 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