From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: single init file/directory for windows and linux using version control svn or cvs Date: Sat, 23 Sep 2006 12:57:01 +0300 Message-ID: References: <45128250.8090009@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1159005461 21395 80.91.229.2 (23 Sep 2006 09:57:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Sep 2006 09:57:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 23 11:57:34 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 1GR4GK-0001uo-QI for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 11:57:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GR4GK-0001Lg-EO for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 05:57:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GR4G4-0001Ja-S5 for emacs-devel@gnu.org; Sat, 23 Sep 2006 05:57:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GR4G3-0001Hx-VS for emacs-devel@gnu.org; Sat, 23 Sep 2006 05:57:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GR4G3-0001Hg-Rt for emacs-devel@gnu.org; Sat, 23 Sep 2006 05:57:15 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GR4Jz-0002YX-In for emacs-devel@gnu.org; Sat, 23 Sep 2006 06:01:19 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-212-11.inter.net.il [84.228.212.11]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id FVD16232 (AUTH halo1); Sat, 23 Sep 2006 12:57:00 +0300 (IDT) Original-To: CHENG Gao In-reply-to: (message from CHENG Gao on Fri, 22 Sep 2006 22:31:59 +0800) 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:60131 Archived-At: > From: CHENG Gao > Date: Fri, 22 Sep 2006 22:31:59 +0800 > > > 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). Previous discussions revealed that the directory pointed to by HOMEPATH is not a very good place to put .emacs and other files Emacs creates in the user's home directory. That is why we chose APPDATA instead. But even if we would use HOMEPATH, that would have been already a complication on Windows, since we will need special logic to look in HOME and in C:/, for compatibility with previous versions of Emacs and with users who do set HOME. > > 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. Not always. For example, if the user has INFOPATH set, it overrides the built-in defaults, and the Emacs manual might become inaccessible. In my experience, it is not a good idea to expect users to read the manual for important features to work. > So why should NT Emacs depend on registry items as APPDATA or HOMEPATH? It > seems contradictory to what new way addpm.c follows. We don't depend on the registry, we use existing OS features. The fact that the OS records them in the registry is irrelevant, as long as those feature can be reasonably assumed to always exist. > So many dirs are scanned for .emacs (or .emacs.el or _emacs or > ./emacs.d/init.el etc). This happens only once, when Emacs starts up. It looks for the directory with .emacs, and records what it found. Thereafter, it just uses that value. So I don't see a performance issue here. > 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. If there's no previous .emacs, then nothing bad happens. The complicated logic is for users of previous versions who upgrade to Emacs 22. > 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? It is desirable, because users of previous versions might have their .emacs in C:/. > 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. You are right; I will fix this part. Thanks. > 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. Sounds like Mew installation needs to be updated, too.