bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Dani Moncayo]

Hi,

1.- Set up a Windows XP system in such way that Emacs, during its
statup, can't find any possible "init file" (.emacs, .emacs.el,
.init.el, ...) in any of the possible paths it may look for (see [1]).

2.- Create a brand new emacs init file with the single sentence (setq
inhibit-startup-screen t), and save it as "c:\_emacs".

3.- Start emacs "normally" (whithout -Q, because we want to test the
search of our init file).


According to [1], Emacs should be able to find (and execute) the init file
created in #2, i.e., the statup screen should NOT be shown. But in fact
it is, i.e., Emacs could not find the file.

[1] (info "(emacs) Windows HOME")


-- 
Dani Moncayo

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-02-28 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ESN
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Juanma Barranquero]

On Thu, Mar 10, 2011 at 21:40, Dani Moncayo <dmoncayo@gmail.com> wrote:

> According to [1], Emacs should be able to find (and execute) the init file
> created in #2, i.e., the statup screen should NOT be shown. But in fact
> it is, i.e., Emacs could not find the file.

The wording is a bit ambiguous, because it only says

  [...] the Windows port of Emacs supports an alternative name `_emacs'
  as a fallback, if such a file exists in the home directory, whereas
  `.emacs' does not.

and the paragraphs before that one aren't 100% specific about whether
in this case "the home directory" means the directory pointed by the
HOME environment variable, or all searched ones. I'd say the former,
but the comment

  Whatever the final place is, Emacs sets the value of the `HOME'
  environment variable to point to it,

makes this less than clear-cut, and in fact, the order in which
[._]emacs is searched (I'm ignoring ~/.emacs.d/init.el) is

  %HOME%\.emacs
  %HOME%\_emacs
  C:\.emacs
  %APPDATA%\.emacs
  %APPDATA%\_emacs

so there *is* an inconsistency. That said, _emacs is an obsolete name
(on Windows, not MS-DOS), so it's not worth changing this IMO.

    Juanma

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Jason Rumney]

On 11/03/2011 10:35, Juanma Barranquero wrote:

> makes this less than clear-cut, and in fact, the order in which
> [._]emacs is searched (I'm ignoring ~/.emacs.d/init.el) is
>
>    %HOME%\.emacs
>    %HOME%\_emacs
>    C:\.emacs
>    %APPDATA%\.emacs
>    %APPDATA%\_emacs
>    

More accurately, if %HOME% is set explicitly, then init files are 
searched there.
Otherwise if c:\.emacs exists, then %HOME% is implicitly set to C:\ (for 
backwards compatibility with older versions)
Otherwise %HOME% is implicitly set to the user's Application Data 
directory, obtained through system calls.
(ignoring the fact that these system calls are not available on Windows 
95 and NT4 without IE5 or later installed, since such systems are 
unlikely to still exist).


> so there *is* an inconsistency. That said, _emacs is an obsolete name
> (on Windows, not MS-DOS), so it's not worth changing this IMO.
>    

This is the first bug report since the change was made in 22.1 (I 
think). And it appears the user is not encountering problems upgrading 
an older working installation but trying to set up a new installation, 
so I agree it is not important to fix this now.  In fact, we could start 
issuing a warning if the fallback directory of C:\ is detected as being 
used in Emacs 24, so we can remove this fallback in a future release.

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Juanma Barranquero]

On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr@gnu.org> wrote:

> More accurately, if %HOME% is set explicitly, then init files are searched
> there.
> Otherwise if c:\.emacs exists, then %HOME% is implicitly set to C:\ (for
> backwards compatibility with older versions)

Well, sort of, because when HOME is implicitly set to C:\, only the
existence of .emacs is checked, not _emacs, while the same is not true
for an explicit HOME or for the AppData directory.

> In fact, we could start issuing a warning
> if the fallback directory of C:\ is detected as being used in Emacs 24, so
> we can remove this fallback in a future release.

Yes, I think that's a good idea.

    Juanma

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Dani Moncayo]

On Fri, Mar 11, 2011 at 07:42, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr@gnu.org> wrote:
>
>> More accurately, if %HOME% is set explicitly, then init files are searched
>> there.
>> Otherwise if c:\.emacs exists, then %HOME% is implicitly set to C:\ (for
>> backwards compatibility with older versions)
>
> Well, sort of, because when HOME is implicitly set to C:\, only the
> existence of .emacs is checked, not _emacs, while the same is not true
> for an explicit HOME or for the AppData directory.
>
Yes, and I wonder why to have this inconsistency. Why don't check
always for the same alternatives of init file? Even when checking
under "C:\"?.

>> In fact, we could start issuing a warning
>> if the fallback directory of C:\ is detected as being used in Emacs 24, so
>> we can remove this fallback in a future release.
>
> Yes, I think that's a good idea.
>
Fine by me too.


-- 
Dani Moncayo

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Eli Zaretskii]

> Date: Fri, 11 Mar 2011 10:33:26 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 8220@debbugs.gnu.org
> 
> On Fri, Mar 11, 2011 at 07:42, Juanma Barranquero <lekktu@gmail.com> wrote:
> > On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr@gnu.org> wrote:
> >
> >> More accurately, if %HOME% is set explicitly, then init files are searched
> >> there.
> >> Otherwise if c:\.emacs exists, then %HOME% is implicitly set to C:\ (for
> >> backwards compatibility with older versions)
> >
> > Well, sort of, because when HOME is implicitly set to C:\, only the
> > existence of .emacs is checked, not _emacs, while the same is not true
> > for an explicit HOME or for the AppData directory.
> >
> Yes, and I wonder why to have this inconsistency. Why don't check
> always for the same alternatives of init file? Even when checking
> under "C:\"?.

Because we want to deprecate both C:\.emacs and the _emacs features.

bug#8220: 24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup

[Eli Zaretskii]

> Date: Fri, 11 Mar 2011 13:56:03 +0800
> From: Jason Rumney <jasonr@gnu.org>
> Cc: 
> 
> On 11/03/2011 10:35, Juanma Barranquero wrote:
> 
> > makes this less than clear-cut, and in fact, the order in which
> > [._]emacs is searched (I'm ignoring ~/.emacs.d/init.el) is
> >
> >    %HOME%\.emacs
> >    %HOME%\_emacs
> >    C:\.emacs
> >    %APPDATA%\.emacs
> >    %APPDATA%\_emacs
> >    
> 
> More accurately, if %HOME% is set explicitly, then init files are 
> searched there.
> Otherwise if c:\.emacs exists, then %HOME% is implicitly set to C:\ (for 
> backwards compatibility with older versions)
> Otherwise %HOME% is implicitly set to the user's Application Data 
> directory, obtained through system calls.

I tried to explain this algorithm in the manual in more user-friendly
terms.  Please take a look (posted in another mail in bug #8221).