(finder-mode-map): Add n and p bindings.

[emacs.git] / man / msdog.texi

@c This is part of the Emacs manual.
@c Copyright (C) 1985, 1986, 1987, 1993, 1994, 1995, 1997, 2000, 2001,
@c   2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
@c See file emacs.texi for copying conditions.
@node Emacs and Microsoft Windows, Manifesto, Mac OS, Top
@appendix Emacs and Microsoft Windows
@cindex Microsoft Windows

  This section describes peculiarities of using Emacs on Microsoft
Windows.  Information about Emacs and Microsoft's older MS-DOS
``operating system'' (also known as ``MS-DOG'') is now in a separate
manual (@inforef{MS-DOG,, emacs-xtra}).

  Iif you want to use Emacs on Windows, you would normally build Emacs
specifically for Windows.  If you do that, the behavior is reasonably
similar to what is documented in the rest of the manual, including
support for long file names, multiple frames, scroll bars, mouse
menus, and subprocesses.  However, a few special considerations apply,
and they are described here.

@menu
* Text and Binary::            Text files use CRLF to terminate lines.
* Windows Processes::          Running subprocesses on Windows.
* Windows System Menu::        Controlling what the ALT key does.
@end menu

@node Text and Binary
@section Text Files and Binary Files
@cindex text and binary files on MS-DOS/MS-Windows

  GNU Emacs uses newline characters to separate text lines.  This is the
convention used on GNU and Unix.

@cindex end-of-line conversion on MS-DOS/MS-Windows
  MS-DOS and MS-Windows normally use carriage-return linefeed, a
two-character sequence, to separate text lines.  (Linefeed is the same
character as newline.)  Therefore, convenient editing of typical files
with Emacs requires conversion of these end-of-line (EOL) sequences.
And that is what Emacs normally does: it converts carriage-return
linefeed into newline when reading files, and converts newline into
carriage-return linefeed when writing files.  The same mechanism that
handles conversion of international character codes does this conversion
also (@pxref{Coding Systems}).

@cindex cursor location, on MS-DOS
@cindex point location, on MS-DOS
  One consequence of this special format-conversion of most files is
that character positions as reported by Emacs (@pxref{Position Info}) do
not agree with the file size information known to the operating system.

  In addition, if Emacs recognizes from a file's contents that it uses
newline rather than carriage-return linefeed as its line separator, it
does not perform EOL conversion when reading or writing that file.
Thus, you can read and edit files from GNU and Unix systems on MS-DOS
with no special effort, and they will retain their Unix-style
end-of-line convention after you edit them.

  The mode line indicates whether end-of-line translation was used for
the current buffer.  If MS-DOS end-of-line translation is in use for the
buffer, a backslash @samp{\} is displayed after the coding system
mnemonic near the beginning of the mode line (@pxref{Mode Line}).  If no
EOL translation was performed, the string @samp{(Unix)} is displayed
instead of the backslash, to alert you that the file's EOL format is not
the usual carriage-return linefeed.

@cindex DOS-to-Unix conversion of files
  To visit a file and specify whether it uses DOS-style or Unix-style
end-of-line, specify a coding system (@pxref{Text Coding}).  For
example, @kbd{C-x @key{RET} c unix @key{RET} C-x C-f foobar.txt}
visits the file @file{foobar.txt} without converting the EOLs; if some
line ends with a carriage-return linefeed pair, Emacs will display
@samp{^M} at the end of that line.  Similarly, you can direct Emacs to
save a buffer in a specified EOL format with the @kbd{C-x @key{RET} f}
command.  For example, to save a buffer with Unix EOL format, type
@kbd{C-x @key{RET} f unix @key{RET} C-x C-s}.  If you visit a file
with DOS EOL conversion, then save it with Unix EOL format, that
effectively converts the file to Unix EOL style, like @code{dos2unix}.

@cindex untranslated file system
@findex add-untranslated-filesystem
  When you use NFS or Samba to access file systems that reside on
computers using GNU or Unix systems, Emacs should not perform
end-of-line translation on any files in these file systems---not even
when you create a new file.  To request this, designate these file
systems as @dfn{untranslated} file systems by calling the function
@code{add-untranslated-filesystem}.  It takes one argument: the file
system name, including a drive letter and optionally a directory.  For
example,

@example
(add-untranslated-filesystem "Z:")
@end example

@noindent
designates drive Z as an untranslated file system, and

@example
(add-untranslated-filesystem "Z:\\foo")
@end example

@noindent
designates directory @file{\foo} on drive Z as an untranslated file
system.

  Most often you would use @code{add-untranslated-filesystem} in your
@file{_emacs} file, or in @file{site-start.el} so that all the users at
your site get the benefit of it.

@findex remove-untranslated-filesystem
  To countermand the effect of @code{add-untranslated-filesystem}, use
the function @code{remove-untranslated-filesystem}.  This function takes
one argument, which should be a string just like the one that was used
previously with @code{add-untranslated-filesystem}.

  Designating a file system as untranslated does not affect character
set conversion, only end-of-line conversion.  Essentially, it directs
Emacs to create new files with the Unix-style convention of using
newline at the end of a line.  @xref{Coding Systems}.

@vindex file-name-buffer-file-type-alist
@cindex binary files, on MS-DOS/MS-Windows
  Some kinds of files should not be converted at all, because their
contents are not really text.  Therefore, Emacs on MS-DOS distinguishes
certain files as @dfn{binary files}.  (This distinction is not part of
MS-DOS; it is made by Emacs only.)  Binary files include executable
programs, compressed archives, etc.  Emacs uses the file name to decide
whether to treat a file as binary: the variable
@code{file-name-buffer-file-type-alist} defines the file-name patterns
that indicate binary files.  If a file name matches one of the patterns
for binary files (those whose associations are of the type
@code{(@var{pattern} . t)}, Emacs reads and writes that file using the
@code{no-conversion} coding system (@pxref{Coding Systems}) which turns
off @emph{all} coding-system conversions, not only the EOL conversion.
@code{file-name-buffer-file-type-alist} also includes file-name patterns
for files which are known to be DOS-style text files with
carriage-return linefeed EOL format, such as @file{CONFIG.SYS}; Emacs
always writes those files with DOS-style EOLs.

  If a file which belongs to an untranslated file system matches one of
the file-name patterns in @code{file-name-buffer-file-type-alist}, the
EOL conversion is determined by @code{file-name-buffer-file-type-alist}.

@node Windows Processes
@section Subprocesses on Windows 9X/ME and Windows NT/2K

  Emacs compiled as a native Windows application (as opposed to the DOS
version) includes full support for asynchronous subprocesses.
In the Windows version, synchronous and asynchronous subprocesses work
fine on both
Windows 9X and Windows NT/2K as long as you run only 32-bit Windows
applications.  However, when you run a DOS application in a subprocess,
you may encounter problems or be unable to run the application at all;
and if you run two DOS applications at the same time in two
subprocesses, you may have to reboot your system.

Since the standard command interpreter (and most command line utilities)
on Windows 95 are DOS applications, these problems are significant when
using that system.  But there's nothing we can do about them; only
Microsoft can fix them.

If you run just one DOS application subprocess, the subprocess should
work as expected as long as it is ``well-behaved'' and does not perform
direct screen access or other unusual actions.  If you have a CPU
monitor application, your machine will appear to be 100% busy even when
the DOS application is idle, but this is only an artifact of the way CPU
monitors measure processor load.

You must terminate the DOS application before you start any other DOS
application in a different subprocess.  Emacs is unable to interrupt or
terminate a DOS subprocess.  The only way you can terminate such a
subprocess is by giving it a command that tells its program to exit.

If you attempt to run two DOS applications at the same time in separate
subprocesses, the second one that is started will be suspended until the
first one finishes, even if either or both of them are asynchronous.

If you can go to the first subprocess, and tell it to exit, the second
subprocess should continue normally.  However, if the second subprocess
is synchronous, Emacs itself will be hung until the first subprocess
finishes.  If it will not finish without user input, then you have no
choice but to reboot if you are running on Windows 9X.  If you are
running on Windows NT/2K, you can use a process viewer application to kill
the appropriate instance of ntvdm instead (this will terminate both DOS
subprocesses).

If you have to reboot Windows 9X in this situation, do not use the
@code{Shutdown} command on the @code{Start} menu; that usually hangs the
system.  Instead, type @kbd{CTL-ALT-@key{DEL}} and then choose
@code{Shutdown}.  That usually works, although it may take a few minutes
to do its job.

@node Windows System Menu
@section Using the System Menu on Windows

Emacs compiled as a native Windows application normally turns off the
Windows feature that tapping the @key{ALT}
key invokes the Windows menu.  The reason is that the @key{ALT} also
serves as @key{META} in Emacs.  When using Emacs, users often press the
@key{META} key temporarily and then change their minds; if this has the
effect of bringing up the Windows menu, it alters the meaning of
subsequent commands.  Many users find this frustrating.

@vindex w32-pass-alt-to-system
You can re-enable Windows' default handling of tapping the @key{ALT} key
by setting @code{w32-pass-alt-to-system} to a non-@code{nil} value.

@ignore
   arch-tag: f39d2590-5dcc-4318-88d9-0eb73ca10fa2
@end ignore