C:\_emacs not being read
Shanks N
If there is no .emacs or _emacs in App Data/ folder and there is a
_emacs file in C:\, then Emacs 22.1 does not read the _emacs file.
If I rename the _emacs to .emacs, then everything works fine;
In C:\, Emacs is looking *exactly* for .emacs and not (_emacs||.emacs)
when there is no init file (_emacs||.emacs) in App Data/
I believe this is a bug as it breaks an existing setup (although post
fix resolution, I know I have to rename the _emacs to .emacs).
This behaviour affects Gnus too, which uses the gnus-default-directory
to derive the Mail and News folder paths. When I first launched Gnus
it kept looking in App Data/ folder instead of the usual C:/News and
C:/Mail.
regards,
Shanks
In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/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: ENG
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
show-paren-mode: t
gnus-topic-mode: t
gnus-undo-mode: t
erc-autojoin-mode: t
erc-button-mode: t
erc-ring-mode: t
erc-pcomplete-mode: t
erc-track-mode: t
erc-fill-mode: t
erc-netsplit-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
display-time-mode: t
delete-selection-mode: t
encoded-kbd-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Wrote c:/Mail/ctan-ann
Expiring articles...done
No more unread newsgroups
Making completion list...
GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on RELEASE
Quit
Loading apropos...done
Type C-x 1 to remove help window.
Making completion list... [3 times]
Loading emacsbug...done
Jason Rumney
> If there is no .emacs or _emacs in App Data/ folder and there is a
> _emacs file in C:\, then Emacs 22.1 does not read the _emacs file.
>
.emacs is the standard name for Emacs's user init file. _emacs has
traditionally been additionally supported by the Windows port, because
the FAT16 file system was unable to represent the true name, but noone
uses FAT16 file systems anymore, and such use is deprecated.
Eli Zaretskii
> From: Jason Rumney <jas...@gnu.org>
> Cc: bug-gn...@gnu.org
But if we don't want to support _emacs on Windows anymore, we should
be consistent and remove it from startup.el as well, and also stop
mentioning it in the user manual, right?
Drew Adams
> > traditionally been additionally supported by the Windows port, because
> > the FAT16 file system was unable to represent the true name, but noone
> > uses FAT16 file systems anymore, and such use is deprecated.
>
> But if we don't want to support _emacs on Windows anymore, we should
> be consistent and remove it from startup.el as well, and also stop
> mentioning it in the user manual, right?
I agree with that - let's be consistent.
I don't care much about this issue, but is there some reason *not* to also
support _emacs? Even if no one uses FAT16, it's still the case that Windows
considers .emacs to be a file extension - a file of type "EMACS", and other
applications besides Emacs will try to look for a file association for files
with that extension. IOW, why not simply let Windows users use _emacs as
they have been doing for years?
Jason Rumney
> But if we don't want to support _emacs on Windows anymore, we should
> be consistent and remove it from startup.el as well, and also stop
> mentioning it in the user manual, right?
>
I don't remember what the exact reason for not supporting it in this
particular place was. I can't find the thread where we were discussing
it, only earlier threads from Nov 04 and May 05. We probably should stop
mentioning it in the user manual.
Richard Stallman
> traditionally been additionally supported by the Windows port, because
> the FAT16 file system was unable to represent the true name, but noone
> uses FAT16 file systems anymore, and such use is deprecated.
What versions of Windows used FAT16? And are we sure no one uses them now?
In many poor countries, lots of people use very old versions of Windows.
Eli Zaretskii
> From: Jason Rumney <jas...@gnu.org>
> Cc: shan...@gmail.com, bug-gn...@gnu.org
>
> I don't remember what the exact reason for not supporting it in this
> particular place was. I can't find the thread where we were discussing
> it, only earlier threads from Nov 04 and May 05.
I don't even remember this being discussed.
> We probably should stop mentioning it in the user manual.
What about startup.el? If HOME _is_ set, we still try to load _emacs
if there's no .emacs there.
If you mean remove this from the manual only as a deprecation measure,
then we probably should introduce it into w32.c where we check for
C:/.emacs. However, you mentioned discussions, so perhaps there are
valid technical reasons not to do that which I'm not aware of.
Eli Zaretskii
> CC: jas...@gnu.org, bug-gn...@gnu.org, shan...@gmail.com
> Date: Sun, 10 Jun 2007 09:18:52 -0400
>
> > .emacs is the standard name for Emacs's user init file. _emacs has
> > traditionally been additionally supported by the Windows port, because
> > the FAT16 file system was unable to represent the true name, but noone
> > uses FAT16 file systems anymore, and such use is deprecated.
>
> What versions of Windows used FAT16? And are we sure no one uses them now?
I'm not sure whether FAT16 is still used, but I think .emacs is
supported as a file name even on FAT16. The limitation that a file
cannot have a leading dot was lifted with the introduction of VFAT
(a.k.a. LFN) feature in Windows 95, and FAT16 supports VFAT. Windows
95 is the oldest version of Windows supported by NTEmacs, so systems
that don't have VFAT cannot run NTEmacs anyway. They need to run the
DOS port, which uses _emacs exclusively.
Jason Rumney
> > .emacs is the standard name for Emacs's user init file. _emacs has
> > traditionally been additionally supported by the Windows port, because
> > the FAT16 file system was unable to represent the true name, but noone
> > uses FAT16 file systems anymore, and such use is deprecated.
>
> What versions of Windows used FAT16? And are we sure no one uses them now?
>
Windows 95 supported FAT16 for upgrading from older 16 bit versions of
Windows, but it also supported FAT32 and came with a program you could
run to upgrade the filesystem in place. Support is probably still there,
since floppy disks often use FAT16, but it is rare to see a hard drive
formatted with it these days, even on old PCs since upgrading in place
is so easy.
Jason Rumney
>> Date: Sun, 10 Jun 2007 09:25:33 +0100
>> From: Jason Rumney <jas...@gnu.org>
>> Cc: shan...@gmail.com, bug-gn...@gnu.org
>>
>> I don't remember what the exact reason for not supporting it in this
>> particular place was. I can't find the thread where we were discussing
>> it, only earlier threads from Nov 04 and May 05.
>>
>
> I don't even remember this being discussed.
>
Then perhaps it was an oversight. I thought I remembered some problem
being brought up in checking for both names in c:\.
> What about startup.el? If HOME _is_ set, we still try to load _emacs
> if there's no .emacs there.
>
The intention was definitely never to drop support for _emacs
completely, but I thought I remembered a discussion about problems with
checking in multiple locations, which was resolved by deprecating the
non-standard _emacs version.
> If you mean remove this from the manual only as a deprecation measure,
> then we probably should introduce it into w32.c where we check for
> C:/.emacs.
If 22.2 is to be released soon, then it is worth adding a check if we
are sure it is an omission.