From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Don't concat directories to file names Date: Fri, 15 Jun 2007 23:19:19 +0900 Message-ID: <87hcp9cnbs.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wsy6cvip.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5u5cydi.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181916543 21093 80.91.229.12 (15 Jun 2007 14:09:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2007 14:09:03 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 15 16:09:01 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 1HzCU0-0006Cf-S4 for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 16:09:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzCU0-0002FS-Cu for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 10:09:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzCTw-0002CR-Ie for emacs-devel@gnu.org; Fri, 15 Jun 2007 10:08:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzCTu-0002AS-M1 for emacs-devel@gnu.org; Fri, 15 Jun 2007 10:08:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzCTu-0002AM-Hm for emacs-devel@gnu.org; Fri, 15 Jun 2007 10:08:54 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HzCTs-00039x-KG; Fri, 15 Jun 2007 10:08:53 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 063857FFC; Fri, 15 Jun 2007 23:08:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 785A81A260D; Fri, 15 Jun 2007 23:19:20 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" (+CVS-20070324) XEmacs Lucid X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:72954 Archived-At: Juanma Barranquero writes: > Then the recently introduced `user-emacs-directory' should be renamed > to `user-init-directory', or aliased, I think (but it doesn't make > much sense to alias a just created var). The variable currently must > end with a directory separator, but that could be fixed. I think requiring the directory separator on the variable is reasonable; after all, in most cases it will be determined implicitly at startup or by a function call. The trick of doing (defun user-init-directory () "Return the per-user directory holding Emacs configuration files." (if (and (boundp 'user-init-directory) (file-directory-p user-init-directory)) user-init-directory (find-user-init-directory))) ; this may be oversimplified is always available, too. > (defun user-emacs-file (name &optional new-name) > "Convert NAME to an absolute per-user Emacs-specific path. > If \"~/NAME\" exists, or `user-emacs-directory' is nil, return \"~/NAME\". > Else, return \"`user-emacs-directory'/NEW-NAME\", or /NAME if NEW-NAME is nil." Looks reasonable to me. FWIW, existing XEmacs practice is to encourage use of `user-init-directory' by looking there first (for our startup files; we don't have the API you are proposing yet, so other libraries have to code by hand). Also, if ~/.emacs is found, ~/.xemacs/ doesn't exist, and migration is not inhibited, XEmacs offers to migrate its files (.emacs and optionally custom.el) from $HOME to `user-init-directory'. If you say no, you get the option of trying again later, or telling XEmacs not to bug you any more. > People wanting to use the same setup files in X?Emacs will have to > make user-(emacs|init)-directory point to the right place, or perhaps > set it to nil (and then `user-emacs-file' defers to ~/ and does not > try to create any dir). XEmacs has -user-init-file and -user-init-directory options to handle this (as well as the -u option). I'm at my limit here: I can imagine use cases for all this flexibility, but I've never encountered them in the wild. I think that `user-emacs-directory' and `user-init-directory' have similar enough semantics that it would be nice if the variable name could be the same. I'd like to claim priority for `user-init-directory': it's over ten years old in XEmacs. Other than that, it's not at all obvious to me that any of XEmacs's APIs or UIs in this area are used often enough to worry about incompatibility. I'm not a big fan of the name "user-emacs-file" for the function you've defined; for me, even after all this time using the ~/.xemacs/init.el style, I think it should point to ".emacs". How does "user-configuration-file" or "find-user-configuration-file" sound? (Of course "configuration" could be shortened to "config".)