[eric.pement@moody.edu: ediff merge fails on Win2K - RESOLVED!]

[Richard Stallman <rms@gnu.org>]

Kifer thinks that call-process is the right place to fix this,
and that seems like a plausible idea.  Does anyone who works
on DOS or Windows want to fix this?


Date: Tue, 25 Mar 2003 11:11:59 -0600
From: Eric Pement <eric.pement@moody.edu>
To: bug-gnu-emacs@gnu.org
Subject: ediff merge fails on Win2K - RESOLVED!
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

This bug report will be sent to the Free Software Foundation [ ... ] 
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

  Several minutes ago, I sent in a bug report about ediff-merge-files
  failing on a Win2K machine using GNU Emacs 21.2.1. Specifically,
  Emacs complained that "diff3.exe" could not be executed, even though
  "diff3" was the proper version, was on the Windows PATH, and even
  though ediff-compare-files had worked successfully in the past.

  As I looked at the error message which I had to paste in with
  continuation lines because it would have been unreadably long, it
  occurred to me that perhaps this long line was the cause of the
  problem. In Windows 2000, the default environment setting for the
  TEMP variable is "%USERPROFILE%\Local Settings\Temp". Of course, the
  %USERPROFILE% is expanded to "C:\Documents and Settings\username",
  and three copies of this string (plus 3 different filenames) are
  appended to the diff3 command, thus creating a very long line.

  Here's how I resolved it:

  I manually created C:\TEMP (which is not in Windows 2K by default).
  I altered the TEMP variable to point to C:\TEMP. That's all I did;
  now everything works.

  My recommendation: I recommend that the ediff fuction calculate the
  length of the command line which will be sent to CMD.EXE, before the
  command is actually sent. If the length of the command line is
  greater than CMD.EXE allows, issue an error message suggesting that
  the user reduce the length of the TEMP environment variable. Thanks
  for listening.

--
Eric Pement - pemente[at]northpark.edu, eric.pement[at]moody.edu