0

I have files in Markdown, saved in a Dropbox folder. One of them replaces characters with angled bracket sequences. For example a git diff no-index between the saved file and a copy-paste of the text to a new file gives:

-# `Package <81><B4>julia-mode-0.3<81><B4> is unavailable.`
+# `Package ´julia-mode-0.3´ is unavailable.`

Other sequences are <91><A1><AD> for ellipsis (...), <81><A0> for a space, <81><E2> for â, <86><A4> for the euro sign €, <91><A1><B0> for opening double quote, <91><A1><B1> for closing double quote, <86><A1> for opening single quote, <86><A2> for closing single quote.

The variable buffer-file-coding-system is emacs-mule-unix in the original buffer and utf-8-unix in the buffer with the copy-pasted content.

Many other files in the same folder have recently stopped showing with proper formatting. They list Fundamental in the mode line instead of Markdown. The characters display properly. Many of these buffers have a variable buffer-file-coding-system of undecided-unix.

As I started having these issues around the same time, I believe they are related. Since the characters display fine in Emacs, it's not a question of converting the buffer from one encoding to another (as many of the threads I have found).

How can I save all of these buffers back to utf8-unix, and what triggered this behavior?

Improve this question
2
  • Does it happen for files outside of the Dropbox folder? What do you mean exactly by "copy-paste"? How does the files display in the terminal (eg less myfile)? What character set does the file command report (file myfile in the shell)? – JeanPierre May 25 '19 at 6:01
  • No, so far it has only happened to files in the Dropbox folder. By "copy-paste" I mean Cmd-A, Cmd-C, Cmd-V on macOS. less myfile shows the same thing: the first file as Package <81><B4>julia-mode-0.3<81><B4> is unavailable. and the second as Package ´julia-mode-0.3´ is unavailable.. The file command reports Non-ISO extended-ASCII text for the first and Lisp/Scheme program text, UTF-8 Unicode text for the second. – miguelmorin May 28 '19 at 15:33
0

Interesting problem. To start with, I doubt that Emacs has replaced a horizontal ellipsis with the string "<91><A1><AD>". Instead, I suspect that what you're seeing is what your shell prints out when it sees a byte sequence that aren't valid in utf-8.

Indeed, <91><A1><AD> is not the byte sequence that utf-8 specifies for a HORIZONTAL ELLIPSIS character; I would expect to see <E2><80><A6>. (But of course, if your shell saw that byte sequence it would have drawn the glyph for the ellipsis as expected.)

It looks like the emacs-mule-unix coding system isn't compatible with utf-8 (the documentation on it isn't very specific). I would update the Emacs configuration so that it always saves files in utf-8-unix instead.

Improve this answer
2
  • I followed these directions to set the defaults to UTF-8, but it still showed the same characters. Do you have a way to save in UTF-8 that avoids copy-pasting? – miguelmorin Apr 29 '19 at 9:23
  • Despite setting four coding systems to 'utf-8-unix, some buffers still save as ‘undecided-unix’. – miguelmorin May 1 '19 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.