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

From: "Drew Adams" <[email-masked]>
Date: Fri, 11 Mar 2011 09:34:51 -0800

> > > > Not according to the docs, which clearly say that it is "for
> > > > compatibility with older versions of Emacs".
> > > 
> > > Actually, it's for compatibility with older versions of _Windows_,
> > 
> > So there is a doc bug, anyway.
>
> ??? Where?  The doc doesn't say anything different.

Juanma quoted a phrase that says that this is for compatibility with older
_Emacs_ versions.  _You_ corrected him.

If the passage quoted is in fact in the doc (Juanma said "according to the
docs"), and if your correction of that passage is valid, then your correction
applies equally well to the quoted doc.

> > That was the reason for _introducing_ support for `_emacs'. 
> > It does not at all follow that when that reason is no longer
> > pertinent we should _deprecate_ support for `_emacs'.
> 
> It does, if there are no other reasons to keep it.

I gave reasons.

BTW, what are the reasons for keeping `.emacs'?
"If there are no reasons to keep it" then...

(But I personally have no quibble with supporting `.emacs' also.)

> > IMO `_emacs' is just as good a default name as `.emacs', if 
> > not better.  One could just as well argue that `.emacs'
> > should be desupported.
> 
> One could argue that, but why would one want to, unless one wanted to
> get silly.

It is just as silly to argue that `_emacs' should be desupported.
That's the point.

> > Certainly `.emacs' has the special property on some OS's 
> > that it is a hidden file.
> 
> `.emacs' is not a hidden file on any platform that I know of.  `ls'
> does not show files that start with a period,

Exactly what I meant.  That is a special treatment for files that begin with `.'
on certain platforms.  Google "dot file" and you will soon see...

Quoting Wikipedia (http://en.wikipedia.org/wiki/Configuration_file):

 On UNIX variants dot files remain "hidden" from listing by
 default.  On Mac OS X these files are sometimes called
 "hidden files" although other mechanisms exist on Mac OS X
 to hide a file from view in various tools.  The Explorer
 interface of Microsoft Windows XP does not allow the user to
 rename a file with an initial '.' though it does allow access
 to such files, and Windows' Notepad program does allow files
 to be saved with such names.  Where Unix programs that use
 dotfiles are ported to Windows, they are sometimes modified
 to accept some other naming convention; for example, GNU
 Emacs permits its configuration file to be named _emacs
 instead of .emacs.

Beyond `ls'...  File names with base part and extension are
common across platforms.  File names with only a base part
(no extension) are also common across platforms.  But file
names that consist of only a `.' followed by an extension
are not so common across platforms.

> > `_emacs' has no such special property on any platform 
> > AFAIK.  Similarly, that can be both an advantage and a
> > disadvantage.
> 
> Emacs is about uniformity of user experience on all platforms, and
> about living up to user expectations on all platforms.  `_emacs' is a
> deviation from that uniformity.

On the contrary.  `_emacs' behaves similarly across platforms.
`.emacs' does not, as you confirmed wrt `ls'.

> It was introduced out of necessity (and on DOS, it still is a
> necessity).  But now that the necessity is gone, it's time to
> correct this deviation.

There is no deviation, and nothing to correct.

It does not follow at all that because the reason for its _introduction_ is no
longer relevant a feature should be removed.  That's not logical.  It does not
matter why it was introduced.  What matters is whether it is a useful feature.

`_emacs' is useful now, as before, precisely because its behavior is
platform-independent.

(And it is generally tools-independent - it's quite possible that some tools
barf or misbehave with a file name that is only `.' followed by an extension.)

> > Just one user's opinion: Keep support for `_emacs' as a 
> > default init-file name; and extend it to any platforms
> > where it is not already supported.
> 
> Sorry, but the converse decision was made a long time ago.

Too bad.  Wonder what the _logic_ was behind that...