GNU bug report logs -
#8220
24.0.50; (On Windows XP) "c:\_emacs" isn't found during startup
Previous Next
Reported by: Dani Moncayo <dmoncayo <at> gmail.com>
Date: Thu, 10 Mar 2011 20:41:02 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8220 in the body.
You can then email your comments to 8220 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs.
(Thu, 10 Mar 2011 20:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dani Moncayo <dmoncayo <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 10 Mar 2011 20:41:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs,w32.
(Fri, 11 Mar 2011 02:37:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 8220 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 10, 2011 at 21:40, Dani Moncayo <dmoncayo <at> 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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs,w32.
(Fri, 11 Mar 2011 05:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs,w32.
(Fri, 11 Mar 2011 06:44:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 8220 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr <at> 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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs,w32.
(Fri, 11 Mar 2011 09:34:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 8220 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 07:42, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr <at> 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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 11 Mar 2011 11:24:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dani Moncayo <dmoncayo <at> gmail.com>:
bug acknowledged by developer.
(Fri, 11 Mar 2011 11:24:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 11 Mar 2011 10:33:26 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 8220 <at> debbugs.gnu.org
>
> On Fri, Mar 11, 2011 at 07:42, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> > On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr <at> 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8220; Package
emacs,w32.
(Fri, 11 Mar 2011 11:26:02 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 11 Mar 2011 13:56:03 +0800
> From: Jason Rumney <jasonr <at> 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).
Message #26 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 12:23, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 11 Mar 2011 10:33:26 +0100
>> From: Dani Moncayo <dmoncayo <at> gmail.com>
>> Cc: 8220 <at> debbugs.gnu.org
>>
>> On Fri, Mar 11, 2011 at 07:42, Juanma Barranquero <lekktu <at> gmail.com> wrote:
>> > On Fri, Mar 11, 2011 at 06:56, Jason Rumney <jasonr <at> 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.
>
Thanks, Eli and Juanma.
--
Dani Moncayo
Message #27 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 12:29, Dani Moncayo <dmoncayo <at> gmail.com> wrote:
>
> Thanks, Eli and Juanma.
>
...oops, and Jason (everyone who spent time o this) ;)
--
Dani Moncayo
Message #28 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> > > 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.
A bug, IMO.
> > 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.
Too bad. $HOME as c:\ should not be treated differently from other dirs as
$HOME.
And _emacs is a longstanding, positive feature, not something that should be
removed.
Just one opinion.
Message #29 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 15:47, Drew Adams <drew.adams <at> oracle.com> wrote:
> Too bad. $HOME as c:\ should not be treated differently from other dirs as $HOME.
It isn't, if you set HOME to C:\. Which you should, IMHO, if you want
to use it as home.
> And _emacs is a longstanding, positive feature, not something that should be
> removed.
Not according to the docs, which clearly say that it is "for
compatibility with older versions of
Emacs". Sooner or later it's time to go forward and abandon such cruft.
> Just one opinion.
Same here.
Juanma
Message #30 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 11 Mar 2011 16:20:51 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dani Moncayo <dmoncayo <at> gmail.com>, 8220-done <at> debbugs.gnu.org
>
> > And _emacs is a longstanding, positive feature, not something that should be
> > removed.
>
> 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_,
and, more importantly, for helping users migrate from DOS (which
simply doesn't allow file names that begin with a period). That
migration is all over by now; whoever still uses DOS will never go to
Windows on the same machine. So it's time to deprecate that old
feature, which makes documentation harder and Emacs operation
trickier.
Message #31 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> > > And _emacs is a longstanding, positive feature, not
> > > something that should be removed.
> >
> > 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.
> and, more importantly, for helping users migrate from DOS (which
> simply doesn't allow file names that begin with a period). That
> migration is all over by now; whoever still uses DOS will never go to
> Windows on the same machine. So it's time to deprecate that old
> feature, which makes documentation harder and Emacs operation
> trickier.
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 is very common in many types of evolution that an entity comes into being for
one reason but becomes co-opted and kept for other reasons.
http://en.wikipedia.org/wiki/Spandrel_(biology)
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.
Certainly `.emacs' has the special property on some OS's that it is a hidden
file. That special property can be both an advantage and a disadvantage. And
it is a platform-specific special property. And just creating `.emacs' on some
platforms (e.g. Windows) invariably prompts user questions - how to do so is a
FAQ, even if the answer is simple.
`_emacs' has no such special property on any platform AFAIK. Similarly, that
can be both an advantage and a disadvantage.
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.
Message #32 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dmoncayo <at> gmail.com>, <8220-done <at> debbugs.gnu.org>
> Date: Fri, 11 Mar 2011 08:40:02 -0800
>
> > > > And _emacs is a longstanding, positive feature, not
> > > > something that should be removed.
> > >
> > > 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.
> 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.
> 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.
> 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, but that's a "feature"
of that application, those files are not otherwise special in any way.
There's no hidden attribute on it, just because its name starts with a
period.
> `_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. 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.
> 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.
Message #33 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> > > > 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...
Message #34 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 18:34, Drew Adams <drew.adams <at> oracle.com> wrote:
> If the passage quoted is in fact in the doc (Juanma said "according to the
> docs"),
When I quote, I quote :-)
But... the passage I quoted is the footnote in the Emacs manual page
"G.5 HOME and Startup Directories on MS-Windows", and the footnote
does not talk about _emacs, but about checking C:\ for .emacs. Both
things are related, but perhaps the way I brought up the quote was
misleading. Sorry.
Juanma
Message #35 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 18:34, Drew Adams <drew.adams <at> oracle.com> wrote:
> It is just as silly to argue that `_emacs' should be desupported.
> That's the point.
I disagree.
> On the contrary. `_emacs' behaves similarly across platforms.
No, it doesn't, because non-DOS, non-Windows Emacsen do not load _emacs.
Yes, you're talking of `ls' and/or `dir', but the point is that you're
arguing in favor of keeping an old compatibility feature by
*extending* it, making detection of [._]emacs(.elc?)? / init.el (and,
more important, explaining how that detection is done) no less complex
on Windows/DOS, and more complex on POSIX environments. For a net gain
of... what?
Juanma
Message #36 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> > Too bad. $HOME as c:\ should not be treated differently
> > from other dirs as $HOME.
>
> It isn't, if you set HOME to C:\.
I misunderstood from the thread that if you set HOME to c:\ it will be handled
differently wrt the default init-file names that are considered.
> Which you should, IMHO, if you want to use it as home.
I agree. Implicit c:\ should be abandoned (deprecated).
> > And _emacs is a longstanding, positive feature, not
> > something that should be removed.
>
> Not according to the docs, which clearly say that it is "for
> compatibility with older versions of Emacs". Sooner or later
> it's time to go forward and abandon such cruft.
My opinion differs from this (doc and your opinion). I think `_emacs' is a fine
name and should be supported, regardless of platform and regardless of the
history behind it.
> > Just one opinion.
>
> Same here.
Message #37 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
> > It is just as silly to argue that `_emacs' should be desupported.
> > That's the point.
>
> I disagree.
>
> > On the contrary. `_emacs' behaves similarly across platforms.
>
> No, it doesn't, because non-DOS, non-Windows Emacsen do not
> load _emacs.
It behaves similarly as a _file_ - that's what I meant. Most platforms do not
treat `_emacs' specially because of its _file name_. Many platforms do treat
`.emacs' specially because of its _file name_.
My point was that `_emacs' _should_ be handled by Emacs as a default init-file
name on all platforms, just as it is handled that way on Windows. Why? Because
it's a good, simple name that is not treated specially by different platforms.
> Yes, you're talking of `ls' and/or `dir', but the point is that you're
> arguing in favor of keeping an old compatibility feature by
> *extending* it, making detection of [._]emacs(.elc?)? / init.el (and,
> more important, explaining how that detection is done) no less complex
> on Windows/DOS, and more complex on POSIX environments. For a net gain
> of... what?
Shouldn't be complex.
The gain is simplicity: `_emacs' is simpler than `.emacs' because it is not a
name that is handled specially on various platforms.
I'd say keep `.emacs' handling too, so that users on UNIX or GNU/Linux can, if
they want, take advantage of the special treatment of dot files.
But allow `_emacs' also as a default init-file name.
Anyway, as Eli has said, this is all moot - it has already been decided.
Message #38 received at 8220-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 11, 2011 at 18:59, Drew Adams <drew.adams <at> oracle.com> wrote:
> It behaves similarly as a _file_ - that's what I meant.
Yes, I know. I said as much in the next paragraph.
> Most platforms do not
> treat `_emacs' specially because of its _file name_. Many platforms do treat
> `.emacs' specially because of its _file name_.
That's true, but that does not concern Emacs. For users of POSIX
systems, that treatment is expected and welcome; for Windows it is not
treated specially (other than the difficulty of creating it on older
Windows), and users do expect that too. It's specialness is not a
problem for anyone.
> Why? Because
> it's a good, simple name that is not treated specially by different platforms.
I don't see why is that a plus. On a POSIX system, I would expect my
Emacs configuration file to be hidden, as I would expect it from the
configuration files of most other applications. Having _emacs around
on Ubuntu, for example, would be ugly IMHO; I very much doubt I would
chose to use _emacs in preference to .emacs.
> Shouldn't be complex.
Meaning what? I'm not talking about complexity from a OS point of
view, but Emacs'. And this very bug report thread is a witness to the
fact that it is, in fact, complex.
> The gain is simplicity: `_emacs' is simpler than `.emacs' because it is not a
> name that is handled specially on various platforms.
You're conflating two things, and I disagree on both. First, that it
is simpler. Apparently you think it is simpler for POSIX users to
adapt to Windows ways (at least, with respect to application's
configuration files) and I don't agree. Second, what I'm talking
about, when I say "more complex", is explaining to the user how it
works. If we were to *remove* .emacs and init.el and keep just _emacs
(let's forget X vs X.el vs. X.elc issues here) it would be simpler;
but as that is not possible, your proposed change adds complexity for
POSIX users. Removing _emacs brings less complexity for Windows users,
without adding it for anyone else.
> Anyway, as Eli has said, this is all moot - it has already been decided.
Thanks god :-)
Juanma
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 09 Apr 2011 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.