Re: ediff failure if diff doesn't exist

[Jesper Harder]

Kevin Rodgers <address@hidden> writes:

> I came across a similar problem in one of my own packages that uses
> call-process to determine what options an external program supports.
>
> It's easy to fix by checking first that executable-find returns non-nil,
> or by wrapping call-process in condition-case.
>
> But that wasn't necessary before, so I suspect that call-process has
> changed to now signal an error.

Unless there's a really compelling reason for this change I think it
should be reverted.  A *lot* of code depends on the assumption that
`call-process' returns a non-zero value if it fails.

Hmm, some years ago I fixed some calls that incorrectly assumed a
numerical return value, so these are just a few of the places that
will probably fail to work correctly if it signals an error instead:

2004-01-03  Jesper Harder  <address@hidden>  (tiny change)

        * progmodes/idlwave.el (idlwave-make-tags):
        * textmodes/flyspell.el (flyspell-large-region):.
        * progmodes/make-mode.el (makefile-query-by-make-minus-q):
        * emulation/viper-util.el (viper-glob-unix-files):
        * emacs-lisp/shadow.el (shadow-same-file-or-nonexistent):
        * man.el (Man-init-defvars):
        * jka-compr.el (jka-compr-call-process):
        * files.el (get-free-disk-space,insert-directory):
        * ediff-ptch.el (ediff-test-patch-utility):
        * ediff-diff.el (ediff-test-utility):
        * dired-aux.el (dired-check-process):
        * mail/sendmail.el (sendmail-send-it): Don't use = or zerop to
        test the return value of call-process, because it can be a string.