bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19591: 24.4; file & buffer compare failures


From: Eli Zaretskii
Subject: bug#19591: 24.4; file & buffer compare failures
Date: Wed, 14 Jan 2015 20:28:07 +0200

> Date: Tue, 13 Jan 2015 11:56:54 -0800
> From: Glenn Linderman <v+python@g.nevcal.com>
> 
> However, the auxiliary program diff when launched by emacs still doesn't
> accept files with such characters. The latest version of diff for
> windows that I can find is 2.8.7. The error message from diff in the
> error buffer seems to contain the proper characters for the file name,
> but diff reports it cannot find the file so I tihnk it is a deficiency
> in diff, like was in emacs versions prior to 24.4, using the
> "bytes" version of open instead of the "widechars" version.

Yes, Diff, as all the other native ports of GNU software to Windows,
uses the ANSI APIs to access files and its command-line arguments.

It is hardly the job of the Emacs team to fix programs that are not
part of the Emacs package.  So I'm not sure what exactly did you
expect of the Emacs project in this matter.

You should know that the Emacs support for non-ASCII characters
outside of the current system codepage stops short of extending that
support to subprocesses invoked by Emacs, for this very reason: there
are no native ports known to me of popular programs, such as Diff,
Grep, find/xargs, etc. that can handle such file names.  So being able
to pass such non-ASCII file names to those programs would be a waste
of effort, since they cannot handle them.

> While it may be somewhat inefficient, it would be possible for emacs to
> work around the deficiency of diff by saving temporary copies of the
> buffers to be compared using generated names in the ANSI subset.

This is not practical.  The place in Emacs sources where command-line
arguments of subprocesses are constructed and encoded has no idea
which of these arguments are file names and which aren't.  (There are
also additional technical difficulties to do that, too boring to go
into here.)  Only the application level -- the Lisp program that needs
to invoke Diff or whatever -- knows that.  So what you suggest would
mean we need to add this kind of work-around in each and every place
where some Lisp invokes some program, too many places to do that.  On
top of that, this would be inefficient: a file could be very large.

So I don't think this problem could or should be solved in Emacs.  Let
people who produce the ports of Diff etc. add support for these
characters first, then there will be a good reason for Emacs to do the
same.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]