Subject: Re: emacs-19.34.4

From: Andrew Innes <[email-masked]>
Date: Wed, 23 Jul 1997 15:31:51 +0100 (BST)

On Tue, 22 Jul 1997 23:06:32 -0700 (PDT), [email-masked] (Geoff Voelker) said:
>Appended below is a reasonably complete list of changes between
>19.34.1 and 19.34.4.

Some minor corrections, additions, and detailed explanations:

>* Enable direct file access for movemail.

Caveat: movemail uses the locking() function when accessing a mail spool
file - whether or not this is the right way to lock the file depends on
the mail delivery daemon involved.  As far as I can tell, it is not
uncommon (on Unix hosts if nothing else) for delivery daemons to use a
different method of (cooperative) locking, which is incompatible with
the method movemail on Windows will use.

>* Update file-truename to do comparisons based upon file name as
>  stored on disk (e.g., Emacs will now recognize "c:/progra~1" and 
>  "c:/program files" as the same file).

This change will hopefully solve the vast majority of problems where the
same file gets loaded into several buffers under different names
(eg. just different capitalization, or using short name aliases instead
of long names, etc).  By default when you try to load a file already in
another buffer under a different name, you should be notified of this
(and the existing buffer is selected).  You can optionally set a lisp
variable so that the truename is always used as the buffer name.

See the documentation on the `find-file-existing-other-name' and
`find-file-visit-truename' variables.

>* Fixes to support perl debugging.

All the necessary changes required on the Emacs side should now be in
place - all that is required is to edit perldb.pl (perl5db.pl for Perl5)
so that the debugger uses stdin/stdout for communicating with Emacs and
not the console (CON).  Someone recently posted an article describing
this change, and the PROBLEMS file in the emacs top-level directory also
explains what to do.

There is also a small fix for debugging with gdb, to correctly handle
file names with drive letters.  I don't know if this means gdb (eg. the
Cygnus version) now works under Emacs or not, but if not it should be
much closer to doing so.

>* New proxy shell, cmdproxy, for creating and managing subprocesses.

====> This is perhaps the most significant change for this release -
====> please read this next bit carefully.

When you run the addpm program to install Emacs (which you should do
even if you are installing over an existing version), it now sets the
default value of SHELL to cmdproxy.exe.  (Note, if you explicitly define
SHELL in your environment, eg. in autoexec.bat or in the Control Panel
on NT, then you may need to change that setting by hand.)

As a proxy shell, cmdproxy is designed to bypass the standard Windows
shell program for simple things and to invoke the real shell for batch
files, interactive use, etc.  Really, its main purpose is to translate
between the command line interpretation of /bin/sh on Unix (which is the
interpretation almost always expected by Emacs), and the convention used
on Windows by command.com and cmd.exe.  By doing so, cmdproxy eliminates
most of the problems with argument quoting (or lack of it) that have
caused so much grief.

If you currently use the standard shell program, then you should make
sure you now use cmdproxy.  As noted above, this happens by default
unless you explicitly set SHELL somewhere, in which case you need to
change that setting.  This includes having
	(setenv "SHELL" "foo")
and/or
	(setq shell-file-name "foo")
in your .emacs.

However, if you currently use a Win32 port of a Unix shell, such as
Cygnus bash, MKS ksh, etc, then you can probably just keep using that
without change.  (In this case, if you were relying on SHELL being set
correctly in the registry, then remember that addpm may have overwritten
your definition.)

>  * Support for multiple DOS subprocesses.

This was previously a major limitation when working on Windows 95,
unless you used a Win32 shell program and could mostly stick to running
Win32 programs.  You should now be able to use DOS programs almost as
easily as Win32 programs.  The main remaining limitation is that you
cannot kill a DOS program on Windows 95 (see below).

>  * Properly pass on ctrl-break and ctrl-c keys to subprocesses.

That is, typing C-c C-c in a shell buffer (C-c C-k in a compilation
buffer) should interrupt the program(s) running in that buffer, as if
they had been running in an ordinary command window and you typed Ctrl-C
there.  (Note that programs are free to ignore the SIGINT signal they
receive, but most command line programs will exit.)

For reference, typing Ctrl-Break (aka C-cancel) in Emacs does not do
anything.

>  * win32-quote-process-args should always be set now.

To be precise, by default win32-quote-process-args is now set to t.
Ordinarily you should never need to change it, and if you have lisp code
that does change it (apart from setting it to t in .emacs, say) then you
should try removing that code since it might now cause problems.

Argument quoting itself (when constructing the command line for
subprocesses) is also improved, and should hopefully work properly in
virtually all cases.  If you have lisp code that tries to work around
problems with argument quoting in previous releases, you should try
removing that code (perhaps restoring the original code, if you modified
code that worked on Unix) and seeing whether any problems still exist.

If you do have problems with argument quoting, I'd like to hear about
them, but first make sure win32-quote-process-args is t and that the
list of arguments to call-process, start-process or whatever is correct.

Note: One possible problem with argument quoting that I know might come
up relates to Unix-like program ported to Windows using an unusual
toolkit.  Depending on the compiler and C library used, such programs
might use a different escaping method than either the Microsoft or the
Cygnus C libraries.  Since Cygnus and Microsoft compiled apps use
different and incompatible escaping methods (Cygnus doubles embedded
quotes, MS escapes embedded quotes with backslash), Emacs now recognises
Cygnus-compiled apps and selects the escaping rule accordingly.

By default non-Cygnus apps use the Microsoft method, which might not be
correct for apps not linked with the MS C library.  For instance, the
MKS tools might fall into this category - I don't know.  The Unix tools
ported to Windows by David Korn (author of the Korn shell) under the
name UWIN might also suffer from this.  (If the escaping method is
wrong, then arguments which contain embedded quotes will probably be
parsed incorrectly by the subprocess.)

>  * Better support for terminating subprocesses.

The elisp function `kill-process' is now able to cleanly terminate a
subprocess (and all of its children), as long as they are Win32 console
(ie. command line) programs.  This works as if they were running in a
command window and you closed the window.  (On Windows NT, each program
gets sent the equivalent of a SIGKILL signal, but on Windows 95 there is
no notification of any kind.  It may well be that on Windows 95 the
applications are terminated with extreme prejudice, not cleanly, but at
least all children of the subprocess should be terminated which is an
improvement on previous releases.)

If a subprocess is a DOS program, on Windows NT a dialog box will come
up asking whether you want to terminate the program - you can safely say
yes; on Windows 95, the DOS program is not terminated or interrupted in
any way.  As before, you must properly exit all DOS subprocesses before
quitting Emacs.

As well as being able to terminate subprocesses cleanly, Emacs now
reliably detects when subprocesses exit.  Previously, Emacs could either
forget a subprocess existed (leaving an extra thread hanging around
indefinitely, taking up resources), or hang waiting for a process to
finish when it's still running.

>* addpm no longer requires an argument (figures it out from where it lives).

That is, to run addpm.exe you can now just double click on it in File
Manager or Explorer.

>* When updating a buffer with existing text, correctly
>  preserve marker and point positions by taking into account CR/LFs.

This change enables a feature that previously only worked on Unix.  When
you revert a buffer (eg. you've checked out a version controlled file
already loaded in Emacs), normally the current position and font
hilighting will now be preserved when the file is reloaded.

>* Enable add-name-to-file function.
>* Support link for NTFS filesystems.
>* New variable win32-get-true-file-attributes.

These three things are related.  `add-name-to-file' is the elisp
function for creating hard links - this now works on NT for creating
hard links to files on NTFS volumes only (previously it always reported
an error).

A matching change to the elisp function `file-attributes' now allows it
to return the correct link count for files, if the variable
`win32-get-true-file-attributes' is set to t.  That is, you can find out
the actual link count of files on NTFS volumes.

Because determining the link count noticeably slows down
`file-attributes' and other related functions like
`file-name-completion', and because most people will never use hard
links, the variable `win32-get-true-file-attributes' is nil by default.

>* Support relocatable heap upon startup (fix, e.g., for HeapAgent dll).

This is only relevant to running the undumped Emacs file, temacs.exe.
If you run temacs.exe to dump a new emacs.exe, then the heap location
will be chosen to work on that machine.

>* Window width and height forced to be multiples of character dimensions.

This is part of a collection of "cosmetic" bug fixes that should mean
frame dimensions are now set correctly based on -geometry, or
width/height settings in `default-frame-alist'.  Also the problem with
frames creeping across the screen when you minimize and restore them
should now be fixed.

>* Support font charsets other than ANSI or OEM.

This support for alternate charsets is not quite as complete as some
people asked for (I think), but hopefully should be a big improvement on
previous releases.  You should now see all fixed-width fonts in the font
selection dialog (S-mouse-1), not just those with ANSI or OEM charset
encoding (`x-list-fonts' similarly returns all fonts).  If the charset
is not ANSI or OEM, it is written as "#nnn" where nnn is the numerical
charset value reported for that font.

So you can now select Courier New in Cyrillic encoding (if you have it),
for instance, using the font string

	"-*-Courier New-normal-r-*-*-13-97-*-*-c-*-*-#204-"

>* Frames raise and lower correctly.

This will undoubtably be a source of confusion for many people [indeed I
see there is already a report about it], but `raise-frame' does NOT
force a frame to the front of everything else UNLESS Emacs is the
foreground application at the time.  It also does NOT give input focus
to the raised frame, even if Emacs is in the foreground.  This is
deliberate, and is consistent with the behaviour on Unix (to the best of
my knowledge).

This means that if you are in Explorer and double-click on a file with
an association to gnuclientw (for example), the Emacs frame which loads
the file will NOT jump to the foreground.  However, it will become the
topmost of all frames belonging to that instance of Emacs.

If one frame has input focus and you do something that calls raise-frame
to bring another frame to the top, the other frame will be placed on top
but will the original frame will still have input focus.

As I said, this will undoubtably catch out many people, but it _is_ the
"correct" behaviour as defined by Emacs on Unix, AFAIK.

For reference, I don't think there is (supposed to be) any way to give
input focus to another frame from within Emacs.  The reasoning, as I
understand it, is that only the user should be able to move input focus,
and the standard (?) style-guide for X applications specifies that
applications should not change input focus in this way.

Ironically, the functions `focus-frame' and `unfocus-frame' used to be
implemented to allow Emacs to grab or relinquish focus programatically,
but they were deprecated some time ago.

However, I realise that many users expect to be able to change focus
programatically (eg. to have an Emacs frame jump to the foreground when
you double-click on a file in Explorer).  I'll look into providing this
capability in the future, perhaps by resurrecting focus-frame.

As a partial work-around, I've discovered the following function works
for programatically switching focus to another frame, when Emacs is in
the foreground:

(defun raise-and-focus-on-frame (frame)
  "Raise frame and give it input focus if in foreground."
  (raise-frame frame)
  (make-frame-invisible frame)
  (make-frame-visible frame))

This works on Unix as well.

>* New function win32-get-long-file-name.
>* New function win32-get-short-file-name.

Typo: the names are just win32-long-file-name and win32-short-file-name.
If a file exists, these functions return the true name and the actual
DOS alias name on disk, respectively.

>* New variable win32-generate-fake-inodes.

This was removed in the release.  It served no purpose since
file-truename now uses win32-long-file-name to accurately detect most
instances where the same file is loaded under different names.

>* New variable w32-start-process-show-window.

This causes the console window created for each subprocess to be left
visible - normally you would not want to do this, but if you are
starting a GUI application instead of a console app, then you may need
to set this to t in order not to hide the application's main window.

Additional changes (some first included in 19.34.2):

* Emacs is now better behaved when run as emacs -nw (ie. in text mode).
  In particular, it is possible to run emacs -nw remotely using one of
  the telnet servers available for Windows 95 or NT, although different
  telnet servers may have individual limitations that make it hard to
  type C-c, etc.

* Emacs now properly handles C-g (the quit character).  Before it would
  always see two C-g characters for each one typed, which affected
  isearch mode and WordStar mode.

* The default font is now Courier New rather than Fixedsys.  This is
  mainly because Courier New uses ANSI encoding, which matches the
  encoding in which Emacs reads character input.  Also, Courier New has
  bold (and italic, if you set `win32-enable-italics') variations

AndrewI