emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: single init file/directory for windows and linux using version contr


From: Eli Zaretskii
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

> From: CHENG Gao <address@hidden>
> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]