emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [Bug] Export Coding System


From: Nicolas Goaziou
Subject: Re: [O] [Bug] Export Coding System
Date: Fri, 22 Feb 2013 23:09:02 +0100

Achim Gratz <address@hidden> writes:

> Nicolas Goaziou writes:
>>> Depends on what language environment is set to, but with the default 
>>> setting of
>>> my Emacs (German) it becomes iso-latin-1, independently of what the coding
>>> system in the original Org buffer was.
>>
>> In this case, it should be `utf-8', shouldn't it?
>
> I want it to be utf-8, but it isn't.  The course of events is apparently
> that when a new buffer gets created it will have the default coding
> system.  You are then apparently asking that buffer for the coding
> system (always the default) and set inputenc accordingly, but should
> have asked the parent Org buffer.  Or so I think, a few details are
> probably still wrong.
>
>>> I think that the export buffer coding system should be explicitly set (via
>>> buffer-file-coding-system, which is automatically buffer-local) to copy the
>>> coding of the parent buffer (or the coding specified via export options if
>>> anything like that exists) so that the default choice of the language
>>> environment doesn't kick in.
>>
>> Still trying to understand: is the coding system wrong when you export
>> to a file, to a (temporary) buffer, or both?
>
> Both.
>
>> Note that `org-export-to-file' use `coding-system-for-write', which
>> overrides `buffer-file-coding-system'. So this variable is probably
>> irrelevant here.
>
> No it is not irrelevant, it simply gets set too late in the game: it
> asks for the new coding system when it is time to save the buffer, while
> the content of the buffer has been cobbled together while assuming a
> different coding system.  The only way I know (from browsing the
> documentation) to override the coding system for a buffer that does not
> yet have a file association is to set that variable directly,
> preferrably directly after the buffer is created.

Does the following patch fix the problem?


Regards,

-- 
Nicolas Goaziou
>From ed16f38854c197e8b31607bd32622d00e47fe10c Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <address@hidden>
Date: Fri, 22 Feb 2013 23:07:04 +0100
Subject: [PATCH] ox: Fix coding system error

* lisp/ox.el (org-export--generate-copy-script): Clone
  `buffer-file-coding-system' when creating a buffer copy.

This patches makes sure the output will share the same encoding as the
original buffer.
---
 lisp/ox.el | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index efce29d..65e5acd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2729,10 +2729,13 @@ another buffer, effectively cloning the original buffer 
there."
                        (val (cdr entry)))
                    (and (not (eq var 'org-font-lock-keywords))
                         (or (memq var
-                                  '(major-mode default-directory
-                                               buffer-file-name outline-level
-                                               outline-regexp
-                                               buffer-invisibility-spec))
+                                  '(major-mode
+                                    default-directory
+                                    buffer-file-name
+                                    buffer-file-coding-system
+                                    outline-level
+                                    outline-regexp
+                                    buffer-invisibility-spec))
                             (string-match "^\\(org-\\|orgtbl-\\)"
                                           (symbol-name var)))
                         ;; Skip unreadable values, as they cannot be
-- 
1.8.1.4


reply via email to

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