From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 19591-done@debbugs.gnu.org, Glenn Linderman <v+python@g.nevcal.com>
Subject: bug#19591: 24.4; file & buffer compare failures
Date: Mon, 30 Sep 2019 03:08:50 +0200 [thread overview]
Message-ID: <CADwFkmnBFV1jH4J53TwMm-SO82zsoGeDjisRCpw9opcOEZHKxg@mail.gmail.com> (raw)
In-Reply-To: <54B57886.4030107@g.nevcal.com>
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
With the above explanation, I'm closing this bug report.
Best regards,
Stefan Kagas
prev parent reply other threads:[~2019-09-30 1:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 19:56 bug#19591: 24.4; file & buffer compare failures Glenn Linderman
2015-01-14 18:28 ` Eli Zaretskii
[not found] ` <54B6C620.6050909@g.nevcal.com>
2015-01-14 19:53 ` Eli Zaretskii
2019-09-30 1:08 ` Stefan Kangas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADwFkmnBFV1jH4J53TwMm-SO82zsoGeDjisRCpw9opcOEZHKxg@mail.gmail.com \
--to=stefan@marxist.se \
--cc=19591-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=v+python@g.nevcal.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.