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

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

bug#14342: 24.3; On windows: presence of carriage returns in diff output


From: Eli Zaretskii
Subject: bug#14342: 24.3; On windows: presence of carriage returns in diff output buffers depends on the presence of non-ascii characters in that output
Date: Fri, 03 May 2013 15:17:26 +0300

> Date: Fri, 3 May 2013 12:08:58 +0200
> From: Albert <address@hidden>
> 
> - start emacs 24.3 with -Q (note: emacs 24.1 also shows the same behaviour)
> - make the following file and call it "file-abbbb" (insert the broken bar
> with C-x 8 RET a6 RET):
> line with ¦ (broken bar character)
> bla
> bla
> bla
> bla
> - remove the last "bla" and write that as "file-abbb"
> - again and write as "file-abb"
> - set diff executable to msysgit 1.8.1.2 in customize Diff Command
>   "C:/Program Files/Git/bin/diff.exe"

That's your problem, right there: you are using an MSYS port of Diff
with the native Windows build of Emacs.  MSYS ports are incompatible
with native Windows programs wrt text/binary I/O issues, and the
result is that some lines of Diff's output have DOS CRLF end of line,
while others have the Unix-style LF-only there.  Emacs cannot make
heads or tails out of the resulting mess, so it does its best, which
isn't much.

Solution: use a native Windows port of Diff instead of the one that
comes with msysgit.  One such port is available here:

  http://gnuwin32.sourceforge.net/packages/diffutils.htm

Alternatively, set up your Emacs to always use Unix-style EOLs in
files it creates, either in certain volumes/directories or everywhere.
One way of doing this is using by the "untranslated filesystem"
feature, described in the "Text and Binary" node of the Emacs user
manual.  Another way is to customize default-buffer-file-coding-system
to SOMETHING-unix, where SOMETHING is what it is set by default in
your locale.  The former lets you be selective regarding the
directories where this will take place, the latter is global.

> (By the way: these different behaviours cause problems with magit:
> without the ^M's it is not possible to stage a region of a hunk,
> with the ^M's it does work. Normally I would prefer the ^M's to be
> absent.)

If you need this for magit, I guess you must use the Diff program
which came with msysgit, so the 2nd alternative described above is
what you should explore.

> Why is this behaviour dependent on the presence of a non-ascii character?

Because the decoding of the end-of-line (EOL) format is part of
decoding non-ASCII characters.

I'm closing this bug, since it's not an Emacs bug.






reply via email to

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