0

I have emacs-24.5 installed on Windows 10. Many utilities are configured through cygwin, including perl. When in Markdown mode every so often after I press C-c C-c p to run the external markdown.pl against the buffer contents and open the resulting markdown-output buffer in the browser, I instead see the following:Incorrect encoding The reason is that the original README.md file contains RIGHT SINGLE QUOTATION MARK character in UTF-8 format, which is the bytes E2 80 99, or 0x2019 code point in Unicode. markdown.pl interprets the character correctly in its output, I tried to run it from the command prompt and the resulting HTML is also in UTF-8 encoding.

Hence the question: how can I to configure markdown-preview function so as it sets markdown-output buffer coding system to utf-8 anytime I asked for markdown-preview?

|improve this question
0

The fact that the top-right window shows those "characters" as \342\200\231 indicates that the file was incorrectly read from the disk. More specifically, Emacs apparently decided that this file does not contain utf-8 text but that it contains binary. This is usually due to a NUL byte somewhere within the file. You can search for it with C-s C-q 0 RET.

You might like to report this as a bug (i.e. the chars should not appear as \342\200\231 but as ’).

|improve this answer
  • I do not think that the issue is caused by the NUL bytes in markdown-output buffer. In fact, the warning depicted on the above screenshot is shown BEFORE the buffer is written to the disk. I have searched for NUL byte in the original README.md file, there is no NUL byte in it either.\ I believe that the issue is related to the coding system that is set at the moment the IO command is performed. The IO commans that sends the original buffer contents to markdown.pl and receives its output back. – Volodymyr Feb 28 at 10:13
  • @Volodymyr: No, the problem comes long before you try to save the buffer: the problem you see when you try to save is due to the presence of \342\200\231 instead of ’ in the buffer, which itself is due to Emacs reading the file (or the process output if this text comes from a process output) incorrectly. – Stefan Feb 28 at 13:04
  • Sorry, @Stefan, but I can hardly agree with you. The buffer depicted above is not the representation of the file read from the disk, but as a result of I/O operation. The original file is called "README.md", and it does not contain HTML, it rather contains Markdown. What is seen on the screenshot above is an HTML file that is the result of the original markdown transformation through the markdown.pl utility. – Volodymyr Feb 28 at 19:43
  • @Volodymyr: that doesn't change the fact that \342\200\231 indicates that the bytes read (in this case from the output of the markdown transformation) were read incorrectly (it should have read it as ’) and that this problem is the source of the error you see when you then try to save the buffer. Hence you need to figure out why Emacs did not interpret those bytes as utf-8 text but as some binary data. Seems like a bug in your mode's C-c C-c C-p command. – Stefan Feb 28 at 21:36
  • To @Stefan: Thank you for your support. I have finally resolved the issue by adding the following into my 'markdown-mode-hook) : (add-to-list 'process-coding-system-alist '("bash" utf-8-unix . utf-8-unix)). – Volodymyr Mar 2 at 20:09

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.