From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: CHENG Gao Newsgroups: gmane.emacs.devel Subject: Re: single init file/directory for windows and linux using version control svn or cvs Date: Fri, 22 Sep 2006 22:31:59 +0800 Organization: eqiao.com Message-ID: References: <45128250.8090009@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: sea.gmane.org 1158935721 28867 80.91.229.2 (22 Sep 2006 14:35:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Sep 2006 14:35:21 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 22 16:35:18 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GQm7N-0003v5-Jz for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2006 16:35:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQm7M-0008R4-72 for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2006 10:35:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GQm79-0008Qd-5M for emacs-devel@gnu.org; Fri, 22 Sep 2006 10:34:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GQm77-0008PO-EA for emacs-devel@gnu.org; Fri, 22 Sep 2006 10:34:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQm77-0008PL-BZ for emacs-devel@gnu.org; Fri, 22 Sep 2006 10:34:49 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GQmAs-0003PO-6X for emacs-devel@gnu.org; Fri, 22 Sep 2006 10:38:42 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GQm5e-0003P6-DD for emacs-devel@gnu.org; Fri, 22 Sep 2006 16:33:18 +0200 Original-Received: from 222.95.227.96 ([222.95.227.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 16:33:18 +0200 Original-Received: from chenggao by 222.95.227.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Sep 2006 16:33:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 125 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 222.95.227.96 User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.0 (darwin) Cancel-Lock: sha1:Dz2Ihi6sz2qZdoP8mMJwaR3mQvc= 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:60109 Archived-At: *On Fri, 22 Sep 2006 15:46:42 +0300 * Eli Zaretskii climbed out of the dark hell and cried out: >> IIRC, there is no fallback dir for HOME under GNU/Linux and BSD, and >> user always (and should) know where HOME is. Why Windoze is so special >> that a (or even some) fallback dir(s) is(are) provided? > > Because a GNU/Linux system _always_ has the HOME environment variable > defined for every user, while a Windows system doesn't. So Emacs that > runs on Windows needs to find some place to look for its per-user files > if HOME is not defined; it cannot rely on the fact that HOME is _always_ > defined. By contrast, a GNU/Linux system where HOME is not defined is > broken in many ways, so Emacs on GNU/Linux does not need to consider > such a situation. Yes I know. Windoze has its HOME, with name as HOMEPATH (for Windoze XP). And you can always set HOME environment var. >> Even Windoze users should know where HOME is. > > I hope by now you understand why they do NOT know. The notion of a HOME > directory simply doesn't exist on Windows. > >> Maybe the clearer and simpler solution is to tell users to set HOME >> dir explicitly in manual. > > That's not a good idea, since one needs a working Emacs to read the > manual. Emacs does not need .emacs to work. Without .emacs, you have a barebone emacs, and you can read Info. > >> If a user can not handle HOME thing, my suggestion is DONT use Emacs. >> notepad.exe is better choice. > > Why treat users harshly when we can solve the issue in the code. As we > have, actually, which is why I think it's pointless to discuss such > suggestions now. Sorry I dont mean to be harsh. I just think things are getting complicated for NT Emacs. CVS Emacs (HEAD and unicode-2 branch) does not add any registry item now. As I read in addpm.c, ,---- | | /* Previous versions relied on registry settings, but we do not need | them any more. If registry settings are installed from a previous | version, replace them to ensure they are the current settings. | Otherwise, do nothing. */ `---- so addpm only updates existed registry items for upgrading installation, and wont add registry for fresh installation. Personally I think avoiding registry is very good decision. So why should NT Emacs depend on registry items as APPDATA or HOMEPATH? It seems contradictory to what new way addpm.c follows. And providing fallbacks to HOME in Windoze seems very bizarre. As I read from Info: ,---- | G.4 HOME Directory on MS-Windows | ================================ | | The Windows equivalent of the `HOME' directory is the "user-specific | application data directory". The actual location depends on your | Windows version and system configuration; typical values are | `C:\Documents and Settings\USERNAME\Application Data' on Windows 2K/XP | and later, and either `C:\WINDOWS\Application Data' or | `C:\WINDOWS\Profiles\USERNAME\Application Data' on the older Windows | 9X/ME systems. | | The home directory is where your init file `.emacs' is stored. When | Emacs starts, it first checks whether the environment variable `HOME' | is set. If it is, it looks for the init file in the directory pointed | by `HOME'. If `HOME' is not defined, Emacs checks for an existing | `.emacs' file in `C:\', the root directory of drive `C:'(1). If | there's no such file in `C:\', Emacs next uses the Windows system calls | to find out the exact location of your application data directory. If | that fails as well, Emacs falls back to `C:\'. `---- So many dirs are scanned for .emacs (or .emacs.el or _emacs or ./emacs.d/init.el etc). My logics is for a dont-know-nothing-about-emacs user, he may have a fresh installation of Emacs, and is it possile that there is some .emacs file miraculously showing in any OPTIONAL PLACE GOOD FOR Emacs INIT FILE? I dont think so. He still need edit a .emacs and put somewhere. He may be happy if he finds he can place it anywhere (as allowed). Maybe he is confused. Who knows. For a user who knows what .emacs is and how to set it, giving several places for init file may be handy, but makes things complicated, and is not in conformity with what Emacs does in other OSes. Is it desirable? BTW, Emacs manual has this part: ,---- | C.5.3 The MS-Windows System Registry | ------------------------------------ | | Under MS-Windows, the installation program `addpm.exe' adds values for | `emacs_dir', `EMACSLOADPATH', `EMACSDATA', `EMACSPATH', `EMACSDOC', | `SHELL' and `TERM' to the `HKEY_LOCAL_MACHINE' section of the system | registry, under `/Software/GNU/Emacs'. It does this because there is | no standard place to set environment variables across different | versions of Windows. Running `addpm.exe' is no longer strictly | necessary in recent versions of Emacs, but if you are upgrading from an | older version, running `addpm.exe' ensures that you do not have older | registry entries from a previous installation, which may not be | compatible with the latest version of Emacs. `---- Seems it's not true any more. As I mentioned above, addpm updates existed registry values if they exist, otherwise, do nothing. I found this while I try to install Mew (I use selfbuilt emacs-unicode-2 branch from latest cvs source). Mew installation under Windoze depends on Windoze registry, and it failed since there is not any Emacs-related registry. I have to run addpm c:\emacs to add these registry items, and installation works then.